olpc boot splash

[Ray Strode]

Hi,
>>>> We do want to make sure that the plugins are generally useful though.
>>>> I guess what I'm saying is, I think we want plugins upstream that
>>>> aren't very distro specific.
>>>
>>> If that's the case you need to have published docs how to build
>>> packages that can link against the core plymouth to make it easy to
>>> build against.
>> Note I'm not saying that the OLPC plugin should be built out of
>> tree--quite the opposite.  The point of the mail was to discuss ways
>> to intergrate it.
>
> Ah, OK, sorry I got the wrong end of the stick then.
Since we talked last I started a branch here:

http://cgit.freedesktop.org/plymouth/log/?h=plugin-rework

that changes how plugins are done a bit.  The idea is to work around
some of the problems I mentioned before.

Now, every splash is composed of two parts: the plugin (the engine)
and the "theme"

The theme is a little config file that says,

1) What plugin the theme is supposed to load
2) plugin-dependent key-value pairs to modify how the plugin runs

With this change I think you'll be able to use the "glow" plugin
(which has been renamed to "two-step") by shipping a theme file for
olpc that looks something like this:

[Plymouth Theme]
Name=OLPC
Description=The default OLPC boot splash
ModuleName=two-step

[two-step]
ImageDir=/usr/share/plymouth/themes/olpc
horizontal_alignment=0.5
vertical_alignment=0.5

in

/usr/share/plymouth/themes/olpc/olpc.plymouth

and then in /usr/share/plymouth/themes/olpc you would just drop the
various frames of the animations.  See the glow theme for an example.

We may need to modify two-step a bit to show the "powered by" badge in
the corner.

If two-step doesn't end up being good enough, we can import the olpc
splash charlie did as it's own engine and give it a theme by default
that's debranded (maybe a "clock" theme?)

>>>> The way we get around the distro-specific problem currently is we have
>>>> configure options  --with-logo , --with-background-color etc.  By
>>>> default these values are a made up "bizcom" logo and a gray color, but
>>>> Fedora, for instance, sets the logo to the fedora logo and the
>>>> background to blue.  Plugins source these values to figure out what to
>>>> show.  This way the "fade-in" plugin shows bizcom fading in and out by
>>>> default, but on Fedora it shows the fedora logo fading in and out
>>>> (likewise for the other plugins).
>>>
>>> How would that work for things like Fedora remixes where there would
>>> well be two logos like in the olpc demo (although the remix logo might
>>> not be used as it might not be Fedora).
>>
>> So what I was saying is we already have --with-logo.  This gets turned into
>>
>> PLYMOUTH_LOGO_FILE
>>
>> which can be referenced in the code.  We can add --with-small-logo, or
>> --with-emblem or whatever, too.
>
> OK. So where the fedora remix logo currently is we replace with
> --with-logo so that debian/gentoo/ubuntu or whoever wishes to use it
> can substitute appropriate logo?
well --with-small-logo, or --with-emblem.  I guess the --with-logo
would be reserved for the olpc logo.

> Cool. So we have a default colour if a specific colour isn't defined
> by the distro in compile or env vars?
Well it will be defined always.  if a distro doesn't pick colors we
use gray.  The question is if your splash should listen to the colors
or ignore them.

If you're splash is designed to be run on a white background and won't
look good any other way, then it should ignore them.  If you're splash
is designed to adapt to the distro it's running on it should use those
colors.

Logos on the other hand, splashes need to always be adaptable for.
Logos are often trademarked and have tight distribution rules (for
instance, the fedora logo can only ship in one package in fedora
called fedora-logos for legal reasons).  I imagine the OLPC logo has
similar issues, and other distros as well.

--Ray