>> It should be a simple thing to code as well, the current desktop
>> ioslave uses it's platform based code to determine where the desktop
>> should be ~/Desktop on unix for example, we'd just give the user the
>
> that path is customizable in system settings.
True, but that's a global setting, there is no way to have desktop:/
method of viewing set to an arbitrary folder in a specific instance.
>
> but before considering doing something to desktop:/, it might be good to back
> up a step and ask "what is actually trying to be achieved, and how can it be
> achieved with as much consistency as possible"

Well, I propose desktop:/ because it's already there and does almost
exactly what I am thinking off here.

Let me explain the situation I am working on - one that I'm sure many
other people will also  encounter (sooner rather than later). I am
encountering it from a distributor's perspective, but the same desire
is very likely I believe to be found by users on an individual basis
as well.

Most desktop systems for some time has had some or other method of
adding a custom menu to give instant access to a set of grouped
applications. In the gnome 1.0 days, this was done with it's "drawer"s
applet for example, RoX and others all have similar things, KDE3 had
quick-browser (which was actually a lot more than this but handled
this nicely as well).

One such example is a dedicated menu for a group of configuration
mini-programs. In kongoni's case, we have KISS which is essentially a
wrapper around a number of common desktop setup tasks that don't fit
well into systemsettings (or aren't there - period) and probably
shouldn't be there anyway since (1) they are desktop-agnostic and (2)
they are very platform specific.

The structure we have consists of a directory under /usr/share/kiss
which holds the actual programs, and another KISS\ Menu which holds
desktop files to launch them correctly. Taking care of things like
"run-as-root" using desktop files is just smart, as it means you get
fairly seamless integration into the user's chosen desktop - without
any additional coding on our side.

So if you browse the path in dolphin - it works fine, but you get the
.desktop filename, not a major problem, but aesthetically not very
pleasing. We could of course just put all those things into the System
menu... but that clutters it up with a bunch of extra menu items that
really are rather simple- it's n ice to group them somewhere special,
and also highlight their presence (the items in KISS are basically the
easy answers to about 99% of our FAQ's).

So what I would like, is an icon on the taskbar, which - when opened,
lets the user browse the KISS\ Menu Folder and subfolders in a
menu/desktop like view - showing the shortcut names, rather than the
actual filenames.
The first thing I tried was an embedded lancelot part, this did in
fact show exactly what I wanted - but lancelot parts take their path
from a drag-and-drop operation - and do not remember them between
sessions (Ivan, if you're reading this - is this a bug ?)
That means ... you can't preset a lancelot part with a certain path to
be on the default desktop the user will see on his first login.

Currently I have a folderview set up - this does everything right,
remembers the path etc - but shows file-names rather than menu names.
This is what the next release will probably ship with however, until
such time as a better solution is present.

The thought that came to me based on this thread was that an ideal way
to tell the system how you want to view the items is indeed with
ioslaves, and since the desktop ioslave does almost exactly what I
need, I asked about possibly adding the one thing it is missing (that
being to specify  a different path for a specific instance).
This may not be the right answer, the right answer may be something
like a whole new ioslave menuview:/  ?
It's just the easy one :)

Of course - I'm very open to suggestions, this is a use-case I'm
dealing with, but it's not specific to what kongoni is trying to use
it for. I was setting up drawers (or whatever you want to call them)
with quick-access menus for common apps grouped together as part of my
daily-work deskop in windowmaker 15 years ago - and it's an approach I
like (in fact, I like it a LOT more than a bunch of shortcuts on the
desktop).
>
> one of the tricks with application launchers is that they should probably go
> away when the application does, for instance. or if referring to a system
> application (versus a custom launcher), if the system application entry
> changes, that should be reflected in the user's launcher as well since it
> represents "that application" not really "that desktop file".
>
> i'm not sure having files on disk is a good idea at all in those situations,
> but if they are on disk then they probably should be managed in a way to
> create a seamless experience.

Well this is going more into your territory - I see your logic, but
I'm not qualified to make any constructive comment on this part
(simply because you know this stuff way better than I do).

So...perhaps the question I should be asking is: how SHOULD I be doing this ? :p
-- 
A.J. Venter
Tel.: +27 21 554 5059
Fax: +27 11 252 9197
Outkast Solutions IT
www.outkastsolutions.co.za
A division of Global Pact Trading Pty Ltd.

www.silentcoder.co.za - Blog
scartoonz.silentcoder.co.za - ScarToonz webcomic
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<