January 10th, 2004

  • alc

(no subject)


I'm using Opera as my web-browser and it's perfectly good for me. What I like in it is that Opera uses its cache in pretty effective way, say it won't reload page when you click Back button, it just shows you the one from its cache. The second example it when you follow the link that was visited by you a minute ago it won't reload it as well. Collapse )

binary and a cookie to whoever notices
  • xb95

S2 Fun and Games!

Okay. I would like to claim to be the first person to have written a game in S2. What? Huh?


Source is messy but available:


I suppose there are probably better ways to have done this, but this was the first thing that occurred to me at 2:30 in the morning, and so I went with it.

I know it's not strictly development, but I thought the group here would get a kick out of it. Enjoy.
  • mannu

Typable Move: An MT-like S2 layout

Link: http://mannu.livejournal.com/

I've created a S2 layout that looks like Movable Type's Main Index default template. Do I have a chance of getting this into the LiveJournal.com default layouts? I'll be glad if people can use my work.

Link: http://www.livejournal.com/customize/advanced/layerbrowse.bml?id=620777

Legal: Mind you, it's a creation, not a "port". The distinction here is important due to the fact that any public S2 layouts need to be licensed under the GNU GPL. It's not like I've taken any code from MT and modified it to suit my LJ needs. Even if that were the case, I'd be within my rights to use the layout on my own journal (with a "Powered by Movable Type" logo and little things like that). I have, however, written the layout code from scratch. It only refers to the CSS classes of the various default MT styles. It's a clone, not a port, of MT's Main Index default template.

So how do I make my 355 lines of S2 code available for the general public?
amused, happy
  • mart

User/UserLite Equality

At the moment all of the S2 layers are checking the equality of users by comparing usernames. However, usernames aren't really so unique anymore. In future, they'll get even less unique as we start supporting multiple namespaces etc.

My proposal is simple. Include the userid in a hidden member in UserLite (not accessible from S2 code) and provide a builtin function equals(UserLite other) which returns true if the userids match or false otherwise.

If we do this now it'll reduce the number of layers that have to be changed later.

amused, happy
  • mart

S2 i18n templates

It'd be pretty cool if we could generate template i18n and i18nc layers (in English) from the layer they are intended to localize. This seems pretty easy apart from one minor issue which I'll over later. However, here's the part of the plan which works:

We already have modifiers on functions, given in square brackets after the parameter list and before the type. I propose that we add a similar modifier capability for properties, like this:

property string text_blah_blah [i18n] {

Given what modifier I used as an example you can probably guess what I'm going to propose for functions:

function server_sig() [i18n] : void;

The above has the problem that at the moment modifiers go on the function implementation header, not the function declaration header. This doesn't matter for global functions (their declaration and implementation are the same thing) but class methods will want this modifier on their declaration so that it can be included as part of the internal class documentation. I don't know if modifiers are valid on method declarations; having them on both would be kinda confusing, anyway, I guess. *shrug*

The minor issue I spoke of before is that the template functions will need to initially have the body of the original S2 function as an example to translators. There's no point in making this template if the translator still has to read the original source to find out what exactly a function is supposed to do. The only real way around this is to include the S2 source in the internal docs for i18n functions, but that's pretty ugly. Any ideas?

The upshot of all this is that then there can be a new option on the Layer Info pages of core and layout layers to get a translation template, which will build an example i18n or i18nc layer containing the English from the original layer which the translator can then edit.

I think this'll make initially creating i18n layers for new layouts a lot easier, and we can also get shot of all of the “i18n layers should override this” junk at the end of lots of the function docstrings.

amused, happy
  • mart

Partial overriding of S2 hash properties

Some layouts (probably just A Sturdy Gesture, actually) use hashes for some translation strings to make the code easier later. A Sturdy Gesture, for example, uses two hashes to deal with the labels on the links for entries and comments. (which should really be in core or supplied by the backend from the translation system, but I digress.)

The problem comes when new links are added in future, causing the parent layer to have a new hash key added. Child layers (i18n or i18nc layers) will still lack the extra key, so journals in that language will lack one of the text items probably leading to a blank link.

What I'm proposing this time is that we allow hash properties to optionally do “partial overriding”. This involves changing make_context to pick up on a property attribute partial_override and, rather than just assigning the new hashref, actually copy the keys one-by-one into the existing hashref, meaning that any keys which are not overriden remain in their English form. This isn't ideal, of course, but it's better than no string at all. It can be an option which is off by default since it's obviously faster to just assign the new hashref and probably desirable in some cases.

Sound good?