[PATCH] new method kstdguiitem::preferences?

Martijn Klingens klingens at kde.org
Mon Sep 22 20:19:43 BST 2003


On Monday 22 September 2003 10:11, Stephan Kulow wrote:
> On Sunday 21 September 2003 15:03, Martijn Klingens wrote:
> > And yes, I know we're in a freeze, that's why I'm posting here. Ok to
> > apply?
>
> Apply and make sure not only kopete uses it :)

Hmm, grepping around the KDE sources for the use of "configure" like strings I 
mostly find the following cases:

- [QK]PopupMenu. There's no KGuiItem support there. It can be added of course,
  but I think it's better to wait with KDE 3.3 for that. I volunteer to do the
  work then; if it is to be done for 3.2 my schedule won't allow it so someone
  else needs to step up in that case.

  One could of course argue they should use KAction in the first place, I
  don't know why they use insertItem() directly instead.

  Examples: Klipper, Kicker.

- Actions that need a custom string. I could change KStdGuiItem::preferences
  to take a QString and use it instead of what KAboutData provides when not
  null, defaulting to QString::null.

  Additionally an empty (but not null) QString can be used as shorthand for
  "Configure..." to allow some more code to use the method.

  Examples: Kicker (again), KDesktop, KitchenSync

KMail, KNode and KAddressBook seem to be candidates for the KGuiItem 'as is'.

KNotes, KPF and others use a string "Preferences...", I'd say that should 
become "Configure KFoo" instead for consistency.

What should I do? Commit the original patch? Add the QString parameter? If so, 
add support for empty QStrings?

If the change goes in, can I convert the mentioned apps? Or do I need to mail 
each maintainer individually for approval? Or can I leave it as exercise for 
the reader and just make Kopete use it?

-- 
Martijn




More information about the kde-core-devel mailing list