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?

A while back I mentioned that I was considering modifying LogJam to add persistent templates for posts.  It since occurred to me that there’s a very much simpler way to achieve the same result:  Add a preference option to keep saved drafts after posting, which suppresses the “Delete this draft from disk?” prompt and action.  Enabling “Keep saved drafts after posting” de facto turns the drafts list into a list of saved persistent templates.  (They can still be deleted if desired from the ‘Open Draft’ dialog, so no functionality is lost by turning this preference on.)

A patch against Logjam 4.5.3 to implement this feature can be found here.

(Crossposted to logjam)

I'm thinking about making a modification to LogJam that would add a major new piece of functionality, but mostly using existing code to do it.  I intend to adapt the existing draft-handling code to add a template feature.  Templates would mostly be handled and treated the same as drafts, except for the following:

• Templates will be stored in a separate directory from drafts.
• Templates will be listed in alphabetical order in the "Open Template" dialog, which will otherwise be just like the "Open Draft" dialog.
• The subject line of a template will always be cleared on load.
• LogJam will never prompt to delete a template after posting.  It will assume you wish to keep the template.  Templates must be manually deleted using the Open Template dialog.

Before I get started on this, is there anything else I should be taking into account?

I was pondering today making a patch to LogJam to add a text autoreplacement feature.  What I had in mind, at the most basic level, was simply scanning the article body before posting and replacing all instances of ' -- ' with ' &mdash; ', simply because I've gotten tired of typing '&mdash;'.  A more sophisticated approach would be to extend the preferences to add a user-editable list of find-and-replace operations which would be automatically performed on the article body at posting time, possibly with a few predefined sample replacements (like the example above) and checkboxes to select which of them the user wanted to have applied.

The question is, I don't have a good feel for the overall architecture of LogJam; if I was to start out with the simplistic hard-coded replacement strategy first described above, where would be the best place to do it?  Or to approach the question a different way, where in the codebase does LogJam actually post articles (new or edited)?  I don't actually know enough about the LiveJournal API to know what I should be looking for.

Update, thirty seconds later:

Of course, thirty seconds after posting that, I just found it.  :)

I'd still appreciate feedback on the idea.  What does anyone else think of this as a feature?  I'm going to implement the simplistic approach as a proof-of-concept.  Does anyone have implementation suggestions as far as a more sophisticated and flexible approach, as described above?