Re: cleaning up themes

On Sun, 2005-07-31 at 00:36 +0100, Mike Hearn wrote:
> >> That's incredibly lame, it'd be better not to give one-click installs at
> >> all if it'll randomly fail on the hottest new themes.
> > 
> > It won't randomly fail, it would warn the user I hope.
> I meant it'd randomly fail from the users perspective, because there's no
> way to tell ahead of time if a new engine is used or not.

The entire point of Thomas's proposal is to tell ahead of time if a new
engine is needed or not. It is a minor implementation detail to read a
small file off the server, and check for the engine.

> > Because there is no standardized packaging format and distribution
> > method
> Theme engines are usually just DSOs right? Or at least, if they
> include extra data that can be compiled in to make it a single DSO. That's
> one file, which can be installed to a known place that can be determined
> easily at runtime (at least on Linux). So it would definitely be possible.

So I should be able to take any single binary DSO object, and shove it
on any other random linux install on any random hardware, and it should
work? Anything is technically possible here. Nobody is questioning
possibilities. What is being questioned, is correctness, and making the
whole general bit of random stuff of the internet that comprises the
realm of Open Source/Free Software, into something that a user can
easily deal with and enjoy. If we do make it possible to install the
engines themselves, I can tell you right now that is not
going to be the only place providing them. And given the huge dive in
control of such a format, it is not particularly reasonable to assume
that it will Just Work (TM).

> > and beyond that, the distributions that do use the same package
> > formats, often have different policies for where things actually go on
> > the filesystem?
> Themes are always installed to the same place relative to GTK+ itself
> though.

But you are not sure where GTK+ might be. If you are unsure where GTK+
is, and of the environment in which you are installing things, how can
you reasonably guarantee that it will work.

> > And no, autopackage is not a solution for it. Most people do not have it.
> It installs itself the first time you use it (by running the package).

> > Adding yet more places for a user to have to look
> > to see what versions of software they have, what upgrades are available
> > (which will cause a LOT of problems, as software will be in one
> > database, but not the system packaging db), and other such utilities,
> > will just add confusion to the process.
> There's no fundamental reason why autopackages (or .themes or whatever)
> can't update themselves automatically and use the system database instead
> of a separate one, it just hasn't been done yet.

Then there's no fundamental reason why we can't just provide packages
that are actually intended for the system they are being installed on.

> And how important is it that themes are upgraded automatically anyway?
> They aren't security-critical. Is it really more important than easy
> one-click installs of new eyecandy (which is a nice end user feature)?

I said nothing about updating automatically. I was talking about where a
user would go to find updates. If it happened automatically. Easy
one-click installs of new eyecandy really isn't that important anyway.
Most distributions ship most theme engines anyway, and a lot of extra
themes. I think it's more important to get a nice "theme editor" UI
in the control center, for users to set the appearance of their desktop.
One-click installs would be nice, sure, and I would support doing it, in
the right way, that will work for everyone on all architectures. Another
thing to remember, is that not all Gnome users are Linux users. Solaris,
BSD, and other systems have plenty of users are Gnome users, too.

Can we also please stop painting this shed in a thread about
gnome-themes maintanence now? It's not really appropriate. If you want
to continue the discussion of themes distribution, feel free to move it
over to gnome-themes list. Thanks.

-- dobey

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]