kdevelop speed drop

[F@lk Brettschneider]

Hi,

Roland Krause wrote:
> 
> Falk,
> it's perfectly clear to me what you are trying to accomplish.
> But I think checking for whether the file is already open should be the
> way to go instead of checking whether it "has_focus".
> 
> The problem with yesterdays fix was, that if the file "gets focus" it
> then "has focus" when you enter docViewManager::slot_gotFocus(),
> therefore your fix would kick in every time, even the very first time.
> 
> So I believe there should not be a fix, instead and architectural
> change.
Oops. I don't think so. :)

> If certain things have to be set only the first time a view is
> opened the so be it. The slot_gotFocus() methods seems to be the wrong
> place to call them.
> 
> Also, I still can not see what this all has to do with the menu?
Wandering through the mainmenu triggers a FocusOut (when popping up) and
FocusIn (when leaving the popupmenu) to the last focused widget (the
current MDI view) with every opened popupmenu there.
The FocusIn event is a central point in QextMDI.
QextMdiChildView::focusInEvent is called which does internal things of
QextMDI (taskbar, view state changes) and then it triggers the
gotFocus() signal to the outside world. DocViewMan connected the signal
gotFocus() with his slot_GotFocus(). Slot_gotFocus(..) calls also
CKDevelop::slotViewSelected(..), a lot of things (concerning to
switching views) happen in these both slots of KDevelop (for instance
the update of the state of the toolbar buttons)

Well, a real focus change (means: a _real_switch_ to another view) needs
to call all the stuff I wrote above. A fact.
But we don't need to call all of them on each and every FocusIn, for
instance just when a simple mouse click has happened or we are temporary
showing popmenus. 
That was is what I'm trying to do at the moment. I think, the last two
commits didn't changed much. An FocusIn event still calls always
DocViewMan::slot_gotFocus(..). :-( At first I thought I got it but then
I found situations which show the opposite... I believe a fix for the
emit of gotFocus() in QextMdiChildFrm::activate() is still necessary,
probably a little thing to change there...

This weekend I'm off, I'll look into that again later then.

Cheers,
F at lk


> 
> Roland
> 
> --- "F at lk Brettschneider" <gigafalk at yahoo.com> wrote:
> > Roland Krause wrote:
> > >
> > > Falk,
> > > after we talked on IRC I started real testing. There are lots of
> > > problems w/this fix. Windows that get focus dont get real focus
> > from
> > > the program, the results is that I can only search in a view that
> > > initially has focus, when I focus another view, keyboard
> > accelerators
> > > are not available neither are menu functions, so there is not undo
> > and
> > > stuff. After a while KDevelop crashes.
> > Sch*iße. :-(
> >
> > But it's definitely the reason for the slowdown (I think jbb just
> > forgot
> > to call 'make install' ;). It takes quite a long time to compute all
> > the
> > stuff you wrote about above, that's why the delay on a flood of focus
> > changes like when wandering through the mainmenu. Fortunately, my bad
> > commit was _after_ the alpha2 tag of KDE.
> > I've converted it back in CVS and will try to prevent slot_gotFocus
> > already in QextMDI _before_ we are pending in a focus change where an
> > escape is fatal. Clear? ..anyway. ;-)

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«