afuna: Cat under a blanket. Text: "Cats are just little people with Fur and Fangs" (Default)
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)



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
afuna: Cat under a blanket. Text: "Cats are just little people with Fur and Fangs" (Default)
ETA: Posted! http://dw-nifty.dreamwidth.org/4374.html (with minor edits, including removing exclamation points *g*)


So many people do not know that Dreamwidth has had custom reading list colors for a long time now!

Putting up a draft entry, shall polish and post to [site community profile] dw_nifty or [site community profile] dw_styles (but I think I may need to do a "here's how to create and start editing your theme layer" first, which I keep putting off)

Enable the custom reading list colors defined by your style



Custom reading list colors are disabled by default, so you'll need to enable it, but it is available for all styles (with the exception of Zesty).

Go to Customize Journal Style, under "Additional Options" select "Use my custom reading list colors"

Most styles implement it as a border around the userpic. However, some styles, such as Negatives, have implemented it as part of the entry border. If you don't like where your style puts the custom colors, you can also customize them by setting some variables in the advanced customization area.

Read on )
afuna: Cat under a blanket. Text: "Cats are just little people with Fur and Fangs" (Default)
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 [personal profile] 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)
afuna: Cat under a blanket. Text: "Cats are just little people with Fur and Fangs" (Default)
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.)

(Originally posted to Dreamwidth http://afuna.dreamwidth.org/6673.html)
afuna: Cat under a blanket. Text: "Cats are just little people with Fur and Fangs" (Default)
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.)
afuna: Cat under a blanket. Text: "Cats are just little people with Fur and Fangs" (Default)
One thing that has frustrated me about interacting with LiveJournal programmatically, is that ?format=light does not work on all pages. It's not really something that affects most users would notice, but certain (Greasemonkey) scripts would be much much easier to write if the entry/journal pages could be guaranteed to follow the same format.

Mostly I've kludged around it by working off of the archive pages, which respond to ?format=light, so I could get data consistently. I have a script which scrapes the lj-cut text, so it can be seen in the inbox which does this. [livejournal.com profile] murklins has done me one better, with a script which lj-cuts your inbox, like the entry text. I do not know how I ever lived without this. Lifesaver. Adore, love. Seriously.

But for other pages, it's been a process of trial and error, trying to figure out whether ?format=light is supported (tag page supports it, showing a page based on s1shortcomings). Uh. Archive pages, as mentioned above. Reply pages and entry pages, obviously, using core, I think.

Not affected by ?format=light are friends and recent entries. LJ site scheme pages, meanwhile depend on the user's site scheme, unless you append ?usescheme=blah, which I always forget to /o\

It's all possible, but it can get messy depending on what you're trying to do. Which is why I love that LJ offers a mobile view. Love <3

The gist of it is that LiveJournal offers a minimalistic view for mobile phones/browsers (I suspect screenreaders could benefit). No header graphics, less junk overall, more consistent look/feel, and most importantly if you're hijacking it for scripting, it works consistently! To trigger, you need to supply the appropriate user agent:

GM_xmlhttpRequest({
   method: "GET",
   headers: {"User-Agent":"w"},
   url: $url_here,
   onload: function(details) {
       // do something with details.responseText
   });



The important part is the useragent line. The rest is just the normal stuff you need to fetch and process a page.

I haven't used it in an actual script. And since I don't play around with LJ much anymore, I'm not sure when I will. But it is a potential solution to what has up to now been a tedious problem.
afuna: Cat under a blanket. Text: "Cats are just little people with Fur and Fangs" (Default)
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
[livejournal.com profile] 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
afuna: Cat under a blanket. Text: "Cats are just little people with Fur and Fangs" (Default)
Back in January, I realized that you could probably figure out which individual tags filter you were viewing by using the (newly-added) parameter to each Userlite data_link:

3:09 AM me: hm
3:10 AM me: ma thinking of s2 at the moment
does this entry : http://community.livejournal.com/changelog/4356263.html mean that we can determine what tagspage we're on by checking the data link?
3:13 AM murklins: Looks like, but how do you check the data link?
3:14 AM me: Page has a hash of data links


I meant to play around with it, so I posted about it to remind myself, and then promptly forgot.


Then in May, [livejournal.com profile] murklins(<3) needed to customize certain tags views, and reminded me about my idea:
12:51 AM murklins: Hey, this is how we find out if we're on a tags subset of the recent entries page right?
if ((size $this.data_links_order) > 0) {
  if ($this.data_link{"rss"}) {
    var Link dlink = $this.data_link{"rss"};
    if ($dlink.url->contains("?tag=")) {
      print "A Tags Page";
    }
  }
}

12:55 AM me: hee
I don't know :)
I don't tihnk I've ever seen that before
though the concept seems familiar, but my mind might be playing tricks on me
12:56 AM murklins: Oh, it was your idea! :)


And I remembered that I'd had that idea before, and decided to do something with it some day. (And then promptly forgot about it again.)

Then someone made an entry in [livejournal.com profile] s2flexisquares asking whether it was possible to hide a sticky post when filtered by tags. And I was happy that I'd finally have a chance to play with the idea (almost a year after I first thought of it), so I wrote code and replied with it. Then she asked me whether it would be possible to make it so that you could show the sticky post only for certain tags, and after shaking off some rust I came up with this code.

It could be more flexible -- right now it won't work if you filter by multiple tags, but it's good enough, and I'm not crazy enough to try implementing a join/split function in S2.

(What if I made the tags an array instead of a hash? That would make it easier to input tag names -- ["tag1", "tag2"] instead of {"tag1"=>true, "tag2"=>true}, and it's unlikely that the list of tags this is used on would be long enough to affect performance either way.)

Other possibilities are to change colors or images depending on the tag that you're filtering by, or to change the behavior of entries with certain tags (for example, only show summaries for fic-related tags). And others! If you were motivated enough, you could make subtle changes to your layout for each tag you have. I'm not that motivated. :-)

January 2017

S M T W T F S
1234567
891011121314
1516171819 2021
22232425262728
293031    

Syndicate

RSS Atom

Most Popular Tags

Expand Cut Tags

No cut tags