[Portland] Screen saver questions / proposal

[Jeremy White]

>>
>>Um, but isn't that the whole purpose of the NoDisplay key in the .desktop
>>file?
> 
> 
> not really, unless the application menu is intended to become a dumping ground 
> for every application's plugins, add-ons, protocols, etc. these are 
> application specific details and therefore shouldn't need to be waded through 
> by sys admins or dealt with in .menu files; shoving everything possible into 
> share/applications/ is perhaps "easy" but it's also pretty disrespectful of 
> a) the intended problem being solved and b) the people for whome the solution 
> was designed for.

I think a lot of our difference in opinion comes from our perspectives.

I'm packaging up a single application.  I would rather, and I believe
most sysadmins would rather, that I deliver all of my 'launch' related
.desktop files in a single bundle - that is easier to manage, imho.

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

Or, alternately, you can preserve your packaging and put everything
into the new services/ directory, 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?  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.

> 
> 
>>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
back to the same old same old nasty problem of having to write special
purpose code that drives me to distraction.

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.

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

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.

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?

> 
> 
>>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.
A single .desktop would encapsulate it neatly, but you've designed
out that possibility.

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

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.

Cheers,

Jeremy