Send plymouth mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freedesktop.org/mailman/listinfo/plymouth
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of plymouth digest..."
Today's Topics:
1. Scripted plugins (Charlie Brej)
2. Re: Scripted plugins (Charlie Brej)
3. Re: Scripted plugins (Ray Strode)
----------------------------------------------------------------------
Message: 1
Date: Wed, 06 May 2009 23:41:35 +0100
From: Charlie Brej <[email protected]>
Subject: Scripted plugins
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Just to keep everyone updated. I was meaning, over the new year, to create a
scripting language to allow elements of the theme to be described. I got
distracted half way though but just got back to it. I have currently got it to
execute expressions so we can set the plugin variables (like the ones Ray
allows
to be set using the .plymouth files) to values which are not constant.
e.g.
HorizontalPosition = ScreenWidth / 4 - 100;
VerticalPosition = ScreenHeight / 2 - 50;
What you do is to populate the variable pool with data like ScreenWidth, and
then execute the script. It then sets some additional variables (if it does not
set them they are unset and a default value is used).
I should have something to that effect by tomorrow afternoon, but ultimately
what I was hoping to do is to allow the script to specify the images (dealing
with strings), their placement, their movement/transformations etc.
Thanks to the separation of themes and plugins what I was hoping to make is a
single plugin called something like "scriptable" and have multiple themes which
define their custom behaviours.
I was hoping to allow a description like this:
//CapitalisedNames are system supplied
image = ImageNew("bubble.png");
sprite = SpriteNew();
sprite.original_image = image; // the sprite object has some predefined
sprite.rot_distance = 100; // important fields like x,y,image
// anything else can be set and is preserved
if (ScreenWidth > ScreenHeight)
{ // ScreenWidth and ScreenHeight are system set values
sprite.rot_distance = ScreenHeight / 2 - ImageHeight(image)
}
else
{
sprite.rot_distance = (ScreenWidth / 2 - ImageWidth(image)
}
refreshfunc = function (sprite)
{
theta = Progress * 2 * 3.1415; // theta is a local and will be destroyed
// when the function ends
sprite.x = ScreenWidth / 2 - ImageWidth(image) + Cos(theta) *
sprite.rot_dist;
sprite.y = ScreenHeight/ 2 - ImageHeight(image)+ Sin(theta) *
sprite.rot_dist;
sprite.image = ImageRotate(sprite.original_image, theta);
} // The old sprite.image will be freed is the
// refcount reaches zero
refreshfunc(sprite); // call now to initialise the values
sprite.refresh_function = refreshfunc; // tell the system to call this function
// every frame
------------------------------
Message: 2
Date: Thu, 07 May 2009 14:58:50 +0100
From: Charlie Brej <[email protected]>
Subject: Re: Scripted plugins
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Charlie Brej wrote:
> Just to keep everyone updated. I was meaning, over the new year, to create a
> scripting language to allow elements of the theme to be described. I got
> distracted half way though but just got back to it. I have currently got it
> to
> execute expressions so we can set the plugin variables (like the ones Ray
> allows
> to be set using the .plymouth files) to values which are not constant.
So far I have managed to get integer operations working with +=*/% operators
and
"if" and "while" constructs. I'm working outside of the tree as it is much
easier to test this way. If anyone wants to have a look then here is my current
status. Obviously this is work in progress code so is incredibly messy and all
over the place with no naming scheme. You may need to edit the Makefile to
point
to the plymouth include dir etc.
http://www.cs.man.ac.uk/~brejc8/temp/plymouth_script.tar.gz
I still need to do strings, floats, functions, a method of wrapping C functions
and storing links to C objects.
------------------------------
Message: 3
Date: Thu, 7 May 2009 13:47:40 -0400
From: Ray Strode <[email protected]>
Subject: Re: Scripted plugins
To: Charlie Brej <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
On Wed, May 6, 2009 at 6:41 PM, Charlie Brej <[email protected]> wrote:
> Just to keep everyone updated. I was meaning, over the new year, to create a
> scripting language to allow elements of the theme to be described. I got
> distracted half way though but just got back to it. I have currently got it to
> execute expressions so we can set the plugin variables (like the ones Ray
> allows
> to be set using the .plymouth files) to values which are not constant.
...
> I should have something to that effect by tomorrow afternoon, but ultimately
> what I was hoping to do is to allow the script to specify the images (dealing
> with strings), their placement, their movement/transformations etc.
It's an interesting idea for sure.
So I guess the point is to make writing splash themes easier?
> Thanks to the separation of themes and plugins what I was hoping to make is a
> single plugin called something like "scriptable" and have multiple themes
> which
> define their custom behaviours.
Right, makes sense. Especially initially. You could make a theme like:
[Plymouth Theme]
Name=Flashy Theme
Description=A flashy theme
ModuleName=scriptable
[scriptable]
ScriptFile=/usr/share/themes/plymouth/flashy/flashy.scriptable
The idea, in general, seems like a cool one. One thing I like about
it is it lets theme writers create their themes without being
proficient in C.
I'm a little worried about the extra complication caused by plymouth
growing its own one-off scripting language. If you do this, I guess
I'd recommend you keep it very simple.
I guess at the end of the day the thing that matters most is the end
product (for whatever product plymouth is being deployed to). The
pluggable splashes are really just an implementation detail to make it
easier to create those end products. Making splashes should be easy,
but the code around the splashes should be small, too. We don't want
the initrd to get too big, and we don't want plymouth to be hard to
debug.
This is definitely an interesting experiment, though. I'd really like
to see how it turns out. Are you planning on working on a branch
eventually? Or are you going to keep this out of tree until it's
ready to be merged?
--Ray
------------------------------
_______________________________________________
plymouth mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/plymouth
End of plymouth Digest, Vol 8, Issue 5
**************************************
