Re: Gnome 3 Extensions/Themes Website?

["Jasper St. Pierre" <jstpierre mecheye net>]

On Thu, Jun 9, 2011 at 11:01 AM, Dotan Cohen <dotancohen gmail com> wrote:

On Thu, Jun 9, 2011 at 00:14, Jasper St. Pierre <jstpierre mecheye net> wrote:
>> I hope not. Themes alter the presentation of an application,
>> extensions add functionality. That is an important distinction, in
>> fact technologies such as CSS have been invented to create this
>> distinction where it once did not exist (SGML, HTML).
>
> OK, then we can axiomatically put extensions into two categories: themes and
> functional, based on the existence of scripting.
>

I see where you are going with that, but I think that the word
"functional" shouldn't be in the UI. How about instead of having
"extensions" which are divided into themes and functional, there be
"addons" which are divided into themes and extensions. That is the
Mozilla terminology, by the way, which will lead to a smoother user
experience using Mozilla apps in Gnome as the same terminology will be
used for the same ideas.

I'm not saying we should expose the word "functional" to the user. In fact, the "extension is a theme" is just a way to consolidate two extremely related mechanisms. Ideally the user would never have to know that a theme isn't an extension -- the fact that we can implement both using the same underlying extension system is just some unimportant details to the user.
 
Right now, I think the best way to "flag themes" as so would be to give them a special UUID namespace, like "Elementary themes gnome org".

> But still, with new code such as the shell, the CSS support isn't as good as
> browsers so there may be quirks or workarounds that need code.
>

That is where browsers were not so long ago, and some still are today.
No problem.

> I thought about ensuring that extensions "marked as themes" cannot have any
> code at all, but that unfortunately excluded the use cases above.
>
>>
>> What benefit do you envision by removing this distinction?
>
> I want to reduce the amount of support code required to support both themes
> and extensions.
>

But that is confusing because the user expects his configuration to be
organized, hierarchically or otherwise. Even if the underlying code is
the same, the action of enabling/configuring them must be distinct.

Of course. I'm not suggesting removing the distinction from the user. You switch themes, you don't switch extensions. You enable extensions, you don't enable themes.

> From a user's perspective, installing both should be one button to click.
> Changing themes may be different than enabling and disabling extensions, but
> the UI to change themes can just do some trickery and enable/disable the
> correct extensions under the hood.
>

No problem there.


--

Dotan Cohen

http://gibberish.co.il
http://what-is-what.com