Could/should themes be more like overlays than overrides

Discuss application theming and theme development.
User avatar
patrickjdempsey
Posts: 23686
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC
Contact:

Re: Could/should themes be more like overlays than overrides

Post by patrickjdempsey »

Frank Lion wrote:Incidentally, I was forgetting my manners in the last post. I wish to sincerely thank again Patrick for his excellent in-theme solutions for the Forward/Back history dropmarker and urlbar RSS feed fixes.


You are welcome Frank! Unfortunately Ken informed me that packaging XBL with themes means they require more thorough testing than themes without to be hosted on AMO... but you don't have that problem. ;)

I missed your suggestion in the UX thread... impossible to keep up with that one, I will look into it deeper.

KMeleon isn't perfect... the BMP/ICO limitations are frustrating. Fortunately KMeleon *does* support 32-bit BMP's, I think I used IfranView to convert PNG's to transparent BMP's... wacky stuff. But the part that's interesting to me is that an 8-year-old with some graphics files could easily build a basic KMeleon skin in an hour. It actually takes longer to figure out how to install the darn things than to create them.... for basic ones, your's being a stunning example of what not to do. ;)
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/
User avatar
KLB
Posts: 2282
Joined: December 21st, 2003, 9:25 am
Location: Saco Maine
Contact:

Re: Could/should themes be more like overlays than overrides

Post by KLB »

If you do package any sort of JavaScript in your themes it is really critical to not go overboard and to resist wholesale changes for no reason between releases.

AMO editors have tools that allow us to do dif checks of source code. As long as the sections of themes with JavaScript don't contain changes between versions they can be reviewed more like standard themes. One of the biggest mistakes addon developers seem to make is to name the root folder in their addons based on the update version number (e.g. /SomeAddon20111120/) What this does is cause our dif checker to flag all files in the jar as being new files and they have to get a line by line review all over again. As long as folder names and structures don't change the dif checker works really well and we can breeze over sections of code that didn't change.

As an AMO editor, all I review are themes as I don't have the expertise to review complicated JavaScript in extensions. I'm just not creative enough to think of all the sneaky ways to sneak in evil JavaScript code. If a theme does have a boat load of JavaScript I may have to leave it for someone else or flag it for an admin review. Either way it can add a week or more to how long the theme has to wait in the Queue. If a theme is completely clean of any JavaScript, there just isn't that much evil that it could commit.
Ken Barbalace - AMO Editor (I focus on reviewing themes)
I maintain Classic Compact, a very compact yet clean Firefox theme.
EnvironmentalChemistry.com (Periodic Table)
User avatar
patrickjdempsey
Posts: 23686
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC
Contact:

Re: Could/should themes be more like overlays than overrides

Post by patrickjdempsey »

Another thought on this topic: it's not widely distributed information that a theme doesn't have to include all of the skins. For instance back when 4.0 was in development and the add-ons manager was undergoing weekly changes I distributed a theme with just /browser/ and /global/ and left out /moz-apps/. I've actually seen many themes that never touch anything in /moz-apps/ but still ship with it. Inexperienced authors end up creating problems if they forget to update all of the files in this skin even if they don't use it.

I've often considered shipping /browser/-only themes. Ideally, /global/ only contains global OS-styled widgets, however the way Firefox is shipped there's quite a few graphics in /global/ that are referred to in /browser/ that a themer may be interested in changing, like blank favicons, search-go, close buttons, etc. When I was playing around with making a theme-building template I moved all of these files into /browser/icons/ and changed the url references. I also moved global.css into /browser/ and created many sub-stylesheets and @imported them from browser.css so it could be cleaned up a bit... like urlbar.css, tabbrowser.css, arrowpanel.css etc. The unfortunate thing is that after doing all of these changes, even though it makes a much easier template than the default theme, it's also different enough from the default theme that it makes porting over changes with each version more difficult.

Edit: another plus to a /browser/-only theme is you automatically avoid the disaster that is scrollbars. Speaking of which, anyone on OSX have time to test this? viewtopic.php?p=11469083#p11469083
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/
User avatar
patrickjdempsey
Posts: 23686
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC
Contact:

Re: Could/should themes be more like overlays than overrides

Post by patrickjdempsey »

There is actually a really simple solution to all of this but Mozilla won't like it: they need to create a /skin/ specifically for Themes. Basically this would be a modification of a /browser/-only type of theme. The goal of this 4th skin would be to contain only the elements needed to skin the main browser window, leaving out the things that could easily seriously break Firefox (like the window-control-buttons in the titlebar). This would create a simple platform for first-time themers that couldn't break important Firefox features, could possibly even be update-proof, and best of all wouldn't break existing themes! (light themes based on Sharebird's method would only require a change in the chrome.manifest).

How it would work: a new skin called /theme/ containing some elements from /browser/ and some from /global/. The goal of this skin is to focus only on things directly seen in the main browser interface... anything seen only in popups and panels is left in /browser/. Another goal is to split up browser.css into component .css files to make it easier to find certain things.

This is what I could see it looking like:

Code: Select all

searchbar.css (same as current searchbar.css)
theme.css (bulk of commands from browser.css and some from global.css)
tabbrowser.css (commands from browser.css about tabs)
toolbar.css (commands from browser.css, toolbar.css about toolbars)
toolbarbutton.css (commands from browser.css, toolbarbrowser.css, menu.css about toolbarbuttons and main menu effects)
urlbar.css (commands from browser.css about the urlbar)

/tabbrowser/... (all images from /tabbrowser/)

/icons/...
bookmark.png (from /browser/places/)
close.png (from /global/icons/)
editBookmark.png (from /browser/places/)
folder-item.png (from /global/icons/)
keyhole-forward-mask.svg
livemark-folder.png
livemark-item.png
mainwindow-dropdown-arrow.png
reload-stop-go.png
tabview.png (from /browser/tabview/)
tabview-inverted.png (from /browser/tabview/)
Toolbar.png
Toolbar-inverted.png
Search-glass.png (from /global/icons/)
urlbar-history-dropmarker.png


So how would it work technically without breaking current themes? Simple. /theme/theme.css is @imported from /browser/browser.css. The sub-styles: searchbar.css, tabbrowser.css, toolbar.css, toolbarbutton.css, and urlbar.css are all @imported from theme.css. If the current theme doesn't include that main @import command nothing from /theme/ runs. I personally think there are too many image files and this is too complicated but that's because I think the default theme is far too complicated to begin with. Of course a theme designer could opt not to use half of these images and style everything in the main window differently.

*Most* of browser.css wouldn't merge into theme.css... the only bits that would, would be: bookmarks toolbar stuff, the main button icon definitions, and the @import commands. Everything else either falls into the sub-styles or is left in browser.css. Mozilla could even be clever here and leave the security-specific stuff in /browser/so that they could drop the argument that themes are possibly less secure than the default theme.
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/
User avatar
KLB
Posts: 2282
Joined: December 21st, 2003, 9:25 am
Location: Saco Maine
Contact:

Re: Could/should themes be more like overlays than overrides

Post by KLB »

In order for us to get Firefox developers to consider any of our ideas to better address the needs of themers, themes in general need a larger user base. Even though, the public stats for the most popular users show over 300,000 users, the truth is, this only is the number of users who have the theme installed. It is not the number that are using it. The number of users who actually have a given theme enabled is much lower.

Here are the stats of the most popular themes that make their stats public:

Code: Select all

Addon Name:         reported users, userEnabled
--Pg 1--
Noia 2:             ~233k,          ~40k
Silvermel:          ~210k,          ~53k
A Blue Fox Theme:   ~165k,          ~30k
Noia 4:             ~147k,          ~55k
Office Black:       ~146k,          ~32k
Walnut for Firefox: ~130k,          ~31k
--Pg 2--
Walnut for Firefox: ~101k,          ~14k
Classic Compact:     ~84k,          ~24k
Purple Fox Christmas
special:             ~81k,          ~12k
AvantGarde:          ~73k,           ~7k
--Pg 3--
PitchDark for Fx:    ~60k,           ~6k
Green Fox Lava RC2:  ~50k,           ~7k
Qute:                ~48k,           ~8k
Black Steel:         ~44k,          ~10k
--Pg 4--
Strata RELOADED:     ~40k,           ~8k
Walnut2 for Firefox: ~36k,          ~11k
BlackX:              ~32k,           ~2k
Littlefox:           ~31k,           ~9k


Based on this, there may be only a few million users who are actively using a custom theme. This would be less than 1% of the overall Firefox user base. In order to change this we need to make themes more appealing to users, and we need personas and themes to work together (bug 520124).

If a competent coder helped contribute code to bug 520124 it could be delivered within a couple versions of Firefox. To make themes more appealing, the overall quality of themes also needs to be improved. Many developers here on MozilliaZine produce excellent quality themes, but there are also a lot of really sloppy themes on AMO. Bad themes cause bad user experiences which in turn and gives all themes a bad reputation.

A major part of improving the quality of all themes is better testing. I'm working on this by trying to develop more through theme testing checklist for AMO Editors. The idea is not to reject themes because of issues, but rather to provide developers with more useful constructive feedback to improve theme quality over time. The intention of the checklist will be to systematically test as many parts of the UI as possible to make sure something didn't get missed. Once it is completed (or mostly completed) I will post the checklist here on MozillaZine for themers to use while QCing their own themes.

Another part of improving theme experience is for themers to do our level best to support extensions, even when the extension is to blame for compatibility issues, because regardless of who is at fault for the compatibility issues themes take the blame.
Ken Barbalace - AMO Editor (I focus on reviewing themes)
I maintain Classic Compact, a very compact yet clean Firefox theme.
EnvironmentalChemistry.com (Periodic Table)
User avatar
ShareBird
Posts: 2740
Joined: December 8th, 2004, 7:09 am
Location: Berlin | Made in Brasil
Contact:

Re: Could/should themes be more like overlays than overrides

Post by ShareBird »

IMHO the worst enemy from theme development is the idea that "theme development" is merely a matter of copying the default theme and changing some images, font colors and background colors...
Our system is very, very powerful and really makes the difference comparing to the boring systems from Chrome and Opera.
Last edited by ShareBird on December 1st, 2011, 5:37 am, edited 1 time in total.
Silvermel - A Theme for Firefox and Thunderbird
YATT - Yet Another Theme Tutorial
Don't give a man a fish. Teach him how to fish instead.
User avatar
patrickjdempsey
Posts: 23686
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC
Contact:

Re: Could/should themes be more like overlays than overrides

Post by patrickjdempsey »

KLB, mcdavis already did a ton of work on collecting together some tests for themes, in case you haven't seen this yet:
viewtopic.php?f=18&t=1932839&hilit=notes+on+testing
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/
User avatar
patrickjdempsey
Posts: 23686
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC
Contact:

Re: Could/should themes be more like overlays than overrides

Post by patrickjdempsey »

Sharebird, I think it is important that we keep the powerful aspect of theming alive, but I also think there needs to be an entry-level. Unfortunately Mozilla has been doing some really wacky coding on the default theme lately that requires support for your overlay themes that frankly I was personally really confused by... it basically requires using Vista/7 Aero to debug at all. Messy stuff.
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/
User avatar
KLB
Posts: 2282
Joined: December 21st, 2003, 9:25 am
Location: Saco Maine
Contact:

Re: Could/should themes be more like overlays than overrides

Post by KLB »

patrickjdempsey wrote:KLB, mcdavis already did a ton of work on collecting together some tests for themes, in case you haven't seen this yet:
viewtopic.php?f=18&t=1932839&hilit=notes+on+testing


Most excellent! I might have to abridge it slightly or the process of AMO editors reviewing themes might grind to a halt, that is one heck of a detailed list.
Ken Barbalace - AMO Editor (I focus on reviewing themes)
I maintain Classic Compact, a very compact yet clean Firefox theme.
EnvironmentalChemistry.com (Periodic Table)
User avatar
KLB
Posts: 2282
Joined: December 21st, 2003, 9:25 am
Location: Saco Maine
Contact:

Re: Could/should themes be more like overlays than overrides

Post by KLB »

patrickjdempsey wrote:Sharebird, I think it is important that we keep the powerful aspect of theming alive, but I also think there needs to be an entry-level.


I totally agree. Theming can't be an exclusive club or we won't have a critical mass of different themes available to attract enough users to make custom themes a consideration for Firefox Development. If we want a seat at the table we need to represent a significant population of Firefox users. This requires an abundance of diverse themes. Not all of them need to be at the graphics quality of Lavafox or NASA Night Launch. There is a place for themes that simply replace some image files or mess with CSS files in creative ways to make the default theme more compact or more gargantuan.
Ken Barbalace - AMO Editor (I focus on reviewing themes)
I maintain Classic Compact, a very compact yet clean Firefox theme.
EnvironmentalChemistry.com (Periodic Table)
User avatar
ShareBird
Posts: 2740
Joined: December 8th, 2004, 7:09 am
Location: Berlin | Made in Brasil
Contact:

Re: Could/should themes be more like overlays than overrides

Post by ShareBird »

Patrick, I don't think Mozilla is doing wacky coding on the default theme... Taking as example the toolbar buttons, it is just using CSS3 instead of graphics to skin the different states (since FF7). To do this they've added some rules and removed others. Of course they need to be overridden if you are using the override approach I've written about. But once you do this for, e.g., FF7 you practically don't need to touch then for 8. 9. 10...

KLB, it's not the quantity of themes that matters, but the quality of them.
Silvermel - A Theme for Firefox and Thunderbird
YATT - Yet Another Theme Tutorial
Don't give a man a fish. Teach him how to fish instead.
User avatar
patrickjdempsey
Posts: 23686
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC
Contact:

Re: Could/should themes be more like overlays than overrides

Post by patrickjdempsey »

So you don't find this to be wacky?

Code: Select all

#navigator-toolbox[iconsize=large][mode=icons] > #nav-bar :-moz-any(#back-button, #forward-button, #reload-button, #stop-button, #home-button, #print-button, #downloads-button, #history-button, #bookmarks-button, #bookmarks-menu-button, #new-tab-button, #new-window-button, #cut-button, #copy-button, #paste-button, #fullscreen-button, #zoom-out-button, #zoom-in-button, #sync-button, #feed-button, #alltabs-button, #tabview-button):not(:-moz-any(#alltabs-button,#tabview-button,#new-tab-button,#sync-button[status])) > .toolbarbutton-icon {
  list-style-image: url("chrome://browser/skin/Toolbar.png") !important;
}
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/
User avatar
KLB
Posts: 2282
Joined: December 21st, 2003, 9:25 am
Location: Saco Maine
Contact:

Re: Could/should themes be more like overlays than overrides

Post by KLB »

ShareBird wrote:KLB, it's not the quantity of themes that matters, but the quality of them.

No it is a balance between the two. I'm not saying we should tolerate errors or broken functionality in themes. Outside of function failings, much of what constitutes quality is a subjective opinion.

As far as objective measures of quality, like functional failings, I do believe we need to help themers improve their themes. When I review themes as an AMO editor, I try not to just say "it looks good", if I notice things that could be improved I try to provide constructive feedback.
Ken Barbalace - AMO Editor (I focus on reviewing themes)
I maintain Classic Compact, a very compact yet clean Firefox theme.
EnvironmentalChemistry.com (Periodic Table)
User avatar
ShareBird
Posts: 2740
Joined: December 8th, 2004, 7:09 am
Location: Berlin | Made in Brasil
Contact:

Re: Could/should themes be more like overlays than overrides

Post by ShareBird »

patrickjdempsey wrote:So you don't find this to be wacky?

Code: Select all

#navigator-toolbox[iconsize=large][mode=icons] > #nav-bar :-moz-any(#back-button, #forward-button, #reload-button, #stop-button, #home-button, #print-button, #downloads-button, #history-button, #bookmarks-button, #bookmarks-menu-button, #new-tab-button, #new-window-button, #cut-button, #copy-button, #paste-button, #fullscreen-button, #zoom-out-button, #zoom-in-button, #sync-button, #feed-button, #alltabs-button, #tabview-button):not(:-moz-any(#alltabs-button,#tabview-button,#new-tab-button,#sync-button[status])) > .toolbarbutton-icon {
  list-style-image: url("chrome://browser/skin/Toolbar.png") !important;
}


No, I don't find it "wacky". The -moz-any pseudo-class is beautiful and very useful tool for selectors. I've solved my problems with pinned tabs using it...

Code: Select all

:-moz-any(.tabbrowser-tabs, #TabsToolbar) 
:-moz-any(toolbarbutton:not(.tab-close-button):not(
                            .scrollbutton-up):not(
                            .scrollbutton-down):not(
                            #new-tab-button):not(
                            .tabs-newtab-button):not(
                            #alltabs-button):not(
                            #tabview-button):not(
                            #tabs-closebutton))
.toolbarbutton-icon {
  -moz-transform: scale(0.9, 0.9);
}

On the code you've posted I have just two considerations: it doesn't use inheritance (you don't need to specify .toolbarbutton-icon, since the list-image attribute will be inherited) and the !important flag.

But the most important question is: why this code is bothering you?? AFAIK, your theme substitute the browser skin provider. Why do you think you are obligated to use it??
I repeat for the nth. time: "The default theme is just another theme". It absolutely doesn't matter which technique the default theme uses for skinning the elements. This is very important to understand. I'm tired to read things like "the default theme has defined a class "foo", or id "bar" or whatever. The default theme "defines" absolutely nothing! The XUL file is who defines everything.
Silvermel - A Theme for Firefox and Thunderbird
YATT - Yet Another Theme Tutorial
Don't give a man a fish. Teach him how to fish instead.
User avatar
patrickjdempsey
Posts: 23686
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC
Contact:

Re: Could/should themes be more like overlays than overrides

Post by patrickjdempsey »

I have one theme using the overlay method and it took me a week to find all of these weird new bits of code and add them to my theme in order to get it compatible with Firefox 8 and Aero Glass. It used to be we could just ignore this stuff in overlay themes but ever since Firefox 4.0 came out the CSS has been more strict and I have to include everything the default theme has in order to override the instructions. My point is that this method of theming is no longer the easy solution for casual themers that it used to be.
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/
Post Reply