Re: Re-inventing Metatheme
- From: Rodney Dawes <dobey free fr>
- To: snickell stanford edu
- Cc: Bill Haneman <bill haneman sun com>, calum benson sun com, desktop-devel-list gnome org
- Subject: Re: Re-inventing Metatheme
- Date: 27 Aug 2002 19:43:59 -0400
On Tue, 2002-08-27 at 14:40, snickell stanford edu wrote:
I have mockups for this stuff I did a few months ago, I'll dig them out
when I get home tonight (if I remember, ugh, sticking a post-it note to
my doorway ;-).
1) It would be good to integrate "editing" with the general theme
selection feature rather than treating themes as some big complicated
thing you need a seperate editor for. This makes theme "sets" (I like
this term, its good because it gently exposes the idea that these are
composed of sub-themes without bludgening the user with the concept).
I'm not sure we need the idea of "customized" themes so much. I would
propose that rather than adding the complicated of save, etc, we just
make changes happen. Having revert there to revert to the theme's old
behavior seems fine.
I hope this doesn't mean there shouldn't be a separate editor. Some
themes are *much* more complicated than they may look, especially
when talking about Sawfish. Making changes happen, and saving those
changes, are very different activities. Making things change is just
a matter of setting GConf keys. We *SHOULD NOT* be writing random crap
to some theme installed in ~/.themes/ that they may be using, or even
worse in $(datadir)/themes/. If a user wants to save a theme, they
should have the option to name it, and do the actual saving, by creating
a new theme in ~/.themes/ (or $(datadir)/themes/ if root). We should
also try to prevent duplication in the list, by checking if a theme is
already listed (ie, if it's in the system dir), and not allow having a
theme of the same name in ~/.themes/, that contains the same type of
theme information. If one has a metacity theme in ~/.themes/ and a gtk
theme of the same name exists in $(datadir)/themes/, then that is fine,
as you won't have two entries in the same list, which can cause major
problems (ie, the first one in the list is the only one that ever gets
used). However, the UI was not the original target of this thread.
2) Should provide a way to open the user's themes folder for copying new
themes in. Themes should also be readable directly from tarballs so the
user doesn't have to worry about unzipping them etc. Drop and go is a
nice ideal here.
I think this is bad UI. Having a link to "Open random folder" is odd.
Users will click on it, and either see none of the themes that are
installed, or just not all of them. Imagine being a new user, and you
click this button, and you see none of the themes you have installed.
It's totally unintuitive, and very confusing for new users. Again,
though, the UI is not yet my target.
3) I can't put my finger on it, but the current layout proposed there
looks rather messy. Its heavy on frames, and low on alignment :-)
It's proposed. It's also evident that this thread is heavily diverging
from it's original intent now. I meant to discuss the architecture and
directory layout of themes, and not the UI. They are very different
problems. If we have no standard for where to put themes, it is harder
to actually use them.
4) Metacity and GTK themes both change very quickly (plenty fast enough
for instant apply). Nautilus themes should, though I haven't checked
recently.
5) I was just going to propose the list with small versions of the
previews when I reread your message and noticed it was there ;-) Its
always nice to provide information to the user as early as possible
rather than making them select things to "find out". I think this isa
good idea.
The UI should be discussed later, really.
6) It would be nice to have a way to export theme sets in a single
package that includes all the sub-themes (and not just referenecs to
them), so people can easily share them.
There is an easy way. The "Save" button. Assuming gnome-vfs supports tar
and bzip2/gzip, this will be even easier to do, as would having themes
not require to be unzipped (though, that may pose a problem for gtk+).
-- dobey
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]