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

List:       kde-core-devel
Subject:    Re: got it! (Re: Kicker memory leaks)
From:       Josef Weidendorfer <Josef.Weidendorfer () gmx ! de>
Date:       2002-05-10 8:03:16
[Download RAW message or body]

Hi,

thanks pointing out the problem with tear-off.
But the quick-browser is UNUSABLE without this patch.
I'm quite sure that the 'kicker memory leak' problem is
exactly this one: Once you opened a dir with quick browser
that is changed quite often (home dir, /tmp, /dev, /proc ...)
kicker will until its end regenerate the menus in the background
on any change. If you check, you easy get >10 000 KDirWatch
instances in a few minutes (and PanelBrowserMenu instances too).

Combined with a "fast" KDirWatch notification (/dev/imon in kernel
or DNOTIFY support in FAM, even if DNOTIFY is disabled in KDE at
the moment...) kicker will be unusable...

I avoided changing the popup menu while visible because there
seems to be a bug: When a popup menu is being deleted while
browsed with the mouse, X hangs for me (mouse grab): I have
to switch to a text console und kill kicker!

New solution:
Create PanelBrowserMenu instances only once, and reuse them
afterwards. This should be the way to go, as tear-offs won't be
destroyed this way. But this means that we have to check in
PanelBrowserMenu::initialize if there is already a popup menu for
a subdirectory, or we use the create/delete events of KDirWatch
to track directory contents and NEVER completely clear/regenerate
a quick browser menu.
But this means that I have to implement this for KDirWatch first,
i.e. NEVER emit only a dirty() event on a watched directory, but
emit created/deleted events for new/deleted files/dirs.
Only FAM does it this way at the moment. Note that KDirLister
supports this "incremental" directory update, so this change in
KDirWatch for STAT/DNOTIFY is good for whole KDE...

As this is more work to do, I don't supply a patch :-)
Open for discussion...

Josef


On Thursday 09 May 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.
>
> Cheers,
> Waldo

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