[Portland] Screen saver questions / proposal

[Jeremy White]

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

Sure; that's the fundamental divide.  Agreeing with your comment below,
I see .desktop files as all the same, and hence I want to dump them
in the same place.  Or I could say that more graciously - I like that
screen savers use the same file format, and so I want to also treat
the file itself the same way for installation.

To me, that seems natural and intuitive; you clearly don't see it that way.


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

I realize I don't know the code here, but I find that hard to believe.
How is "snag all category=screensaver from the already in memory list" worse
than "go read this list from this other file location, and oh by the way,
make sure you remember all the tricks needed to read them from disk right."

And, pushing a bit further, to an outside viewer, that appears to be the clear
design intent of the .desktop files.  Otherwise, why have a Category=Screensaver at all?


[snip]
> 
> 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

That is really great!  I've never felt that those things were well
documented, and it's good to see a start.

[snip]
> 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.

Yah, I just noticed that (in fact, it's worse, it must be in
share/applnk/System/Screensavers, at least on Fedora Core 6).

As a tangent, I consider KDE 3.5.6 to be new and bleeding edge.
I realize that's a different perspective from what you have, but
there you have it.  As an ISV, I care primarily about what the
majority of potential users already have in the field.

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

Picasa.

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

Hrm.  I'd counter that it's a poor design that doesn't elegantly
extend to real world use cases.


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

Well, perhaps; I'd like to hear from Gnome and XFCE (and other?) folks;
I have no clue if Gnome is going this same 'Screensaver is a service'
direction or not.

Also, this may be somewhat awkward, as the XFCE folks seem to be sticking
mostly with xscreensaver, and it's configuration process isn't really
well encapsulated with a .desktop file.

Cheers,

Jeremy