LogJam Development

Andy,

Here's the third of my patches.  This one should probably be optional, which is why I've posted it separately from the other two.  It adds no functionality as such to LogJam, aside from adding two accelerators (Ctl-I for Insert Image and Ctl-D for Open Draft); it's primarily a usability patch that rearranges the top-level menus into an order I find more intuitive.  I always found the out-of-the-box top-level menu order in LogJam awkward and clumsy.  I was constantly having to hunt back and forth on the bar for the menu I wanted, because they were placed with no apparent rhyme or reason, and after a couple of weeks of using it (about eight years ago now) I gave up, went into the code, and patched it to rearrange the menus in an order I found more usable.

This patch leaves the LogJam and Edit menus first, where they belong as standard menus that are always first in every application that has them.  It then arranges the remaining menus in order of increasingly fine detail from left to right: View (application-global UI settings), Journal (selection of journals and operations on specific journals), Entry (actions on the current entry within a journal), Insert (insert high-level objects into the active entry), and last of all HTML (insert individual HTML formatting tags into the active entry).

Not every user will want this patch, but I find LogJam much easier to use with this modification, and wanted to put it out there in the event that other users want to try it.

Andy,

Here is a patch (in gzipped Unix unified diff format) which adds a comment-screening control to LogJam 4.6.0.  This first one should be a completely straightforward issue.

This second patch adds a large number of additional HTML tags to the HTML menu, in support of which it modifies the html_mark_tag() function to properly handle the <span> tag.

(This could technically be extended to handle any other tag with arguments, such as <div style=...>, but that would quickly get ridiculous.  <span> itself is necessary because <span style=...> is the only reasonable way to do small-caps formatting.)

After a week and a half or so banging on hardware, I got back to my LogJam updates.  Since auto-crosspost is not available to standalone clients and doesn’t sound likely to be so any time soon, I’ve removed the code for that.  About the one thing I still need to do is find a good, clean way to be able to extract the site hostname (which turns out to be surprisingly difficult to get at in the LogJam data structures) so that LogJam knows whether to use and submit the adult_content_reason property (Dreamwidth only), whether to ask for a site field (Dreamwidth only) in <lj user=“”> tags, and whether to use <lj-cut text=“”> (on LiveJournal, InsaneJournal, GreatestJournal etc) or <cut text=“”> (on Dreamwidth).

As previously noted, I may also need to revisit the issue of templating; template storage probably needs to be moved up at least one level, from specific LiveJournal sites to the level of all-LiveJournal-compatible servers.  That’s a separate issue from getting LogJam working properly on Dreamwidth though.

I’ve occasionally run into a problem in which trying to re-open a post for editing results in a failed request with unrecognized headers from the server.  I haven’t fully diagnosed this yet.

I’ve discovered that there’s a functional problem with my “keep drafts” workaround for implementing templates.  In short, the problem is that drafts are server-specific, while templates really should be global.

I’m clearly going to have to revisit this.

This question is primarily for Evan, but anyone else feel free to jump in ...

I’ve just begun the process of extending LogJam to work on Dreamwidth by adding the additional fields to support the auto-crossposting feature of Dreamwidth.  This of course requires that I modify liblivejournal to add the additional fields, during which I noticed that the liblivejournal code I currently have does not support the adult-content field of Livejournal.  So livejournal needs support added for the adult-content selector, while dreamwidth needs support added for auto-crossport, age-restrict (Dreamwidth’s version of LJ’s “adult content”), and restriction reason.  (It may also be necessary to have support for the list of crosspost sites, or that may have to be left — for now — to whatever default is set in your Dreamwidth journal.)

Here’s the key question:

Is it intended that the correct way to do this is to create a liblivejournal/dreamwidth directory under protocol, copy the liblivejournal/livejournal code to it, and make the dreamwidth-specific changes there?  Or should I keep it all in one place and make the code conditional on which server is being accessed?