August 7th, 2002

  • brad

User layers as themes

(Mart, this question's basically for you, but I'll ask it here.)

Background: S2 layers are applied in this order:

Core: defines all the basic classes and functions.

i18nc: language specific overrides to the core
Layout: also on top of core, can add more functions specific to that layout.

Theme: color/image specific overrides to the layout
i18n: language specific overrides to the layout
User: any last overrides the user wants to change.

Now, I want a user to be able to make the user layer with a wizard. But, when they change their layout, their user layer for that style is destroyed, since a user layer is specific to a layout.

So, I want a way for users to save their current user layer as a theme.

But, as a theme, that means i18n settings will then override their choices, which seemed to work before (in a user layer) but no longer (in a theme layer).

So, I propose switching the priority order between theme and i18n.

A well-designed theme won't ever touch the i18n properties/functions, unless it's a user theme.

Perhaps we should also define a meta-data flag for i18n properties, so if we ever have a "submit your theme as public" tool, we can verify the theme they're submitting doesn't trample i18n settings. (but, this is way future. for awhile we'll just process incoming themes by hand.)

Anyway... objections to swapping theme and i18n priority? I'm not forgetting anything important, am I?
amused, happy
  • mart

Minor Bug in the Palette-transform code

While I was playing with my colour picker, I noticed that if, when editing a GIF palette on-the-fly, you try to change palette index 255, you get a corrupted image back. I'm guessing that the palette transform code is writing out of the palette segment of the file, but I really have no idea, and looking over the code gave me no clues because it's getting late and my brain is tired.

concerned, frustrated
  • mart

Cross-browser DHTML Realisation

The suckiness of it all just hit home.

It was all going really well, until I noticed this interesting discrepency: In Mozilla events fire with a scope chain starting at the object which fired the event, then the window containing that object. In Internet Explorer 6, events fire in the scope their event handler was defined in. Given that I'm used to how CODE refs work in Perl, I was expecting the latter behavior, and it was all going well until I got to cross-browsering my clicky-choose-hue box.

What's more, Mozilla doesn't seem keen on letting my window talk to window.opener, so I can't fake IE's behavior by making explicit calls into the parent window's scope. I'm just wondering if any of those folks who said they do this kind of thing for a living want to give me a hint on how to get around this one…

Might as well throw in a screenshot, too.

The lightness gradient is off by one pixel because of the bug I reported a few minutes ago regarding colour transformations on the full 256-colour palette.

Update @ 2:05GMT: It's fixed, and it wasn't nearly as painful as I was expecting:

  // Copy some functions into the picker's scope so events can hit them
  p._HSVtoRGB = _HSVtoRGB;
  p._varstoform = _varstoform;
  p.setBGColor = setBGColor;

It's an ugly solution, but it works and doesn't involve duplicating anything apart from three references, which I assume are pretty small. I'm back on track now.