[Panel-devel] application menu and "utilities"

Florian Merz FlorianMerz at gmx.de
Tue Oct 10 18:51:22 CEST 2006


I cc'd Craig Drummond because of the kfontview issue.
Craig, can you please shed some light on kfontview use cases. It would be 
nice to be able to replace the application with a kpart so fonts can still 
be viewed when browsing fonts:/ (or other directories) but we don't have a 
separate entry in the utilities menu. Is there any reason not to do this? 
For example being able to open fonts directly in kmail?
If a kpart alone is not enough, would it be ok to remove the entry from the 
applications menu and make fontview a 'hidden feature'?

> > Still doesn't explain why there's two of them although they are almost
> > the same... :)
>
> yes, they could be combined. kcoloredit has a number of visual bugs and
> is something of a usability nightmare. if someone showed it some love and
> allowed switching from a more simple kcolorchooser type interface to the
> full "edit a color map" (which is what kcoloredit is for) we might have
> something nice indeed...

I just had a closer look at kcoloredit. It could be turned into quite an 
interesting application. Something inspired by 
http://wellstyled.com/tools/colorscheme2/index-en.html and 
http://wellstyled.com/tools/colorscheme/index-en.html would be really 
amazing. Especially the feature to display the colors like colorblind users 
would see it is really cool.
I wish university wouldn't keep me as busy as it does...

> > > > - 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.
>
> the dictionary i can buy. i'm on the fence with the other two. i have a
> niggling feeling that there are valid use cases that preclude this
> approach.

You got a point. I'd rather see kcalc be replaced by speedcrunch, which 
wouldn't work as plasmoid at all. So I guess kcalc isn't really I candidate 
for plasmoids after all.

> what i'm wondering is if we can do something about the case where people
> do install all the apps they need to be productive. it's a bit crappy
> that we say "well, it works if you don't install a bunch of apps" to
> which the user says "but i use all these apps!" to which we say "well,
> then it sucks to be you!" =)

Either you have a few applications that do quite a lot or you have many 
smaller applications that are good for single tasks. The first one makes 
individual  applications harder to use, the second one makes searching for 
and picking the right application for the task at hand harder to do. Let's 
see what raptor brings.

> ktnef is probably a good candidate for extragear, assuming it isn't used
> externally by one of the core apps (such as knode or kmail?) though i
> don't think it is since there's a tnef library in kdepimlibs...

I agree.

> > > > 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.
>
> but the author usually knows what the use case is. and often that comes
> from users. so asking the author is a good way to find out what the
> intentions and real uses are.

I cc'd Craig. Let's see what he has to say about this.

> ah, sorry, i read that as "kalarmd". kalarm itself is a cute little app
> to set, well, alarms. quite simpler in scope than korganizer. should this
> also go to extegear? *shrug*

Maybe not. Dunno.

> > > > 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.
>
> i have no issues with having it launchable only from an icon representing
> the floppy disk ... but that's a bit different than making it specific to
> an ioslave.

Yeah, sorry, what I wrote definitely doesn't read like what I wanted to 
write :)
I didn't want to make it specific to the ioslave, just specific to the 
floppy icon.

> essentially your suggestion is to hide these apps from the menu and only
> have them launched from apps that need them, correct?

Well, yes. Unfortunately this might introduce different issues: A user might 
say "I know I used an application to format a floppy disk some time ago, 
but now I can't find it in the applications menu.". On the other hand I 
don't even know if users would actually realize this is a separate 
application at all.


More information about the Panel-devel mailing list