Classic KMenu Extension

[Sebastian Sauer]

On Thursday 08 January 2009, Cyberbeat wrote:
> > Do you think it would be a good idea to introduce logic to disable or
> > even hide those both options if some other view like e.g. "logout" was
> > choosen where those options don't make sense?
>
> This option only affects the standard-menu. Perhaps greying out these
> options, if another menu-display is selected. Does really someone use these
> other view-options (recent/logout/.., they are easily integrated in the
> standard-view)?

y, e.g. me is using 3 instances; app, fav and logout :)
Anyway, sam is valid for the format-combobox. So, that can be still done 
later.

> > -    <signal name="cleanRecentDocumentsAndDocuments"/>
> > +    <signal name="clearRecentDocumentsAndApplications"/>
> >
> > That's a bit of a problem cause it changes the dbus-API. That would mean,
> > that e.g. scripts or applets written against <4.3 connecting with that
> > signal won't work any longer with 4.3 what is evil (specially since it's
> > a runtime-error probably hard to discover). But then I guess it's safe to
> > assume that noone outside of kickoff uses that signal yet. Anyway, I
> > would suggest to backport that fix to the yet unreleased 4.2 branch
> > before 4.2 is out and others may start to use that signal.
>
> I think escpecially for inter-program-communication, the correct naming is
> important, so better change early.

++
So, if you like to backport that part to the 4.2 branch and commit then please 
do else I can do that.

> > -    Q_ASSERT(maximum > 0);
> > +    Q_ASSERT(maximum >= 0);
> >
> > uh? Does it really make sense to allow to set 0 recent items? I would
> > suggest to use d->recentApplicationsSpinBox->setMinimum(1);
>
> why not? some people perhaps don't want their environment to log which
> software they use. This number affects the model (how many are stored in
> rc-file), not only the display.

Ah, got it :)
Well, for that we have kconfig/kiosk ( 
http://techbase.kde.org/Development/Tutorials/KConfig#Kiosk:_Lockdown_and_User.2FGroup_Profiles ) 
which does allow to prevent writing the recent apps/docs to the rc-file while 
preserving the functionality to display them in the recentmodel. I hope we 
will have the kiosktool ( http://extragear.kde.org/apps/kiosktool/ ) in place 
for 4.3 or 4.4 again to provide a UI for that. Meanwhile it can be done by 
editing the rc-file manual ( 
http://developer.kde.org/documentation/tutorials/kiosk/index.html ).
Anyway, to allow to enable displaying recent items with zero displayed recent 
items can't harm. What we can probably do is to remove the checkbox 
alltogether since it's equal to if 0 is set (seems we did the same in KDE3).

> > Sorry, probably a stupid question, but does that also affect the
> > recentmodel used in kickoff (so, not the classic menu)? If yes, then
> > that's a problem cause that option can only be changed in the classic
> > menu but is used at both of them. If not, then forget this comment :)
>
> yes, this also affects kickoff. that's what i mentioned in my last mail.
> This should really be changeable in both menu-configurations. perhaps it is
> possible to share common configuration-panels/logic?

Also the same is valid for "recent documents" what means, we would have 2 
additional spinbox's in both application launcher settings. So, y, would 
probably make sense to share some settings.