Multiple DeskTops, HiColor theme, standardized icon names, & menu icons
Aaron J. Seigo
aseigo at kde.org
Thu Jun 29 07:06:24 EEST 2006
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
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).
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
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20060628/7994223f/attachment.pgp
More information about the xdg