RFE Proposal for Easily Redistributable, Powerful Themes

"Great, we talked about it yesterday in the meeting. I'll look it over and reply tonight."

Actually, my queue is pretty deep right now and I'm going out drinking tonight after work, so I probably won't be able to review it in depth until tomorrow, but I'll look it over and get back to you.

Hahaha. Thanks, bharat. And for those who missed it, in IRC I was complaining about the lack of response, even though three people downloaded it.

jmullan: how long ago did you upload it?
CSpotkill: Three hours? lol

jmullan: how long did you work on writing it?
CSpotkill: At least an hour, after brainstorming all through yesterday ...
I could probably edit it again and clean it up, maybe add a photo or two, and some UI ideas, but I'll wait a little for comments

jmullan: wouldn't you want us to spend at least an hour reading and thinking before we respond?
CSpotkill: that's the easy excuse :p

CSpotkill: jmullan, I think part of it was I expected people to reply after they downloaded it, even if it was just something like "Great, we talked about it yesterday in the meeting. I'll look it over and reply tonight." I mean, that's how things seem to go on other forums I've been at. Lots of little "status updates" and such.

CSpotkill: Part of it is also nervousness. I want to be doing *stuff* but I can't. I need to see how the new theme system will go, before I can really start re-doing the existing theme, because perhaps the theme structure itself might change (or have to change)

Signe: You put too much stock in people reading the forums. :p
CSpotkill: lol I know.

Louis St-Amour (aka CSpotkill)

I downloaded and read your proposal. Although I've certainly not dug deeply into G2 (yet), I've pretty much ripped apart and rebuilt several versions of G1 over the last 2 years to make it look the way I wanted. The G2 carrot (for me) was that it would be far easier to customize, and that customizations would hold over from one version to the next (unlike G1).

Just wanted to say I like your ideas. I think it's important at some point to make sure that a non-designer will be able to easily add their own personalized touches to their G2 gallery without having to wade through a ton of tech info. Making things easier for Jane and Joe Average will significantly improve G2's success rate with the masses.

(and isn't that what we'd like to see)?

Gaile

I don't get the advantages of making a Themed Layout as apposed to either creating a new layout or using the .local files.

When I created my custom layout and theme I made them go together. Since I'm the only admin on my site (I'm not sure how many sites would have more then one admin) I just set the layout, theme, and imageframe to what I want. Since the users can't change to any of the other themes I don't really see the problem with how it is now.

With Themed Layouts, you can continue doing what you're already doing - it won't change that. It just means that people making themes for others can redistribute the themes with multiple "Supported Themed Layouts".

Another part of it personalization options, as you mentioned, so users can choose themes or views, or even for site admins - so they can set different views for subalbums, and use the same theme in both.

It's about making things more powerful and flexible, but also to minimize the amount of "clutter" involved with modifying code to "make it look right" on your site, and organize things to make it easier to maintain the changes.

At least, that's the theory.

Snow. And more snow. -3 right now. It'll be -10 tonight.

Still, snow's fun.

And as for the name, it's actually an online gaming alias. It works well, quite memorable, though for awhile, the kids I was playing with would think of that movie from ... two years ago, I think. You know, "See Spot Run". It was a romance, didn't pay much attention to it.

I don't actually like violence outside of video games, so ... I'm rather embarrassed to have used it here, really. I just wanted a name to sign on with, temporarily, like you. ;)

Nah, it's not that, though bharat even offered to change the name in IRC. I'll stick with it for now, because I can't think of anything better ;)

And I don't really mind the mystique it adds ;)

Besides, video gaming is the tech industry's little secret. I bet we'd all be working 10x more without it ;)

[Responding to Bharat. Skipping the quote, it would take too long.]

Theme versions - In a perfect world, the theme should work only with versions of a module in which the overridden files are not changed. Since we are assuming modules will need to be released to be downloaded by site admins and applied as updates, version increments should be possible, for all the "builds" available to download, if nothing else.

We can't confuse people with different versions of 0.82. If that means adding a build number (0.82.14) then we should. Using CVS would be too risky, and we can't assume everyone will be using CVS. What about Subversion, which doesn't version individual files with version numbers, but instead relies on giving versions to whole checkout/checkins (as I understand it).

Now, back to the themes. I doubt, once things are settled, that version numbers will change *that* quickly for most modules that would need to be overridden. But to help reduce the pressure on site admins (and theme writers who use these advanced features), we should double-check if overridden files *specifically* have been changed. If they haven't been changed, then ignore the upgrade when users visit the site, continue to use the themed override, and alert administrators with a "warning" instead of an "error". If the files have been changed, then we use the new versions.

Some of this could be avoided, however, if during module installation or activation, we check to see if there are any themes overriding files in this module, and see if they are up to date or not. If they aren't, we alert the administrator, and give the option of disabling the override, or avoiding the module upgrade/installation until they update the theme. Same with themes (ask if they wish to disable the override).

Another possibility, down the road, is to integrate some kind of diff with the logic, and attempt to merge the changes into the override files. (This would be my preferred option, and make it much easier for theme writers, especially if the theme is local, and not released elsewhere, or if Site Admins have even a basic understanding of web technologies.)

And, of course, a related option is to check for updates. I'm saving this proposal for another RFE, however, so I won't go in to too much detail here. However, we could also lookup theme updates when outdated overrides are encountered. If we've dedicated theme designers, this feature should be quite useful, especially if combined with an automatic diff/merge.

Renaming "Layouts" to "Views" - How about "Album Views"? Though I still prefer "Views". Hmm. The problem, at least from a designer's perspective, is that "Layouts" are very ... vague. It would be easy to mistake a Layout for a Theme, if you aren't used to how modular G2 is. Why I like Views, is that it's an established term for changing the way a list of files/objects are displayed, as used in many operating systems. For example:

So as you can see, everybody calls them "Views". It just make sense to use the word "View", somehow.

Themes without overrides - As I mentioned, it would be an optional new feature. Without it, we stick to the current CSS methods, using CSS as much as possible to override the default presentation of Modules/Views.

Require designers to know everything? - Well, once they pick up how to use Smarty, they'll begin to grasp the rest. They don't actually have to know how the module works, they just need to know where the HTML is and how they can change it. After all, they should be used to HTML ;)

Besides, this is an optional feature, for "power users" only. And if people prefer to use .local, more power to them. In fact, I encourage it - but only for changes that will not be (or would be useless to be) redistributed. (Such as making site-specific changes, like adding in a site name or experimenting)

Let's table the "Rename Layouts to View" idea for a second -- I think it's something that we should resolve, but it's a separate issue.

From our discussions, here are the salient points of the proposal.

* Themes have their own configuration page where they have a list of active/inactive overrides. I envision this as a list of modules and template files and an indicator that says that the override is active/inactive/incompatible. Users can toggle the status between active and inactive, but can't change it if it's marked incompatible.
* When we install a new module, we'll scan all the template files and update the overrides for all themes (basically leaving them alone unless they're incompatible in which case we'll mark them as incompatible).
* When we mark an override as incompatible, we'll notify the site admin. We can do this *before* we do the install process, so that the admin can abort the process (but then they'll have to revert to the older form of the module).
* We'll include a new definition block at the top of every template that will give us a list of all the variables used by the template, and what they do. This will help template designers (because it'll give them an idea of what all is available). It'll also provide our template compatibility checking code with a way of knowing whether the change to the template was cosmetic, or actually affects the structure of the template. This will save us a lot of churn in the themes because if you just change a little HTML in a template, the override will remain valid. Downsides: creation/maintenance of these definitions will take time, parsing them for compatibility will take time. (Alternative proposal: we require that every template create its own very simple API version number in a Smarty comment at the top of the file, and only change that version when the template input data changes).
* Override compatibility will be determined by our definition block. Might be easiest to just say that the override is valid if the definition block matches byte-for-byte (that'll save us having to do complex parsing, etc). We'll still want to have a pretty strict format for them (and maybe a unit test that audits templates to make sure that they have the block and that it's well-formed).
* When we include a template or a CSS file, we'll check to see if the current theme has an active override for the given template. If it does, we'll use the version from the theme instead.
* In the absence of an override, we look for a .tpl.local file and use that as an override.
* In the absence of any overrides, we use the existing module/layout's template file and apply our regular CSS rules (as we have now)

Open Issues:
* What happens if the override provides new text? We'll have to provide a localization framework for the theme in that case (ouch!). I vote we punt on this for now and worry about it later.
* A theme that provides a complete makeover of G2 would require the themer to tinker with 150+ templates and 10? CSS files. And that's just the modules we know about!

Let's let this simmer for a day or two, and if no new ideas fall out of it then let's move forward with it.