On Thu, Jun 9, 2011 at 11:01 AM, Dotan Cohen <[email protected]> wrote:
> On Thu, Jun 9, 2011 at 00:14, Jasper St. Pierre <[email protected]> > 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 "[email protected]". > 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 >
_______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
