July 31st, 2002

amused, happy
  • mart

Difference in Vision

Brad and I seem to be thinking about things a little differently when it comes to the use of S2 on FotoBilder. There are a lot of things he seems to want which I didn't consider and vice-versa. One of these which I can pin down is a difference of opinion about the point of separation between stuff that's set by settings and stuff that's set by styles.

When I was designing the core1.s2 I sent to Brad, I was thinking along the lines of "make styles flexible so that users can easily change settings for specific galleries and pictures via metadata. The layout of Brad's code seems to suggest that he's more going for things like the size of thumbnails, number of thumbnails per line and so forth being set in the style.

I think it's important that anyone should be able to take one of the stock styles (or, indeed, design their own single layout) and be able to apply it to many situations where the size of thumbnails can vary and the number of thumbnails displayed on a single line can vary, to name only a couple.

My design employed a set of predefined "Picture Views", which are forms of a single picture. At this time, the only "alternate form" available for most pictures is a different-sized version, but a Picture View could pretty much be any kind of modification permitted. The predefined ones were an array of thumbnails and a single "full picture". The array of thumbnails would be set up for the gallery and certain styles would be made to expect different amounts of thumbnails but, ideally, still be able to cope with the minimum of one thumbnail. The "full picture" would obviously be the full-sized version of the picture.

Brad's design also has Picture Views, but they are represented by the Image class and aren't such a specific concept. These are obtained by the style by calling a method of the Picture class to get a thumbnail of a given size which it can then use in output. This gives loads of flexibility, but it means that a given style will always display a thumbnail gallery in the same way, regardless of the particular requirements of a given gallery which would need to use a different style to compensate.

I propose a compromise. My 'array of thumbnails' was not a good design now that I consider it more. Instead, I suggest that there only be two predefined PictureView objects, the first representing the gallery's idea of a "default thumbnail" (which is part of the gallery metadata, perhaps) and the second representing the full picture as I had before. This alone would hamper flexibility, so here's the interesting part…

A builtin method can be added to the PictureView class which takes $this and performs some modification on it. At this time, the modification can only be more resizing, but in future it could also be cropping, changing gamma, reducing to greyscale, or other interesting thing. This would be represented, for simplicity, by an operation string and a "parameters" string, so that only one version of this function needs to be defined in the core layer. This function will then perform some magic on the URL it's the PictureView object already has to add the new settings to it, cancelling out other settings were it makes sense or has to be done (which will be documented, of course).

The result is that, for example, a particular style can take the "default thumbnail" it's given and use it as a template to produce a greyscale thumbnail of the same size, without it needing to only support a given size or even be aware of what that size is in many cases. This also means that if a particular image is set to have its thumbnail generated by a cropped version of the image resized, the extra greyscale operation can be piled on top without it needing to be aware of the elsewhere-defined crop zone. (Crop zones are obviously image-specific, so definitely don't want to be set by styles)

I'd be interested in people's thoughts on this solution, as well as any modifications to it which might be a good idea, or better plans to replace this one. (but only if they're equally or more flexible! ;))

black & white
  • texel

mac os x

hey everyone...

i asked evan if anybody had expressed interest in developing a mac os x client for fotobilder, and when he said "no," i quickly slapped him in the face, and proved him wrong by saying that *i* would like to start said project.

anyone else interested in working on this? evan also said he'd send me some info that i'd need to get started, but i haven't received it yet, so he gets another slap the next time i see him.

Feature request

I get redirected to the login page when I try to go somewhere like /manage/styles while I'm not logged in. Could I get redirected back to /manage/styles (or wherever I came from) once I log in?
  • brad

summary of CVS commits

-- add directory for upcoming Apache-style Directory Indexing layout

-- update S2 compile-all.pl script to only compile things that are out of date.

-- more work on the style selector/editor

-- S2 compiler bugfix: die on use of unknown properties earlier, rather than dying with mysterious null pointer deference in a deeper type checking phase.
  • brad

Another project for somebody

I need a color selection widget in JavaScript.

It should be like this:

Modifying text should update the colored area.

The "Pick...." button should pop open a new window where they can select their color from a Hue/Saturation grid, with a brightness control on the side, and an "Currently Selected" color, then OK and Cancel buttons.

It should be invoked by a function call that takes as arguments the text box widget to update with the color. (and when you update that, that event will fire and update the color cell)

Any takers?

pooh piglet
  • niro

fotoup.pl backend proposal.

Ok, here's my basic interface idea, I haven't had the chance to think through it all very completely yet, so some of it is incomplete.

New command line options:
-b --backend puts it into backend mode, when in backend mode all other command line options are ignored.

In backend mode it reads commands from STDIN, responds to STDOUT.
commands consist of a single word command (made up only of word characters, typically all uppercase) optionally followed whitespace and arguments.

Responses consist of a single uppercase character, optionally followed by a single space and arguments.


SERVER <server> - Sets the server to use.
USERNAME <username> - sets username
PASSWORD <password> - sets password
DEFAULTSEC <seclevel> - sets the default security level.
AGENT <agentstring> - sets the user-agent http header.

PICSEC <seclevel> - sets the security level for the current set of images.
PUSHFILE <filename> - Adds a file to the upload queue.
PUSHGALLERY <galleryname> - Add a gallery to the list of galleries the queue of images is placed in.

UPLOAD - uploads all the files in the upload queue to the galleries specified in the gallery list. Clears both lists upon completion.

EXIT - Does cleanup, and exits.

I haven't figured out the best format for all of these yet, but here's a few.

S - the last command sent was successful.
F - The last command sent failed to execute.
E <human readable error message> - Sends and error string. I'm not sure whether or not it would be usefull to have a machine parsable error message too, if so the format would be:
E <errorcode> <human readable error message>

I haven't figured the best way to do progress bar info yet. it will likely look like this though:
P <percent>

U <shortname> - image successfully uploaded.

As I said, I haven't figured everything out here yet, there should probably be a bit more status information returned.
Note that the command may return an error and still manage to execute, e.g. one of the files doesn't exist, the rest may still be uploaded. In this case it sends the error, but still sends a success, if it fails it should almost always send an error message with why, but may not.

If you have any bright ideas about the best information to send for progress bars let me know, also from a front end perspective what other information is relevent? Right now I'm somewhat brain dead on the matter, I'll get better once I actually put together a front end for it though.

I'm also tempted to have the commands a bit more rigid, so that in the initial mode you can send SERVER, USERNAME, PASSWORD, AGENT, and DEFAULTSEC. Then you enter a different mode, perhaps with "UPLOAD BEGIN" where you can use the PUSHFILE and PUSHGALLERY commands, then send the UPLOAD END or UPLOAD EXEC or something to finish it.