[Panel-devel] Re: PATCH: Dynamic Quicklauchner applet

[Aaron J. Seigo]

On Wednesday 01 June 2005 02:23, you wrote:
> - The minimum number of items
> - The maximum number of items
> - The threshold when an application will be included/removed.

you seem to have forgotten to include the autoadjustdlgbase.ui file which is 
preventing me from compiling this =)

> The kmenu and the minicli must be patched, too.

hm.. looking at the kmenu patch i really wonder if the DCOP signal shouldn't 
be attached directly to the RecentlyLaunchedApps (RLA) class. RLA should 
become a QObject subclass with a QValueList as a member which can be 
retrieved with an accessor.. i say this because right now when you pick 
something from the kmenu this happens:

kmenu (which is a PanelServiceMenu (PSM) subclass) item selected -> PSM::exec 
emits the dcop signal -> kmenu gets the signal calls -> 
PSM::updateRecentMenuItems -> calls a bunch of RLA methods 

in fact, it seems that PSM::updateRecentMenuItems(service) gets called twice, 
once by KMenu and once by PSM itself.

next time kmenu is opened -> KMenu::initialize() is called -> calls 
PSM::updateRecent() -> PSM messes around with the entries in the KMenu. there 
is no reason for this to be in PSM!

so it seems we have some very snaky code here. this problem obviously predates 
your patches. instead, i'd like to see this happen:

dcop signal is emitted (from minicli or PSM) -> RLA::applicationLaunched() 
called -> if it results in a change, emit RLA::recentAppsChanged() -> 
KMenu::updateRecentApplications() (moved from PSM) is called

much nicer, no? what do you think?

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20050602/5ffd88aa/attachment.pgp