development corrupts

Edited slightly, and posted to http://dw-styles.dreamwidth.org/13219.html


The basic settings to customize your theme can be accessed and modified via the Customize Journal Style page. However, if you're doing something more complicated, you may need to modify code snippets or manually set some variables. For these, you will need to know how to create a theme layer and attach it to your style.

First of all, a quick rundown of terms:

A style is what is applied to your journal, and it is made up of several layers. A layout layer is the basic structure or framework of the style. Customizations via the Customize Journal Style page will be saved as auto-generated customizations in a user layer. Any other modifications you make, you should do in a theme layer. A theme layer can contain system-provided default color settings; it can also contain any additional advanced customizations you wish to apply to your journal.

Technically, you can just modify a user layer, and it seems easier to do that, because it's already been created for you and you can skip the few steps required to create and attach a new theme layer to your style. However, this is a bad idea, because hand-edited changes to a user layer may be erased the next time you use the wizard. To be safe, always create a separate theme layer if you need to edit something manually.

(!! the links will work from single entry-view; they'll also work from read page, etc, when I post the final entry)

• Find your current style information
  
• Create a new theme layer
  
• Copy existing theme layer settings to your new theme layer
  
• Apply the new theme layer to your style
  
• Tips
  

( on with the tutorial )

For the record, I now hate the advanced customization area and want it to die die die :-) Setting things up is way more complicated than it should be

I find myself utterly in love with the creativity of people who can use CSS. Because, hey, I'm happy with black on white and everything in outline form and utterly utilitarian myself, but that doesn't make for gorgeous. (My heart flutters every time I see someone take a Core 2 style, and make it really pretty, because that's what they're there for.

My heart also bounces with glee whenever someone mentions that it's easier to customize styles here than they are used to, because that's what all we did was for. Seriously, ba-dump-thump.)

Styles still not done, though. On my list, once I'm no longer focused on open-beta-blockers and the styles usability bugs being reported to us, is, in no particular order:

• sticky entry module


• custom text module


• hooks to let layout authors easily insert custom modules


• segment and arrange the wizard properly (subheaders, etc)


• pulling in information that's already available to us in other places, to be accessible using S2 (la la la la)

The one thing that I'm finding out is how easy it is to manipulate the S2 backend. Perhaps too easy. I find myself wondering whether my methods are hackish/messy and will cause problems down the line later on.

(I'm already trying to stop myself from trying to redo the grouping stuff as hashes with lots of automagic rather than arrays. Imagine being able to do property string{} module_customtext_group { grouptype= "module" }; and have it pick up the title/name/opts automatically instead of having to do a set module_customtext_group... Feel like I missed my chance on that one, now I have to do the grouping manually all the time. Bleeeeeh. (but it works, I'm happy with it))

But before that, business statistics, which I am working with, with pauamma. We've got some kind of framework hashed out, now just need to figure out how to do the selects for data collection (I say "just", but since that's the entire point of what we're doing... hah!).

The biggest problem with the SQL is that we're basically going to go through all the user accounts for data, e.g, account types. How to do this without bringing the DB to its knees? Suspect I shall need to talk to friendly neighborhood database administrator soon-ish.

Stuff like -- group by looks the easiest syntax-wise, but has to load everything in the database in one go, and that probably won't be pretty. bin/maint/stats.pl splits users into blocks, and iterates over each of the rows a block at a time. Or could you combine the two, split into blocks, and groupby within that block? Ponder, ponder, beard-stroke, etc. (Thinking out loud, will wander over to IRC and try to find a good time to talk at some point).

It's April 20. I'm so excited. Also, feeling the lack of time. (I do wish it was faster to get into the zone, though. I usually sleep Saturdays away, which leaves only part of Sunday to do code, and there's so much to do. Grr)

For instance:

    foreach var string module ( $*modules_available ) {
        # FIXME: get the values in less hacky manner
        var string section = get_plural_phrase( 0, "module_${module}_section" );
        var int order = int(get_plural_phrase( 0, "module_${module}_order" ));

        $*module_sections{$section}[$order]=[$module];
    }

(but I should probably not let something like that creep into core. Long list of if-statements, it is.)

Not the inside-inside, Perl guts, but trying to update all (DW) layout layers, to get all the updated features!

Long-term goal (actually, medium-term, because once the site goes live, everything needs to be stable, so I won't be able to do any drastic changes) is to turn this layout/feature chart entirely green. I know it's not possible; I can at least try what is reasonable.

One The hard thing about developing with S2 "officially" is that the quickest (only?) way to get feedback on your changes is to apply the layout to your journal, use the S2 compiler (layeredit.bml), apply changes, check journal, rinse repeat. However, then you have to copy the updated layer to bin/upgrading/s2layers. I've found that last step error-prone: tedious to pick out the changes bit by bit and transfer them manually. If I try to replace the entire layer in one go, I find that I have a hard time copy-pasting more than a screenful in vi (hm, have I ever tried just truncating the file and then pasting everything into a blank file? I don't think I have. Maybe I should do have tried that before trying to work around it).

So, anyway! Perl script! You give it the name of the layout. It reads the updated version which is currently "live" (on your dev site need to set the base URL; localhost works fine reads from ljconfig.pl). It then updates the static file in bin/upgrading/s2layers. After that, just need to do cvsreport.pl or hg diff or svn diff or commit or whatever. I've stuck in my ~/bin, so I can run it from anywhere, which is pretty convenient:

http://afunamatata.com/scripts/dreamwidth/s2sync.old

(This assumes that $LJHOME is set properly, and live versus cvs directories are in their normal LJ-setup locations, though this is really more for DW, since it overwrites bin/upgrading in DW-free)

( Sample in action )

At some point, I may find it useful to modify it so that it accepts and upgrades multiple layouts (and themes??), but too much trouble to do so now, since I'm not touching themes at all.

And hopefully this will make development that much easier :) I was dreading keeping my live layout versus my diff-able layout in sync, but I am looking forward to coding this weekend now.


Update
exor674 just came up with a much prettier version <3 http://pastebin.com/f2fc673b3

I'm appropriating it for my own use.

Update2
Slightly tweaked version here: http://afunamatata.com/scripts/dreamwidth/s2sync!

(Basically, sanity check to make sure it's a layout layer, and also put the output directory into a variable, so that people who want to stick it straight into live instead of under cvs/ can change just the one line)

It now accepts either layer id (as a number), or layout name or redist_uniq, so either of these will work:
$ s2sync 333
$ s2sync bob/layout
$ s2sync bob

Also, output slightly changed:

dh-afuna@li-166:~/dw/cvs/dw-free$ s2sync 336
Can only handle layout layers at /dreamhack/8080-afuna/bin/s2sync line 33.
dh-afuna@li-166:~/dw/cvs/dw-free$ s2sync 333
bob/layout written to /dreamhack/8080-afuna/dw/cvs/dw-free/bin/upgrading/s2layers/bob/layout.s2