Patching a style

[liv]

I claimed branchandroot's really awesome Mobility layout, partly because I wanted to flex my muscles and try a complete new layout as well as just themes, and partly because I was in love with the idea of a style that looks attractive on mobile screens and on full-size, high-res desktops. This isn't a walkthrough, just a list of little things that tripped me up / new stuff I discovered for future reference.

Doing the layout, following the styles and themes newbie guide, was relatively straightforward. There were a few little tweaks which ninetydegrees pointed out in her code review. For reference:

• No need for set theme_authors in theme layers if the theme author is the style author, it'll inherit.
• We alphabetize userprops in each section now, rather than the old way which involved dividing things into subsections like page, header, footer.
• STYLENAME.pm is used to sort custom props into the appropriate tabs of the wizard, but NB the Presentation tab is, confusingly, called display_option_props

One weird error I ran into was that at some point I made theme layers using the wizard, copied the relevant code into themes.s2, updated the database and couldn't get the themes to show up. I went into #dreamwidth-dev and asked for really basic troubleshooting advice, on the lines of "is it plugged in?" Checks they suggested, which may be useful for future reference, are:

• Did you actually save the files after editing them?
• Are you on the right branch?
• Did you update the database (dwdb) before visiting your hack?
• Has the browser cached a stale page?

Turned out it was none of these, but that the file had somehow randomly been switched to Mac-style linebreaks when they should have Unix-style linebreaks. (It was sophie who managed this impressive feat of troubleshooting!) Since nothing was ever opened on a Mac at any point in this process, and since I never intentionally changed the linebreak style, I have NFI what happened here, but at least I know for future that if a change just randomly has no effect, it's a thing to check.

Things got more tricky when I was asked to redo the style as a child of Tabula Rasa. I didn't actually know how children of Tabula Rasa work, so I went down a lot of blind alleys. I ended up documenting the correct process on the Wiki at Style based on TR. Key facts are:

• If you make your layout a child of TR in s2layers.dat the system automatically appends all the TR code to the beginning of the layout layer.
• When sorting properties that are either custom for the layout, or aren't exposed in the wizard in TR, you need to use propgroup presentation_child {} instead of propgroup presentation {}
• You can't have two lots of Page::print_default_stylesheet() in the same layer, that just ends up with TR's (extremely sparse!) stylesheet taking priority and the layout stylesheet not being applied at all. Instead you have to change the stylesheet printing function to print_stylesheet () (NB this is not a Page:: object.)

PNG images have to be colour indexed, and not have colour profiles. This can be done in Photoshop by changing Image Mode from RGB to indexed. To my eye this degrades the quality of the images quite a lot and visibly alters the colour palette, but if that's the way we do things then that's the way forward in future.

And finally, jack taught me some excellent Git tricks I hadn't known before. I was getting a bit antsy that when I do $ git commit I could no longer see which files have changed, unless I do $ git push and then go and look things up on the GUI at GitHub. And it seems a bit silly to go around pushing commits to the public repository just so I can keep track of the files! It turns out that the secret is $ git diff --stat: this lists the files that have changed in the current commit, just like the list that you get when you do $ git status after add but before commit, ie when the files are still in the staging area. If there are multiple commits in the branch, you can do $ git diff HEAD^3 --stat to look at the combined changes in the three most recent commits.

My lovely husband also showed me how to squish multiple commits into one and make a clean branch. First of all you have to go to the messy multiple-commit branch, and do $ git status to find out the hash that represents the state of the code at the beginning of your branch. Then $ git reset --soft <hash>. (jack explained to me that git reset notoriously does completely different things depending what options you use, but this one works for this job!) That puts all the files back in the staging area; if you then do $ git commit you get a branch with a single commit containing all the files modified in multiple commits before.

It may be possible to push this to GitHub and overwrite the messy branch, but it isn't obvious how to do so, because the clean branch will clash with the multiple commit messy one that's already there. But Git can magically get round this! You need to create a new branch, not from develop but from your old branch. The new branch will have the single merged commit from the old branch as its top commit, so you can just straightaway push it to GitHub.

Et voilà! I am actually liking Git more and more the more I explore it, it's obviously way more powerful than I can benefit from right now, but it seems to be pretty good at doing the right thing if you know the right searches to find the appropriate syntax.