July 26th, 2002

computer crap

Security Group Editor

I've been working on a security group editor as per brad's request. I'm about to go to sleep now because I'm really tired, but I'll definitely have it finished tomorrow since it's about halfway done.

I'll post here again after I've submitted my patch, received complaints from brad, then fixed those.

What's everyone else working on?
  • brad

more S2 fun


Mart's still missing in action, so I'm doing more: You can click galleries now! (oh boy)

Go read the S2 source for everything... that's a lot more fun:

$ cd bin/upgrading/s2layers/
$ $EDITOR *.s2

I've changed my mind about 10 times over how I want to implement (well, store in the database) palette-modified nav icons on the server, so I'm going to sleep on it. Hence, the goat's still there as a placeholder.
Peek a Boo!

Black Gallery Name?

Should a blank gallery name be acceptable? I just pressed the space bar to have a blank charater and it worked when I saved the settings.

It could be confusing to people if there's no gallery name and/or can't find a link to click on.

Update - Fixed by a patch (I think) - link
  • mart

core.s2 MartStatus

I'm currently merging my stuff with Brad's stuff so that it stays compatible and we don't need to start a new majorversion already. Most of what Brad wrote is the same as mine with different names anyway, so this probably won't take too long.

I'll probably have the first version of this thing done in a few days or something. Sorry for vanishing.

  • brad

On-the-fly GIF palette modifying

On-the-fly GIF palette modifying is done, and it's incredibly fast:

We start with...

Let's change palette index 0 to green!

And palette index 1 to orange!

And palette index 3 to yellow!

Best of all, we still get cache-control with all this... etags still work, etc.

And this concludes the palette swapping demonstration.

Now to start reviewing Mart's huge fricking "I'm back from the dead" S2 file.

amused, happy
  • mart

Things that aren't images

It was once stated that FotoBilder should be able to handle other fun things such as Flash animations and movies. This is all very well, but right now the S2 stuff assumes that everything is an image. Therefore, here are two ways we could make the S2 classes future-proof with regards to other data formats:

  • Standardize on using <object> for everything. This is a generic HTML replacable content element and is capable of embedding just about anything as long as there's browser support for it. For this to work effectively, the S2 stuff needs to have the image Content-type available to it, which is easy enough as it's just a string. The caveat is that <object> only works in recent browsers.
  • Extension of the previous idea: add a string field in the picture class to hold one of "img" and "object", and therefore by extension any future embedding mechanism needed. The handler functions can then check that field and select the relevant display mechanism, and if it's not supported default to object or perhaps output some text explaining that it can't be handled. (I'm not sure which is best: both have advantages and disadvantages)

I'm interested in what others think. A valid opinion can also be "we don't need to support things that aren't images", which means that I can stop thinking about this and carry on with only-images support. I want to get this in now rather than adding it later because it'll be a pain to make a future modification backwards-compatible and thus we face the need to rehack a whole load of layers to work with the new stuff or else they'll make galleries full of broken images.

Update: I also seem to remember that right now, due to shortcomings in IE's plugin support, Scalable Vector Graphics can only be loaded via the <object> element and not the <img> element. FotoBilder doesn't support SVG right now, but it might want to later? (and other sites might want it to?)

  • brad

Template Images ... working.


See the image there from last post? It matches the color of the text.

An S2 layout or theme layer just needs to define a property:

property string home_image { noui = 1; }
set home_image = "http://www.picpix.com/brad/pic/00033f2e|50|50|fgcolor|fgcolor|fgcolor|fgcolor";

And then in its code:

var Picture home;
$home = palimg_create($*home_image);

Note that the first argument in a paletted image spec can be either a URL (to your own pic, or to a remote picpix server), or a named system entity.

I have discussed named entities yet.... in a nutshell: users will be able to define URLs for any object... picture page, photo, gallery, etc..

When you run update-db.pl, resources which redistributed layers use will be put in the database for user system, given a upicid, and have the unique resource name mapped to that... then the layers only refer to the resource name.... webserver cache mappings for system user... all is fast & low memory.

Anyway, I'm off to the beach for awhile.

Happy Hackin'!
amused, happy
  • mart

Things that should probably change in S2

Over the time I've been working with S2, I've noticed a few things which should probably be changed. Here's a list of ones I remember right now.

  • Variable/member names should not be allowed to start with underscores. This prevents the namespace conflicts with the perl backend's (and probably other future backends) $_ctx (context) variable and $thingy->{'_type'} (object type) hash element along with other stuff added in the future.
  • An isnull operator would be very handy for representing "empty" objects. In LJ's class library in particular, there are some things which are often there but in some cases are left blank because they are not applicable in one small case. Thankfully there aren't actually any of these on FotoBilder yet. I propose isnull $.whatever mapping to $this->{'whatever'}->{'_isnull'} which can then be set by the backend which forms the initial data structure to flag empty stuff more cleanly so that code can just do if (isnull $somelink.image) rather than checking on members of it as my code does now.
  • The S2 compiled and source data is stored in BLOB fields. While I suppose that technically the compiled data could one day be binary (compiled C code, perhaps) the source is always going to be text. Why do I care? Mainly because my GUI interface for fiddling with my DB in realtime won't let me edit BLOB fields because they're binary. ;)
  • Update @ 17:09 GMT: It's possible to create an infinite loop by messing with the array in a foreach loop. I thought I submitted a patch for this before, but since the current code doesn't seem to have it I guess I didn't ever submit it. The patch involved using grep( { 1; }, @{$whatever} ) to create a copy of the array. (Thanks to youngoat for reminding me of this half an hour after I overwrote my compiler sources with the ones from danga CVS! It was youngoat who alerted me to this originally.)

I've noticed other things in the past, but I've forgotten them now. Hopefully they'll come back to me as I'm writing the initial stuff for FotoBilder and I'll add them here.