Re: Starting to think about Firefox.next - light weight themes .. old-style themes
Mike Beltzner
to have full control over the browser's appearance. It's for people who want
to be able to put a different face on the browser quickly and transiently.
Simplifying theme development should ideally keep all the power of the
current system, but just make it easier to actually determine where images
should go, how to put together the manifest files, and allow for an easier
to understand structure.
cheers,
mike
----- Original Message -----
From: dev-planning-bounces+beltzner=mozil...@lists.mozilla.org
<dev-planning-bounces+beltzner=mozil...@lists.mozilla.org>
To: dev-pl...@lists.mozilla.org <dev-pl...@lists.mozilla.org>
Sent: Thu Apr 02 14:11:57 2009
Subject: Re: Starting to think about Firefox.next - light weight themes ..old-stylethemes
Hi,
every themer has likely different wishes, but all want the control of
there stuff.
For example are without code changes not even different icon sizes
possible.
A theme system without code changes is therefore more or less useless
for most of the themer.
Some would love a sophisticated theme editor, especially would it help
to find new themer.
But i don`t believe, that the few current theme nerds would use stuff
like this. They have already a developing system and this works
especially without any restrictions.
A system without restrictions for advenced themer and an easy to use
system are preferable. When possible, one system for both, but for
example is Personas in its current condition clearly not such a system.
Cheers
> On Thu, Apr 2, 2009 at 2:13 PM, Aronnax<aron...@gmail.com> wrote:
>> But a system for "Style the browser without having to code" is
>> naturally not, what an old-style themer want.
>
> Do you mean that old-style themers would not want to be able to make
> their current themes without having to write code? If we had a really
> sophisticated "theme editor", for example, would they object to it?
> I'm trying to make sure I understand if they really object to the
> process being made simpler (which would lessen the "exclusivity" of
> the activity, and could indeed cause some people displeasure I
> suppose!) or if you mean something else.
>
> Mike
_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning
Ted Mielczarek
see what percentage really go all-out, and what percentage just drop
in new toolbar icons and a new background color/image, say. More
precisely: what percentage of our existing themes could be written
using the new proposed light weight themes?
-Ted
Mike Beltzner
the current system to a personas-esque system. It's to allow a second,
lower-investment (on behalf of author and user) type of theme, as well
as to make it easier for those who want the more detailed, higher-
investment style of theme to be able to do what they want to do with
fewer headaches.
cheers,
mike
Ted Mielczarek
author time could we have saved with this method?" Given a set of
people who have successfully made themes, how much complexity are they
using on average? If we develop a simpler theme API, will it be too
simplistic to cover the needs of an average existing theme? Granted,
making a simpler API expands the set of potential theme authors, so
it's not the only thing to consider, but I think it's worthwhile to
ask, "if we had had this simpler theme API, how many of our existing
themes could have been written using it?"
-Ted
Michael Connor
A lot of the "simple" themes are dropping in new icon sets, so
Personas probably is the wrong model. Things get a lot less
lightweight when you get into replacing icon sets, especially with all
of the states, and _especially_ if you're changing image sizes.
-- Mike
falc...@42st.org
for Firefox.
I created a theme, "Camifox," that uses the MPL-licensed Camino
toolbar icons as a replacement for the default Firefox toolbar icons.
I use it myself because I like the equal weight/size and color of the
icons. It's largely a matter of personal preference. I'm glad that
such a theme can exist, thanks to the open licensing of the icons and
Firefox's accommodating theme structure.
Camifox modifies some toolbar icons, some nitpicky stuff like the
padding and spacing of some other XUL elements, and a couple of
toolbar backgrounds. It could actually be accomplished through
userChrome.css or a Stylish modification, using the "!important" flag
to override each existing XUL element.
But as it is, the theme carries a lot of unnecessary overhead. It was
very frustrating to keep up with the changes to the default Firefox
theme and make all the corresponding changes in my Camifox theme.
So, beginning with Firefox 3.1/3.5, I'm actually packaging the
*entire* Firefox default themes for each OS inside my Camifox theme.
On top of that, I'm using a separate Camifox CSS file within the .jar
package, which is called once from within global.css and carries all
the instructions to override icons and other elements with my own.
The solution isn't pretty, but it makes things easier. For the end
user, it allows them to install my theme directly from AMO without
messing around w/ Stylish or userChrome. For me, it lets me simply
swap out the Firefox default theme resources as they're updated,
leaving my own CSS overrides unaffected.
Looking forward to the future and new "light-weight" theme mechanisms
for Firefox, I think it would be great to have a built-in theme
structure that simply applies CSS overrides on top of the default
Firefox theme. The developer would retain free reign to use *any*
combination of CSS to override any XUL elements that they wish, but
they wouldn't have the burden of packaging an entire theme from
scratch.
Right now, the Stylish extension has that functionality. It can apply
real-time CSS overrides to the Firefox interface, without restarting.
But only UI geeks like myself are interested in Stylish; it requires
users to install an extension, go to another web site to get the
modification code, and generally be familiar with CSS. If similar
functionality were built directly into Firefox, the front end could be
much more accessible to the average user.
Obviously, Personas doesn't fit the bill, as it only changes the
toolbar backgrounds, and it is far too limiting for even the most
casual developer. It serves a different purpose than themes. I can
only assume "old-style" Firefox themes will never be deprecated unless
a replacement is provided that gives full control over CSS/XUL to the
developers that desire it.
Pardal Freudenthal
themers without changing anything in the way "heavy-weight" themes
work now.
We could register a new skin package, let's say "customSkin", with
just one *empty* .css file, let's say "customSkin.css". :-)
This file would be loaded from one .xul, or .js file, preferably at
the end from stylesheet cascade.
The goal on it is that "light-weight" themes would need to only
register one skin provider for this package:
skin customSkin skinname uri/to/files
We could place there css rules which would overwrite rules from the
default theme concerning toolbarbuttons, menu colors, backgrounds and
so on.
Something like the userChrome.css, but with the advantage this rules
will not match anything when the user change the used theme.
The default theme would provide the other rules so, no problems to
update the themes at a Firefox major update.
Really very "light-weight" themes with a couple kB.
We could also prepare this file with some empty css rules
like .toolbarbutton-1 {/*place here your list-style-image: value*/},
or whatever.
It's a very simple task and would make things a lot easier for
beginners (someone starting with this approach could any time use the
"full" approach, just registering the packages he/she wants to
modify).
I hope I was able to explain this idea...
Dave Townsend
Missed this discussion somewhere, but yes this is basically the idea
that I had some time ago. Although I don't think it would be easy to do
it quite as you say.
Right now every XUL file references a stylesheet, maybe in browser or
global. We just have to change things so every XUL file references two
stylesheets. The normal one, and then one in browser-override or
global-override say. Those stylesheets would be empty (or maybe just
non-existant if that doesn't break things) as default. A new theme could
then just provide the browser-override package to add individual style
overrides as they want, all the existing rules in the browser package
would still exist.
Dave Townsend
> Right now every XUL file references a stylesheet, maybe in browser or
> global. We just have to change things so every XUL file references two
> stylesheets. The normal one, and then one in browser-override or
> global-override say. Those stylesheets would be empty (or maybe just
> non-existant if that doesn't break things) as default. A new theme could
> then just provide the browser-override package to add individual style
> overrides as they want, all the existing rules in the browser package
> would still exist.
I should clarify, I'm saying that where every XUL file has a reference
to its own stylesheet we'd add an additional reference to the override
stylesheet.
This has a pretty big benefit that it should help themes remain
compatible with future versions of Firefox since they are only making
small overrides, new style rules in new versions of Firefox would still
be there and work.
Dao
> global. We just have to change things so every XUL file references two
> stylesheets.
It could be @included in global.css.
Dao
> We could also prepare this file with some empty css rules
> like .toolbarbutton-1 {/*place here your list-style-image: value*/},
> or whatever.
... and a -moz-image-region for each button, since we have multiple
default themes with different regions for the toolbar buttons (or no
regions at all).
Dave Townsend
That is an option, however that means that themers would have to use
document-uri selectors etc. in order to make sure their individual
styles were only applied to the correct window.
My opinion (and I'm not a themer so I could well be wrong) is that it
would be easier to have separate override css files for each XUL window,
just as we have separate normal css files for each XUL window.
It's possible we'd want to offer an override for global.css too, themers
would actually have hte option to do it either way then.
Pardal Freudenthal
<?xml-stylesheet href="chrome://customSkin/skin/" type="text/css"?>
Please, notice what I'm thinking is not a solution for all themes,
just a possibility for beginners, or "skinners" to have the option to
make a "light-weight" (or a "skin") for the application.
The other option, I mean instead of registering the new customSkin
package but registering skin providers for the other packages
(browser, global, mozapps, etc...), would be exactly the same as is
now....
Pardal Freudenthal
> I guess just one call on global.xul could do the job. Something like:
> <?xml-stylesheet href="chrome://customSkin/skin/" type="text/css"?>
Sorry, I mean browser.xul (there is no global.xul at all...)
> Please, notice what I'm thinking is not a solution for all themes,
> just a possibility for beginners, or "skinners" to have the option to
> make a "light-weight" (or a "skin") for the application.
>
> The other option, I mean instead of registering the new customSkin
> package but registering skin providers for the other packages
> (browser, global, mozapps, etc...), would be exactly the same as is
> now....
I'll try to explain the thoughts behind this.
I guess it's a common sense there are actually two different types of
themes. It doesn't matter how they are called: "light-weight", "heavy-
weight", "old style" or whatever.
I will call them "themes" and "skins". I don't know if it's
appropriate but just to distinguish both.
So, I understand "themes" and "skins" have different purposes, let's
say, the one modifies "look 'n feel", the other modifies "look".
The necessities from both are also different.
"Themes" don't care about heavy use of theme techniques like CSS and
XML. They need more freedom to manipulate the UI, it means more
customizable XUL, less hardcoded images... ;-)
"Skins" want to have a possibility to change some icons, modify some
menus without to have to do with so many files, and using as less code
as possible.
It's a little overkill if someone wants to bring just a set of icons,
change some background colors, needing to copy so many files from the
default theme.
Doing this division we could improve both type of themes, with many
advantages for both.
A chrome.manifest for a "skin" could be:
skin customskin skinname uri/to/files
The file structure:
-chrome
-customskin
-customskin.css
-Toolbar.png
.
.
.
A chrome.manifest for a "theme":
skin browser skinname uri/to/files
skin global skinname uri/to/files
skin mozapps skinname uri/to/files
(I can understand (more or less) why the default theme register a
communicator skin provider, but I don't understand why third party
themes also do this... I mean Firefox themes not Thunderbird, of
course)
The manifest flags could be used from both for skinning different OS
(a big advantage for "skins", which would never mind about XOS
compatibility), different versions, etc...
I guess also the call only on browser.xul will satisfy the necessities
from "skins". Notice that a "skin" can every time become a "theme",
just modifying its chrome.manifest, registering the skin providers for
the packages it wants to touch on.
Mook
> I came to an idea which could make things easier for "light-weight"
> themers without changing anything in the way "heavy-weight" themes
> work now.
So, the goal is to be able to implement themes without having to ship
the whole thing, and fallback to the shipped default skin, right? All
without being a user style sheet that has no concept of compatibility etc.?
I've had a hack to do it for a while: (Sorry for the line wrapping)
# Import the default skin
skin communicator classic/1.0
jar:resource://gre/chrome/classic.jar!/skin/classic/communicator/
skin global classic/1.0
jar:resource://gre/chrome/classic.jar!/skin/classic/global/
skin mozapps classic/1.0
jar:resource://gre/chrome/classic.jar!/skin/classic/mozapps/
skin help classic/1.0
jar:resource://gre/chrome/classic.jar!/skin/classic/help/
skin browser classic/1.0
jar:resource://app/chrome/classic.jar!/skin/classic/browser/
# Add custom parts
skin nativetabs classic/1.0 chrome/
style chrome://browser/content/browser.xul
chrome://nativetabs/skin/browser.css
style chrome://venkman/content/venkman.xul
chrome://nativetabs/skin/venkman.css
It just uses chrome.manifest rules to import the shipped things and add
on the custom bits; it's more work than the syntax you're suggesting,
but is a real theme (in that it shows up in the EM correctly, you can
switch to a different one, etc.) This however also means you need to
restart the app (since as far as I know nobody tests
extensions.dss.enabled).
(Shouldn't this live in .platform?)
--
Mook
Pardal Freudenthal
+nntp.news.mozilla....@gmail.com.please-avoid-direct-mail> wrote:
> Pardal Freudenthal wrote:
> > I came to an idea which could make things easier for "light-weight"
> > themers without changing anything in the way "heavy-weight" themes
> > work now.
>
> So, the goal is to be able to implement themes without having to ship
> the whole thing, and fallback to the shipped default skin, right? All
> without being a user style sheet that has no concept of compatibility etc.?
Yes. The idea behind your approach is very the same I've proposed. But
your idea is better!
The goal behind my idea is to let the default skin do the whole job
and a theme may only overwrite some rules from the default theme.
I think that's not necessary to re-register the skin providers, once
they are already registered from the default theme (am I wrong??)
If we combine your idea with my idea, we come to a very simple
approach, without any modifications on Firefox self (using the same
file structure I did above):
skin customskin skinname chrome/customskin/
style chrome://browser/content/browser.xul
chrome://customskin/skin/customskin.css
And we could also add some other style overlays for other .xul
files...
bird
the above method:
http://www.tudobom.de/articles/yatt/#light_weight
The method works, but it's still too limited because it makes only
possible to override the browser window's styles and has no control of
global widgets. It means if I want to modify, e.g., the appearance
from buttons, I have to declare a style overlay for each window where
buttons appear... Impossible. It could be a lot better if I can
determine styles globally for the widgets.
A solution could be what Dave proposed, enabling the override
instruction for themes. For me it makes more sense the override
instruction for themes as for extensions, if is guaranteed that these
overrides will only take effect if the theme using them is the
actually used theme.
Another approach could be an @import in content/xul.css (@import url
("chrome://customskin/skin/customskin.css");, for example) that would
make possible to override styles for the XUL elements. But all themes
using this approach will obligatory have to register a "customskin"
package...
As I said before, I think it's important, is to provide the two ways
for make themes. A "light-weight", override approach for simple themes
and the "heavy-weight", substitute approach for more complex themes.