[Portland] Screen saver questions / proposal

[Aaron J. Seigo]

On Wednesday 25 April 2007, Jeremy White wrote:
> I'm packaging up a single application.  I would rather, and I believe
> most sysadmins would rather,

i'd dispute the latter since according to feedback i receive from real-world 
sys admins, dealing with the .menu files is already overly tricky and adding 
more twists and turns to it (e.g. "these are screensavers, you want to define 
them not to be in your menus by doing this..") isn't a good direction.

> that I deliver all of my 'launch' related 
> .desktop files in a single bundle - that is easier to manage, imho.

seeing as we already segregate different types of data, e.g. icons for a 
trivial example, i don't see the issue.

> Now, from your perspective, the problem is different; you have
> buckets and buckets of .desktop files, and keeping them clean
> and well organized is a challenge. 

i actually see this as a shared "problem". if the platform becomes unwieldly 
and grotesque, i'm not sure how you as an app developer benefit. uglifying 
things for the benefit of your screensaver also seems disproportionate of a 
response. i'd like to see this canonicalized within xdg-utils, and i'd like 
to see recognition of share/services be made as it is a non-theoretical, 
well-working solution.

> But I don't see why Screensavers can't 
> simply go in a subdirectory 'Screensavers' under the desktop menu
> heirarchy. That seems quite organizationally clean to me.

because, as i already noted, screensavers don't belong in an application menu. 
you're confusing "a dumping ground for .desktop files" with "where we store 
application entries".

> Or, alternately, you can preserve your packaging and put everything
> into the new services/ directory,

well, share/services actually predates share/applications.

> but then, imho, you should make sure 
> to put that directory into one of the env variables specified by
> the menu spec, and you should *allow* screensavers put in the regular
> desktop heirarchy to work.  Why should a service *have* to go in a
> specific place? 

why should anything have to go in a specific place? ;) 

yes, i suppose we could say "put anything you want anywhere and our code will 
manage all the various possibilities, even if nobody actually uses them" but 
i hope you'd agree with me that that would lead to a very hard to maintain 
and ultimately brittle system, not to mention one whose performance and 
manageability would decress. i doubt you'd allow such a design perspective to 
enter into your own software projects.

> The whole idea of the new desktop spec, I thought, 
> was to get away from the bad old days where location on disk affected
> system behavior.

the whole idea was to provide a way to easily add new application entries 
while making it possible to define how they are displayed to users (including 
multiple layouts) that worked with all desktop environments. this is a 
slightly different purpose.

> >>And, again, you've replicated the entire problem sequence we had with
> >>the .menu desktop files - the algorithm to figure out where to put them
> >>is annoying and desktop specific.
> >
> > actually it's pretty simple, much simpler than the app menu issue since
> > we don't have the need for multiple presentation options of the same body
> > of data; they are all screensavers, the most we care about is "show
> > opengl savers, or not" (for instance). and since screensaver .desktop
> > aren't cross desktop right now anyways this becomes even less of an
> > issue.
>
> Um, except that Gnome does it differently from KDE, and we're

this was already the case, of course.

> back to the same old same old nasty problem of having to write special
> purpose code that drives me to distraction.

i'm bringing this up some 6 months prior to release so that we might be able 
to -avoid- that by providing you with tools that will work.

> And where those files went was *not* an obvious extension of the current
> location, in my rather useful lay person (read: ignorant) perspective,
> and the xdg-util tools  were not extended to take advantage of it.

we're 6 months away from release of 4.0 here and this was only recently 
figured out. so what you suggest would have been premature. i brought it up 
on the list specifically to that we can address these issues in xdg-utils, or 
wherever else it makes sense.

> (Okay, I'm just surly because I had to do a
>   find / -type f -exec grep -iH <known-screensaver-name> {} \;
> in order to find where the heck screensaver files went <grin>).

oi vey! well, that's what mailing lists are for; i'd have been happy to point 
you in the right directions, as would many others i'm sure =) working in 
isolation is surely frustrating, i can understand that.

btw, we are trying to document these designs much better within kde through 
the TechBase initiative. we have the start of a page here:

	http://techbase.kde.org/SysAdmin/KDE_Filesystem_Hierarchy

on this. i have noted for future work here that we need to be much more 
explicit as to what exists in, for instance, share/services. probably with 
a "reverse lookup" as well so one can search for "ScreenSaver" and find that 
those go in share/services.

i also do wish that other desktop oriented projects would leverage the build 
systems put together by the desktop environments as we embed pretty much all 
of this knowledge within them. that's another topic, of course, and it 
probably requires us documenting our build systems and making them suitable 
for use by others. i think cmake is a nice step in that direction, though.

> And I'll bet you money that one or more of the major WM environments
> will change the location of those files in the next rev or two, and
> any code I write now will be obsolete shortly.

i would agree with you that expecting each ISV to write this code themselves 
is not desirable. that is the point of xdg-utils.

> We worked long and hard to build what I think is a good set
> of standards around .desktop files and where they go - why
> aren't we using them?

a) we are, in that we're using .desktop files for the screensavers
b) the standards really didn't cover these things. you may have noticed that 
in kde2 and kde3, the screensavers were kept in share/applnk, for instance.

> >>I suppose you could modify xdg-desktop-menu to take a --screensaver
> >>option which would 'know' to manipulate things in an alternate
> >>directory, but that seems wrong to me.
> >
> > remind me why you want to show your screensavers in the application menu?
>
> My application is capable of being *either* an app or a screensaver.

btw, which app is this? i'm interested in use cases.

> A single .desktop would encapsulate it neatly, but you've designed
> out that possibility.

yes, it is usually poor idea to optimize for irregular situations.

> > to me it makes much more sense to define the type of service
> > (e.g. "ScreenSaver"), categories and additional (potentially app
> > specific) details in a .desktop file and put all of those in a separate
> > share/services/ directory which serves as a sort of registry for these
> > kinds of things.
> >
> > it keeps apps and services/plugins/protocol definitions separate (aka
> > "user relevant info" vs "implementation details") and allows for rather
> > more interesting discovery/querying for these kinds of things.
> >
> > we can, of course, hack things into share/applications. it's just not
> > particularly elegant or scalable.
>
> Sure; instead of a '--screensaver' option, we could have a '--service'
> option. Thus, a regular in menu desktop file is installed with
> xdg-desktop-menu, and a special 'services' .desktop file is installed with
> the --service option. Alternately, you could have a xdg-desktop-service
> utility with the same basic behavior as xdg-desktop-menu.

the latter sounds more sane imho, and a good approach.

> Note that I'm not in favor of that proposal, but if the service .desktop
> files are to be segregated, then I want an xdg-utils way to manage them in
> order to preserve my sanity.

i think a point of confusion here may be that you see all .desktop files as 
equal and the same. they aren't. .desktop is a file format which can be, and 
is, used for a variety of different and valid purposes. one of those purposes 
is to notify the desktop of the presence of an application that should be 
visible to the user in, for instance, an applications menu or launcher area. 
it is not the only use case of .desktop files, however.

-- 
Aaron J. Seigo
humru othro a kohnu se
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: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/portland/attachments/20070425/f5dd04ac/attachment.pgp