Print

[geniusalz]

Here are my thoughts on skin scripts:

Control of the scripts should be with the user, as opposed to the skin maker.

-Skin scripts should be 'installable' onto any skin without manually editing the skin's xml file.  (that's a no-brainer)
-Script settings (size, position, 'enabled', color) should be saved for each skin.  One way to achieve this would be to put a text file in each skin's folder, containing the settings.
-There should be a 'configure skin script' script that lets you move the display around, among other things.  (e.g. Position an analog clock wherever you want on the skin).  Each skin script should have its own configuration script.  (Action/Skin Scripts/Configure)

The main idea here is that the user decides what skin scripts go where, as opposed to the skin maker.  

So the main question would be: Should skin scripts be in control of the skinner, or the user?  An idea here would be to let the skin creater put skinscript configuration files (as discussed above) into the skin folder when distributing it.  In this case there's the obvious question of how to ensure the user has those scripts installed.

Feel free to post your thoughts on this matter.  <

[BenJeremy]

Hmmm... I guess I'd consider a combination.

For the idea you have, we'd be talking about user-assignable elements, add-ins to existing skins.

Replacing or supplimenting a screensaver would be the obvious usage for this. Adding the clock or a newsfeed to the main menu screen would be another. The tricky part is, are the add-ins global, remaining even with skin changes, or only for the individual skin? Do we track the positioning and scaling on a per-skin basis? Each script would also have to have an "adjustments" or Configuration phase, so the user could make changes to the add-ins config.

 <

[koldfuzion]

QUOTE

Should skin scripts be in control of the skinner, or the user?

i think both.

Not all scripts will require user-"placement".   The clock position is a great example of letting a user specify the script settings.   But at the same time,  the author might want to use a script to put a menu in motion, provide some cool animated effect, provde menu "mouseover" effects, or to scroll some text that was only meant to be in one place in the skin (read as image cutout with overlay) that should not be messed with by the user.

maybe scripts included in the skin.xml file are HARD-SET.  while still enabling skin-plugins? which should allow for user movement, settings etc?



 <

[geniusalz]

QUOTE (BenJeremy @ Jun 19 2004, 07:47 AM)

The tricky part is, are the add-ins global, remaining even with skin changes, or only for the individual skin? Do we track the positioning and scaling on a per-skin basis? Each script would also have to have an "adjustments" or Configuration phase, so the user could make changes to the add-ins config.

Each skin can have a "Plugins" node, or a plugins.xml file, which looks something like this:

<Plugins>

<Plugin GUID="someguid">
<Enabled>True</Enabled>
<Setting1>100</Setting1>
<Settingetc>200</Settingetc>
</Plugin>

<Plugin GUID="otherguid">
<Enabled>False</Enabled>
</Plugin>

</Plugins>

This way, the user can specify which plugins show up for each skin, and where they go.  If no info is found for a plugin, it stays unactivated until the user 'enables' it through the plugin manager or something.  And if the skinner includes a plugins.xml file, the plugins specified (if present) can show up, and if not present, prompted for download or something.

Menu effect scripts can be 'hardcoded' into the skin like kf said.  But they will need a new set of AS commands to interact with the menu like that.

This post has been edited by geniusalz: Jun 19 2004, 01:10 PM <