Call for contributors: New Theme Development Docs

Discuss application theming and theme development.
User avatar
jorgev
Posts: 53
Joined: May 26th, 2005, 9:54 am
Location: Costa Rica

Call for contributors: New Theme Development Docs

Post by jorgev »

We're looking into rearranging the add-ons sections on MDN, and one of the areas we've seen needs updating is the one for complete themes. I was curious if theme developers were getting their docs from some other place but it looks from this recent thread that right now the development process is very ad-hoc.

So, we would like to improve this, and clearly you're the best group to create a new guide for theme development. I'd like to know if there is any interest from this group to contribute to this documentation. We can figure out together how it should be structured so it doesn't become outdated too soon and aspiring theme developers can quickly get started.

The MDN team has shown lots of interest for this proposal, and they're willing to give you editorial support and any other assistance dealing with the MDN wiki.

If you're interested in contributing or have any ideas on how we should do this, please post them here or contact me directly (jorge AT mozilla DOT com). Thanks!
Jorge Villalobos
Add-ons Developer Relations Lead, Mozilla
User avatar
LoudNoise
New Member
Posts: 39900
Joined: October 18th, 2007, 1:45 pm
Location: Next door to the west

Re: Call for contributors: New Theme Development Docs

Post by LoudNoise »

Made into a two week sticky.
Post wrangler
"Choose between the Food Select Feature or other Functions. If no food or function is chosen, Toast is the default."
User avatar
KLB
Posts: 2282
Joined: December 21st, 2003, 9:25 am
Location: Saco Maine
Contact:

Re: Call for contributors: New Theme Development Docs

Post by KLB »

I think rearranging the docs would be a good idea. The lack of good and easy to implement documentation creates a huge hurdle to new people creating themes.

I would be willing to help as much I can, but I'm not one of the real theme gurus here There are many here who are way more talented than myself.

The goal of the documentation should not only be to make it easier for people to learn how to create new themes, but how to create a code base that minimizes effort required to maintain these themes. I think I can safely speak for many theme developers when I say the rapid release cycle has made maintaining themes an exhausting process.

I know that some folks here had developed a method of creating themes that only contained the stuff they changed rather than the entire theme code base. I personally don't understand how they went about doing this, but it would certainly make life easier if there was a documented way to make a custom theme without having to reflect every single change to the default theme.
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
Aris
Posts: 3248
Joined: February 27th, 2011, 10:14 am

Re: Call for contributors: New Theme Development Docs

Post by Aris »

I would also be willing to help.

@Jorge


Wouldn't it make sense to start something like this after Australis is at least in beta? Australis ui contains many changes and it could be a big waste of time to create docs now for current Fx versions and recreate them again for Australis after a huge css part changes, or am I wrong?

@Ken

Look at themes from L.A.R. Grizzly. They are basically extensions masked as themes.

The main trick is hidden inside chrome.manifest.

Instead of doing what most themes do...:

Code: Select all

skin   browser      theme_name   chrome/browser/
...


...it is easier to add an overlay:

Code: Select all

style chrome://browser/content/browser.xul     chrome://theme_name/skin/browser.css


Browser.css only contains your changes/additions to the UI. Everything else is styled by default theme.

Example 1
If such a theme changes button images, button colors and/or toolbar colors, there is no need to release updates for every Fx version.
Example 2
If a new Fx version introduces new ui content the worst case scenario would be the content gets styled by Fx default theme, nothing breaks.

Pros
- no updates needed for every Fx version (no devtools changes needed anymore :mrgreen: )
- lesser (css) code
- easy to handle for new theme devs, if documents tell how to create a basic empty theme to start with

Cons
- you need to know the exact .xul file location you want to overlay (add-ons manager, browser, etc...)
- every css change needs "!important"


IMO the best way to theme Fx in the future is to create css loader extensions with inline options or option windows to make themes more customizable.
User avatar
jivko
Posts: 237
Joined: September 2nd, 2008, 11:20 am

Re: Call for contributors: New Theme Development Docs

Post by jivko »

If you want to help with custom theme development here's what I think you should do.
1. Do something about making custom themes more popular. We haven't had new custom theme in months and some classing custom themes are no longer supported. In other words try attracting more people. Right now you're encouraging people to make personas backgrounds, not themes. I'm sure that a lot of users have Css knowledge.
2. Stop rapid release cycle. It's annoying to fix changes in documents from the devtools folder and some small changes in the url bar for example.
3. Wait for the big theme changes. There's no point in making tutorials about current theme code since Australis is coming in the near future.
4. Don't write huge information of how to create a theme like it's a book or something. Make a video. It's easier, saves time and new developers can understand the process of theme development easily.
User avatar
KLB
Posts: 2282
Joined: December 21st, 2003, 9:25 am
Location: Saco Maine
Contact:

Re: Call for contributors: New Theme Development Docs

Post by KLB »

jivko wrote:If you want to help with custom theme development here's what I think you should do.
1. Do something about making custom themes more popular. We haven't had new custom theme in months and some classing custom themes are no longer supported. In other words try attracting more people. Right now you're encouraging people to make personas backgrounds, not themes. I'm sure that a lot of users have Css knowledge.
2. Stop rapid release cycle. It's annoying to fix changes in documents from the devtools folder and some small changes in the url bar for example.
3. Wait for the big theme changes. There's no point in making tutorials about current theme code since Australis is coming in the near future.
4. Don't write huge information of how to create a theme like it's a book or something. Make a video. It's easier, saves time and new developers can understand the process of theme development easily.


#1: I agree. More work needs to be done to promote custom themes. It takes a tremendous amount of work to maintain a theme and it takes way more work today then it did prior to the rapid release cycle. Helping to make themes more popular would make the effort feel more rewarding because more people would be using them.

#2: Beyond Jorge's control. I also see merit to the rapid release cycle from other perspectives, but it is killing us as theme developers.

#3: I agree, this probably should be something that is part of Australis, but that isn't to say there isn't some stuff that could be worked on now. Rewriting the documentation will take a lot of work.

#4: I disagree, some people may like videos, but they don't replace well written documentation. Personally I hate video tutorials. I want to see text with examples.
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
David.Vincent
Posts: 213
Joined: June 17th, 2011, 10:11 pm

Re: Call for contributors: New Theme Development Docs

Post by David.Vincent »

I agree with jivko and Aris.
It takes a lot of time to maintain a theme compatible with Firefox (and Thunderbird for me). The major time is consacred to devtools that nobody uses (actualy I have 4 versions of devtools in my theme if I want that they work with all Firefox versions). This huge work is not well rewarded, because full themes are not very welcome for Mozilla team (all full themes have lost 50% of users mini since the new Add-ons pages display has launched).
I think that new Firefox releases should be more spaced too (2 - 3 months).
I am following Australis development and every week the code is changed in an other way : if I write an adaptation for my theme, I am sure that the next week this adaptation will not work. For this reason, I have stopped to work on Australis development until it will be launched in Nightly. And I know that when this will be, the work will be huge. At this moment, it will be the good time to update theme development docs. Not now.
And, finaly, I think that Firefox developers should communicate with theme developers in this forum. Nobody knows when Australis will be launched (Firefox 28 - March 4th???). Jorge is the only developer that give us some informations for every new release (thank you for this).

A centralization of links that could help developers will be a good idea :

https://wiki.mozilla.org/RapidRelease/Calendar

https://wiki.mozilla.org/Firefox/Planni ... c_Reaction

https://blog.mozilla.org/futurereleases/

https://blog.mozilla.org/addons/

https://developer.mozilla.org/en-US/docs/Themes

https://wiki.mozilla.org/AMO:Editors/Ed ... emeReviews

viewtopic.php?f=18&t=2173163
User avatar
Frank Lion
Posts: 21173
Joined: April 23rd, 2004, 6:59 pm
Location: ... The Exorcist....United Kingdom
Contact:

Re: Call for contributors: New Theme Development Docs

Post by Frank Lion »

Jeeze, what an awful lot of discussing about what to discuss.

Is it possible to document how to make a full non-native theme? - No, it is too complicated and the constant stream of changes would make any such documentation redundant in a week.

Is it possible to document how to make a native theme that will not break* under any circumstances? - Yes.

For example, here I'm just using 17esr on XP to go from this -

Image

Uploaded with ImageShack.us


..to this, in just under an hour -

Image

Uploaded with ImageShack.us


...and here's the same in 'Large Icons' mode, which I think looks better -

Image

Uploaded with ImageShack.us

Not the prettiest theme I've ever done, but here are the changes from default -

#1. Toolbar.png colourised and contrast adjustments.
#2. Toolbar background added.
#3. Round ended urlbar/searchbar and slight height reduction.
#4. App Menu button changed.
#5. Tabs changed from rectangular XP type to Chrome/Australis-like tabs.

Everything else is default. The entire installable theme is around 50K in size. It is impossible to break* so long as you keep an eye on any Toolbar.png changes. This 'non-breaking despite updates' is achieved by not only knowing which UI elements can be 'safely' themed, but also by using a certain simple style of coding that uses no margin or padding commands, etc.

It's not necessary to use the default 'toolbar buttons', but the -moz-image-regions must be the same. This limitation means that alternative buttons are limited to around 18x18 and, frankly, that is a challenge to make buttons that look much good at such a small size. However, they can at least be readily identifiable using shape, colour and contrast, but don't expect a harmonious and unified look using this approach.

That tab coding I've done could break, but I only added that to confirm that this method would accept existing (which this was) userChrome snippets and it does. A 'gentler' approach in this area wouldn't break.

Is the above a 'Complete Theme'? Don't ask me, I don't do themes like that (apart from Andromeda) it certainly has changed the default a lot and it ain't no 10 minute Persona, so I guess it must be.

Is this method suitable for what is required above? - Again, don't ask me, I've been doing this stuff a while and, as mentioned, it took me an hour to make. I guess with instructions, someone starting out could have a theme (if that is what this is) done in a few evenings.

KLB wrote:I know that some folks here had developed a method of creating themes that only contained the stuff they changed rather than the entire theme code base. I personally don't understand how they went about doing this, but it would certainly make life easier if there was a documented way to make a custom theme without having to reflect every single change to the default theme.

The 'some folks' are Patrick (Phoenix Light), me (ML Andromeda) and, mainly, Sharebird (whole raft of stuff on chrome manifest flags and 'lightweight' themes)

@ Jorge -


If this is the sort of thing you were after then let me know what you want in it and what you want it to look like. I'll make it and comment the coding sections as I go along. I'll then pass this template theme over to the MDN team to document it all. AMO can host the template and you're good to go.
"The only thing necessary for the triumph of evil, is for good men to do nothing." - Edmund Burke (attrib.)
.
User avatar
jorgev
Posts: 53
Joined: May 26th, 2005, 9:54 am
Location: Costa Rica

Re: Call for contributors: New Theme Development Docs

Post by jorgev »

Regarding Australis and other future changes, I think the tutorial could have two parts. One would be the base tutorial that covers the things that don't change often and lets you create a simple but durable theme, which is what Frank showed in the last comment, I think. Then there could be a move advanced section that covers more specific things and will probably need to be refreshed every now and then. I think that if we can at least have a good set of guidelines on how to set up your theme dev environment and create a theme base to extend on, that will be very valuable to new developers.

For rapid releases, you might be interested in this proposal. The Release Management team is looking to renew the release process, and this proposal includes switching to a 9 week cycle. It's no official yet, but it looks like the only big hurdle to overcome at the moment is localization.
Jorge Villalobos
Add-ons Developer Relations Lead, Mozilla
User avatar
malliz
Folder@Home
Posts: 43796
Joined: December 7th, 2002, 4:34 am
Location: Australia

Re: Call for contributors: New Theme Development Docs

Post by malliz »

With respect jorgev the real world is not like Mozilla. I would imagine Frank has made the offer because he has the time to do it now.
What sort of man would put a known criminal in charge of a major branch of government? Apart from, say, the average voter.
"Terry Pratchett"
User avatar
LoudNoise
New Member
Posts: 39900
Joined: October 18th, 2007, 1:45 pm
Location: Next door to the west

Re: Call for contributors: New Theme Development Docs

Post by LoudNoise »

Lunar. split your post off to here.
viewtopic.php?f=7&t=2766395

Folks, this is a very specific topic. It is about the documentation needed for make Themes which would all agree is a good deal. Please keep comment specific to the topic at hand. Thanks.
Post wrangler
"Choose between the Food Select Feature or other Functions. If no food or function is chosen, Toast is the default."
User avatar
patrickjdempsey
Posts: 23686
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC
Contact:

Re: Call for contributors: New Theme Development Docs

Post by patrickjdempsey »

jorgev, the commonly-held belief that Rapid Release is *the* problem is simply a fiction. Rapid Releases isn't what is breaking themes. It's shoddy programming and improperly quarantined experimental features. Devtools is THE big breaker on themes with every single release... for several releases in a row almost the entire devtools system was scrapped and rebuilt. Themes cannot possibly support these kinds of heavily-experimental features. Unlike the default theme, OUR users expect a Theme that will be compatible with dozens of older versions. And AMO tests and guidelines have made it an obstacle course for Themes to support older versions of code... all to avoid meaningless Error Console warnings, which BTW is completely unnecessary because of the way CSS parser works. This requirement along with a policy of stuffing experimental feature code into browser.css makes supporting themes a constant hassle. Rapid Releases doesn't have to be like this. If Mozilla would develop experimental features like devtools in a separate skin, and stop randomly changing the ID names of elements, and loosen the Error Console requirements, then theme support would be greatly simplified.

The simple method LAR Grizzly uses and Frank illustrated was developed by several of us, mostly ShareBird and USED to work beautifully. The issue is that some of the Mozilla developers keep using extremely complicated solutions for basic problems. These complicated solutions break basic themes. Some examples:

- for Glass/Personas support Firefox is swapping out toolbar.png programmatically using a manifest override instead of just using CSS in the default theme.
- a similar hack happens for OSX Lion support.
- the combined Back/Forward/urlbar stuff seriously breaks basic themes.
- the hiding Forward button does the same.
- and the Back button "circle".
- the -moz-any code used for selecting buttons in the default theme creates a selector hierarchy that breaks basic themes and requires one-up-manship to stay ahead of.
- recently a change with how the combined urlbar Stop/Reload/Go is handled broke these themes so that these buttons disappear. I still have not been able to figure out why or how that even happens.

I've drafted proposals for an alternative theme structure that would still be compatible with Complete Themes but also allow for Basic Themes that would NOT break. But it would require Mozilla to do training and testing on something it is doubtful they have any interest in supporting.

In addition to the work on Basic Themes, ShareBird also began working on fixing Restartless Themes based on some discussions we had. Working in conjunction with Basic Themes, this Restartless concept would have been able to deliver something as immediate and as stable as Personas but vastly more interesting. I'm not sure if his method still works or not but the last version i used required multiple restarts to work for some reason. Anyway, this is technology that should be fixed in the browser.

I've also experimented with override theming, but this method was banned for Themes... even though the default theme uses it. While it was working it only required a single file and a very short chrome manifest to build a theme that just swaps out the main toolbar.png file. I've also got an SVG-based theme that simply changes the colors of the provided buttons.

Another MAJOR problem that first-time themers face is cross-platform issues. I've got a few of these listed in my Theming Firefox 4.0 Metathread below, but there are other older resources that haven't been updated in a long time, that may or may not be required. Currently Mozilla supports no less than half-a-dozen "default themes" each with OS-specific code that doesn't work on other OS's. Guaranteeing interoperability across platforms is virtually impossible and finding users with the patience and know-how to help you test can be maddening. As mentioned above, even Basic Themes and Override Themes are severely broken on cross-platform by the weird overrides and hacky CSS.


Anyway, here is a series of resources and discussions that may be of interest:

ShareBird's Yet Another Theme Tutorial:
http://www.tudobom.de/articles/yatt/

Firebird Theme - a "light-weight" Theme:
viewtopic.php?f=18&t=1472225

Loading Themes without Restart.

viewtopic.php?f=18&t=1707005

My basic description of an alternative theme structure:
viewtopic.php?p=11530289#p11530289

My sample override theme (only works in Firefox 4.0-7.0):
https://addons.mozilla.org/EN-US/firefo ... serprofile

My sample SVG theme:
https://addons.mozilla.org/en-US/firefo ... vg-colors/
My SVG theme documentation:
viewtopic.php?f=18&t=2517761

A Metathread about theming for Firefox 4.0, which includes several topics about major changes since 3.x... some of this is now out-of-date:
viewtopic.php?f=18&t=2164853

And lastly, the epic list of Nightly Changes maintained by akayser and mcdavis, which is the closest thing to an official document on every single theme-related change that has happened in the browser since Firefox 4.0. As you can see by the length of 22 pages (which only sparse commentary) this is a truly massive amount of changes in 2 years.
viewtopic.php?f=18&t=2173163
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
jorgev
Posts: 53
Joined: May 26th, 2005, 9:54 am
Location: Costa Rica

Re: Call for contributors: New Theme Development Docs

Post by jorgev »

Thank you for the detailed explanation and links, Patrick. I would appreciate it if you can create a separate thread about the review guidelines issues you and others have encountered, and let me know about it, since that's something I can take more immediate action on.
Jorge Villalobos
Add-ons Developer Relations Lead, Mozilla
User avatar
patrickjdempsey
Posts: 23686
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC
Contact:

Re: Call for contributors: New Theme Development Docs

Post by patrickjdempsey »

One thing that I've recommended for first-time themers for awhile now is building a browser-skin-only theme. Most themers only want to touch the primary interface anyway, so there is no point of packaging the other skins if you aren't going to change them. This has a very big advantage of only breaking when changes happen in the areas touched by the browser skin. However, as I mention above, the vast majority of changes happening in Firefox have been happening in /browser/, while the other skins have been gathering dust. So that doesn't really fix the primary headache, even if it does fix some of the long-term support issues.

The fix is to break off the primary interface code out of the /browser/ skin into it's own small little /basic/ skin. This would include the code for drawing tabs, the toolbarbutton-1 support code, and the urlbar and searchbar code. The nice thing about isolating this code is that the default code can be as monstrously complex as it wants and a themer can come in and replace it with nice clean Firefox 1.5-era theme code and everything will run just fine. If handled correctly, it would be possible to build a virtually maintenance-free theme that only requires support when major major structural changes happen... which is still very rare.

Edit: IF this kind of fix was going to happen, it really should have begun with the work on Australis so that it could all be a part of the new interface. Although, it only took me 2 hours to hack omni.ja to make this alternative structure work and I'm hardly the most knowledgeable person in regards to skin packaging.
Last edited by patrickjdempsey on November 4th, 2013, 5:41 pm, edited 1 time in total.
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: Call for contributors: New Theme Development Docs

Post by patrickjdempsey »

There were many examples for instance of themes that never got properly updated for Firefox 4.0 that had broken addons managers. Removing the /mozapps/ skin in these themes would have immediately fixed the problem of addons manager support without lifting a finger. The fact that these skins are optional is not something that is obvious in most tutorials.
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