[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    RE: konqy active-view and keyboard focus problems
From:       David Faure <David.Faure () cramersystems ! com>
Date:       2000-03-13 15:06:19
[Download RAW message or body]

> > > I hacked a bit around and installed in konq_frame an 
> > > eventhandler for the
> > > embedded [tree, icon, text]view, which caused to change the
> > > active-view-indicator according to focus in/focus out events, 
> > > but this seemed to me like a hack. It also didn't solve problem 1.
> > 
> > It's an awful hack. KParts should take care of that.
> > Perhaps Simon disabled something in KParts (the FocusIn event stuff
> > has always been tricky) ?
> 
> I had to disable the FocusIn event handling in partmanager during the
> kparts-koffice switch. It horribly broke on the part-selection dialog in
> koffice, although I never found out why (the parent of the 
> dialog was set correctly and the focus policy was fine, too -- but still 
> always the shell got the focus, which is wrong if the dialog was launched
from 
> withing an embedded document ).
> 
> I just tested it again with todays sources and it still doesn't work
> (meaning it breaks koffice :-(
:(
Well, this is a bug and it needs to be investigated ;-)
The debug output of KParts says every time it gives the focus
to a part, which widget got the focus. Perhaps that helps here ?

> Test it with this:
> Remove the comment about the FocusIn condition in 
> KParts::PartManager::eventFilter, open a koffice application, embed a
> kspread document (example), activate the kspread document, open up the
> insert-part dialog, select some part and click "Ok" . Now the 
> shell will get the focus :-(

Perhaps the _window_ gets a focusin event because another window
was taking its focus ? You see what I mean: both the window and
the actual active widget get the focus, when the dialog is closed.

If so, the fix would be to simply disable the focusin even handling
when the widget that got the focus is a toplevel window, if we know
that another widget (giving more information about which part
to activate) is going to receive the event too (or actually, did before).
Just a wild guess. Can't investigate right now - and I'm leaving tomorrow
for 2 days in Paris BTW.

> I have absolutely no idea where the bug is, however I think 
> that we should check for the FocusIn stuff in partmanager (as 
> David's original implementation worked perfect -- switching the 
> active view in konqueror was possible via <tab> )
Yup. And before that I had never heard of focus policies... ;-)

David, so glad the Qt docu is so good.

[prev in list] [next in list] [prev in thread] [next in thread]