Multiple DeskTops, HiColor theme, standardized icon names, & menu icons

[Aaron J. Seigo]

On Wednesday 28 June 2006 17:50, Rodney Dawes wrote:
> On Thu, 2006-06-29 at 00:49 +0200, Thiago Macieira wrote:
> > Sorry, I completely disagree.
> >
> > Why should application A care about application B's private files? They
> > are *private* so they can:
> >
> > a) disappear from one version to the next
> > b) change names
> > c) be in a completely different format
>
> Nobody said that application A would care about application B's private
> data, or even implied that it would. What application A does care about,
> is that it doesn't conflict with application B's data, by installing a
> file of the same name into the same location (hicolor). These icons need
> to be themable, the same as the rest of the icons in an application.

sure. which makes the conversation about share/apps/$APPNAME/* moot since 
application A shouldn't be installing files into there.

> > What I do agree is that an application should be reserved one directory
> > where it can store any kind of file it wants, in whatever layout it
> > wants. The FHS already describes two possibilities already:
> >
> > /opt/$appname
> > /usr/share/$appname
> >
> > I think the second option is inefficient if we take into account the
> > number of applications that get installed. We confuse /usr/share/$concept
> > with /usr/share/$appname.
>
> They are no more confused they they are now. You can't possibly tell me
> that share/apps and share/applications isn't confusing. It is the very
> definition of the word.

hint: which came first? so which was the stupid decision? that's right: 
share/applications. doubly so since it's where .desktop files go. it probably 
would've made more sense to call it "menu-entries" or "app-desc" or something 
more fitting. particularly since share/apps/ was already there.

moral of the story: think twice before writing specs.

> > PS: like Waldo said, KDE was meant to be installed in /opt/kde,
> > so /opt/kde/share does not follow FHS and should not appear
> > at /usr/share.
>
> While KDE may not have been meant to be installed into /usr 8 years ago,
> the option to do so, should not be disallowed. KDE is a lot of things it
> wasn't meant to be, 8 years ago. KDE needs to become a fully integrated
> piece of the desktop. We shouldn't be treating it specially because of
> what someone wanted some piece of it to be like, 8 years ago. It should
> be a part of the creation of specifications for all desktop
> environments, and an example of implementation to them, as well.

this paragraph is why i entered this thread, to be honest. to even _hint_ at 
the idea that kde, the desktop that actually largely defined the icon spec we 
currently have (not to mention many other specs, and the first desktop to 
adopt dbus into its foundation to take another pretty obvious example) is 
pretty low brow.

we are all about taking part, indeed leading, when it comes to cross-desktop 
efforts. and we back that up with years of effort. so perhaps there is 
another reason there is push back on this? e.g. it doesn't make a whole lot 
of sense.

meanwhile the above "let me admonish you" crap is really not helpful.

as for the "it wasn't meant to be installed to /usr 8 years ago" idea, i'd 
add "and it's worked really, really well ever since". we have a lot of users 
who have learned this system and we have a lot of code that works well with 
it too. unless there is a -very- good reason for moving this around, you're 
going to be met with a lot of blank stares. note that this change would 
result in either a less-consistent set of paths for KDE users and sys admins 
since we use it for a lot more than just icons; moving share/apps/* to just 
share/* would make share/* a nightmare.

cross-desktop standards should result in simpler models for those who manage 
these systems. standards that don't do that are failures for the people who 
matter the most: our users. adding this to the icon spec would make it a 
failure by this metric.

and here's a real shocker: perhaps the FHS, which was designed for servers, 
doesn't make much sense for -desktops-. it seems we constantly get caught up 
trying to shove our software into models that make the engineers and all the 
world's spec writers happy but which continue to piss off our users. our 
priorities here, to make the desktop better for users by making it more 
consistent, seems to have gotten diluted (or on some completely lost).

</rant>

-- 
Aaron J. Seigo
Undulate Your Wantonness
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: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20060628/7994223f/attachment.pgp