[Panel-devel] application menu and "utilities"

[Aaron J. Seigo]

On Tuesday 10 October 2006 2:55, Florian Merz wrote:
> 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.

they work completely differently. that's why we have 2.

> > > 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... :)

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'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.

there are people who use it outside of any application. think of people 
writing HTML using kwrite who need to know a hex colour. i actually wrote 
something exactly the same as kcolorchooser (though never thought to plague 
kde with it ;) for my g/f at the time who was doing exactly that (well, using 
nano rather than kwrite)

> > > - 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.

> 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.

yes, this is a good idea =)

> 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.

we'll see how the whole plasmoid thing takes off.

> > > - 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.

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!" =)

> > > - 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.

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... 

> > > - 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

ah, kappfinder. yeah, that's probably a nice candidate for extragear as well.

> > > - 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.

sorry, i was agreeing =)

> > > 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.

> > > 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?

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*

> > > 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.

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

> > > 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.

yes, we need to organize them into categories. that much is evident. (though a 
different topic =)

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20061010/4f6f1301/attachment.pgp