[Panel-devel] application menu and "utilities"

[Florian Merz]

Am Dienstag, 10. Oktober 2006 05:06 schrieb Aaron J. Seigo:
> On Monday 09 October 2006 18:40, Florian Merz wrote:
> > -  KDE Groupware Wizard, kprintfax, kjots, kalarm, kpilot
> > integrate into kontact (separate kpart or part of an existing kpart)
>
> kjots is an app people often use on its own. even if when it is a kpart,
> it's still a valid app on its own.

I guess you're right about this one. I still don't like the fact that there 
are two applications for taking notes, kjots and knotes.

> > kcolorchooser, kcoloredit
> > - unify them and integrate the functionality into koulorpaint and krita
>
> they are wrappers around individual classes in kdelibs. these wrappers
> were written for those who need/want a colour picker, for instance, but
> don't want to open an image editor and hunt around for how to get to one.

Still doesn't explain why there's two of them although they are almost the 
same... :)
I actually use it from time to time, but only because some other application 
(mostly the gimp, actually) doesn't provide the same feature. I'd rather 
have it be part of that other application because that would provide a 
better workflow, but I guess we can't fix every application that might need 
it.

> > - kruler, knotes, klipper, dictionary, ktimer, ktip, kpager, kcalc
> > turn into plasmoids
>
> for kpager this makes sense, for the rest it doesn't really. and if it
> did, it would only be redistributing the problem to another place on the
> desktop.

Look at http://www.apple.com/macosx/features/dashboard/ . A calculator, a 
notes wigdet and a dictionary are actually used by apple to demonstrate 
what dashboard is all about. If plasma is going into the same direction I 
think this would be the way to go.
If you place ktip as a plasmoid on your desktop you get a tip on every 
login. This plasmoid could be activated by default for new users. They get 
a tip on every login, but don't get an annoying pop-up. Doesn't sound that 
bad.
KTimer could be a dashboard widget designed like a stop watch (or rather 
some kind of countdown watch). If you need more than one timer, open the 
applet more than once. The user interface would change, but the 
functionality would stay more or less the same.

> > - kregexpeditor - edit regular expressions
> > move to extragear, though it's fine in the utilities menu
>
> and if someone installs it from extragear? how do we show it in the
> kmenu?

Keep it in utilities. If the user installs it from extragear he will 
probably want to use it, too, so it should be fine in the utilities menu.
We can't stop the user from installing too many applications and cluttering 
his menus on his own, but we can do something about the default 
installation.

> > - ktnef
> > drop it, integrate it into kmail or move it to kde-apps.org ;)
>
> same as some of the above apps such as kcolorchooser

The only way to be sure how many people actually use this would be a survey, 
I guess. There are quite a lot of applications like this on kde-apps.org, 
which seem to be useful for a relatively small number of users. I'd rather 
seem them move to extragear or kde-apps.org or something similar instead of 
keeping them in kde just because that's where they've been before and 
someone does actually use it. But If ktnef is actually used by a lot of 
people I'll apologize and take it all back.

> > - kiconedit, menu updating tool
> > drop them
>
> *raises an eyebrow*
>
> while i believe kiconedit has already been slated for the bitbin in kde4,
> we will need the menu editor.

Didn't know about kiconedit, sorry.
The menu updating tool is not the menu editor. The menu updating tool is the 
tool to import legacy applications into the kmenu. It creates .desktop 
files for those apps that don't provide any of their own. In the age of 
freedesktop.org those apps should be fixed to provide their own .desktop 
files.
Alternatively this could be integrated into the real menu editor so we get a 
central place to edit the menu.

> > - ark, ksnapshot, kgpg, find files/folder
> > leave them where they are or move all of them to the utilities menu
>
> these all seem to qualify as "applications" in terms of complexity and
> general usage

That's more or less what I was trying to say.

> > KFontView, for
> > example, could be a kpart for konqueror instead of a stand-alone
> > application.
>
> i'm not sure what the exact use cases are for this app; it's hard to say
> without knowing that. perhaps the author (craig drumond) might be able to
> shed light on it.

Far more interesting would be to know how most kde users use it, because kde 
is not designed for craig drumond (sorry, craig ;)), but for all kde users.

> > Kalarm seems to duplicate some of korganizers functionality.
>
> actually, it's used by korganizer.

I got a separate systray icon for korganizer on my computer. Is there any 
specific reason why it has two systray icons?

> > KFloppy should be launched from the media:/ ioslave instead of the
> > utilities menu. KJobView should be moved to the print:/ ioslave.
>
> again, i don't think this makes much sense. whether or not we need to
> have kjobview in the kmenu is another question.

There should be a floppy icon in media:/ if there is a floppy drive 
installed. Place KFloppy into the context menu of the floppy icon. That way 
users don't even have to choose which drive to format, because it will 
apply to the drive they selected.

> > It seems to me like there is no need to create a new menu/place/thing
> > to hold and manage these utilities. Most of them showed up in the
> > utilities menu because programmers didn't realize the right way to do
> > it or the right way just didn't exist when the program was created.
>
> most of the utilities are there for specific use cases. those use cases
> don't go away just because we wish them to. and i'm not overly
> comfortable with the idea of simply removing these things for the sake of
> simplicity.
>
> if we can think of a better way of presenting them so we don't have to
> get rid of them altogether, that would be a much better win imho.

What about porting them to python or ruby and make them installable via 
gethotnewstuff? That way they are still available for those who actually 
need them and kde could add even more utilities to the ghns repository.

> > There is some danger, that moving many of these utilities over to
> > plasma might not solve the problem, but instead move the problem to
> > somewhere else (namely the plasmoid selection dialog). IMHO this
> > shouldn't be a problem in the near future as there should't be as many
> > plasmoids distributed with kde as there are applications right now.
>
> assume there are as many plasmoids as there are panel applets now. it's
> not a pretty result.

The current panel applets (in kde 3.5, don't know about kde 4) are presented 
as a simple unorganized list. If they were organized in categories it 
should be slightly better, though not a real solution, I guess.