got it! (Re: Kicker memory leaks)

[Lubos Lunak]

On Thursday 09 May 2002 23:42, Lubos Lunak wrote:
> On čt 9. květen 2002 22:48, Waldo Bastian wrote:
> > On Wednesday 08 May 2002 03:56 pm, Josef Weidendorfer wrote:
> > > Attached patch:
> > > - PanelBrowserMenu::slotClear reimplements KPanelMenu::slotClear
> > >   and correctly delete the submenus (Question: should submenu
> > >   deletion handling be done in KPanelMenu, as this deletion bug
> > > probably exists for the K-Menu too ?!??).
> > > - KDirWatch events simply call slotClear; this is much better than
> > >   regenerating menus that aren't visible at all. The menus are always
> > >   regenerated if needed before they are shown (slotAboutToShow calls
> > >   initialize() !)
> > > - Menus should NOT be changed when shown. When shown, a change
> > >   is marked in a dirty flag. When the menu is shown the next time,
> > >   the menu is updated before (in initialize()).
> > > - Start KDirWatch as late as possible (in initialize()), and remove
> > >   it as early as possible (in slotClear())
> > >
> > > This leads to a much saner behaviour now. Note that opening a
> > > quickbrowser on /proc/self or on /tmp while compiling rendered
> > > kicker useless before this change.
> > >
> > > Please check and commit to BRANCH and HEAD again :-)
> >
> > The patch has some weird interaction when a browser menu is torn off.
> >
> > The torn off menu sort of disappears when something in the directory
> > changes.
>
>  This has probably to do with
> http://lists.kde.org/?l=kde-cvs&m=102095154829788&w=2 (not the change
> itself, but the grumbling of mine about the right fix). I think that
> KPanelMenu::reinitialize() shouldn't call initialize(), as that's what
> aboutToShow() is for. The exception is when the menu is visible, but due to
> the somewhat hacky way tear-off menus are implemented this is simply not
> possible, as you simply can't find out if the popup menu is visible as
> torn-off (well, torn-offs are a stupid useless eyecandy feature anyway).
>
>  I've already mailed qt-bugs@ asking for a way to find out when the menu is
> visible, even in tear-off mode. For now, using the patch and replacing all
> "slotClear()" and "setInitialized(false)" with "reinitialize()" should
> probably do, with some unnecessary menu generations, and after Qt is
> changed, KPanelMenu::reinitialize() can be changed to call initialize()
> only when needed.

 Quoting the answer from qt-bugs@ ,

On Friday 10 May 2002 19:42, qt-bugs at trolltech.com wrote:
> >  Would if be possible to add e.g. something like "const QPopupMenu*
> > QPopupMenu::tearOffWidget() const", or any other way allowing to find out
> > if the popup menu is really visible or not?
>
> Yes, but not for 3.0.x
>
> Dynamic popup content is indeed the reason why I think KDE's automatic
> adding of tear-off handles is a really bad bad bad idea.
>
> Dynamic menus should simply not have a tear off handle.
>
>
> Matthias
>
>   ettrich at trolltech.com                        Fax: +47 21604801

 how about simply commiting the patch as it is and just not adding tear-off 
handles to quickbrowsing menus? I fail to see usefulness of torn-off 
quickbrowing menus anyway - that's what Konqy or Kicker buttons are for (I 
mean, I find such torn-off menus even more useless than in general >;) ).

-- 
 Lubos Lunak
 llunak at suse.cz ; l.lunak at kde.org
 http://dforce.sh.cvut.cz/~seli