[Portland] Screen saver questions / proposal

[Aaron J. Seigo]

On Wednesday 25 April 2007, Jeremy White wrote:
> >> 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.

this could be because i get to deal with far more different types of .desktop 
files than you do given where i work in the stack, and so have a broader 
perspective on the issue. i also get to deal with people who manage large and 
small installations of KDE.

i fully understand how from your perspective it seems straightforward, but the 
larger picture from which those of us working on the platform are required to 
face makes it less so. we have .desktop files for mimetypes (though we've 
replaced that in kde4 with the fd.o mimetype spec; woohoo!), servicetypes, 
services, kio vfs protocols, applications ... other files are very similar 
such as the index.theme files in icon themes (same file format, doesn't have 
the standard [Desktop Group] however).

as a platform, we have to support not only your needs, but the needs of 
thousands of others who also write applications for the platform. 
unfortunately the obvious answer for one person's needs doesn't always extend 
to the sort of solution that works out in the best interests of others. we 
all share this platform, including with the people who manage installations 
of it. so .. we try and exercise some respect of that and design not just for 
the "simple and obvious hack", but for structure that just might survive 
while annoying the least number of people and satisfying the greatest number.

seeing this is about 1 .desktop file in your case, this all seems a bit over 
the top =)

regardless of this discussion, there isn't any one place you can put 
your .desktop file today. so we will want an xdg-util for installing a screen 
saver .desktop file. which makes the discussion about the future somewhat 
moot from your perspective since you'll probably continue to use that xdg 
tool in the future and won't particularly notice the change in location when 
it happens *knock on wood*.

the salient point here is whether in the -future- we should put them in 
applications/ or in services/. that's probably a discussion for the xdg list 
on fd.o. i had some preliminary discussion a few months back with a gnome 
developer who works on their screensaver support about it and iirc we got 
through most issues (mostly content of the .desktop files) with the on-disk 
location being one that we didn't get to.

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

reading from services/ is, from the application code, identical to reading 
from applications/. the difference is that instead of using Categories= it 
uses ServiceTypes=. the service types are then registered by applications in 
servicetypes/, allowing for runtime expansion of the known plugin types.

but yes, we use essentially the same code to load and cache both sets 
of .desktop files.

in both the applications/ and services/ cases you get a KService::Ptr back, 
and in the services/ case you can do some pretty nice querying via 
KServiceTypeTrader.

by putting screensavers in two locations, which is what the bit you were 
replying to was referring to, applications would then need to look in two 
different locations. by putting them all in applications/ we end up with 
other un-niceties as already described.

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

to accommodate a path forward from what we had been doing (putting screen 
savers in the applications menu). in retrospect, this doesn't seem like the 
best idea in the world.

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

=) still lots to do; more information is needed, the page is still a bit messy 
(particularly the tables) .... but getting all this stuff in one place is 
imho very important to supporting both our own as well as 3rd party 
processes.

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

yes, it's in System/ScreenSavers on all systems. share/applnk is just the top 
level =)

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

i am aware that 3.5.x is considered the current newness for the user and 3rd 
party developer population. and it will be for some time even after 4.0 is 
out due to the timescale of deployment upgrades (3-5 years)

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

ah, cool.

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

how does it not extend to real world use cases? you can precisely achieve what 
you want. this seems like quite a bit of push back over one .desktop file.

p.s. you don't need to cc me on replies =)

-- 
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/20070426/901d34c4/attachment.pgp