Re: [Fresco-devel] DesktopKit, WidgetKit and theming stuff

Micah Dowty <[email protected]>
Newsgroups gmane.comp.video.fresco.devel
Message-ID <[email protected]>
On Sun, Jan 05, 2003 at 01:55:28PM +0100, Pier Luigi Fiorini wrote:
...
> Another think I am working on is a theming system.
> I like very much XML and attached there's a draft implementation.
> scanline on IRC have another idea but I'm sure he will answer this 
> message so we will be able to think to the better implementation as we 
> can do.
> 
> I hope you have understood what I have wrote :)

And here I am, scanline, a.k.a. "that guy that won't shut up about PicoGUI" :)

PicoGUI's theme system has been around for a while now and recieved a lot of testing.
As a whole, it's turned out to be an awesome system compared to what else is available,
but there's still room for improvement. I don't expect fresco to use picogui's theme system
of course, but there are a lot of ideas that can be borrowed if they're good.

The main concepts behind picogui's theme system:

  - You have a single theme format that's used by all widgets, other GUI elements
    like the cursor, and by applications. (Note that in picogui-land, window borders
    and the desktop background are widgets)

  - That theme format is self-contained and platform independent

  - Themes can define an arbitrarily large or small section of the GUI appearance

  - You can stack themes at runtime, so for instance you can have one theme define
    the widgets' look, one for the background, one for the cursor, another to
    modify the font sizes or colors...

  - Themes are fundamentally an object oriented database, where the values stored may
    be any object the PicoGUI server can represent internally, including code fragments
    in a very simple scripting language.

  - Applications and the core of picogui make no assumptions about screen size or
    organization, that's all up to the theme.

You can look at the screenshots on http://picogui.org for some visual indication of what the
format can do. Since there are no assumptions about pixel size or format in the picogui
server, themes can be used to run the same applications on a desktop monitor, tiny handheld LCD,
wallclock, etc :)
I'm sure fresco will need similar ways to make things look good both onscreen and in print.

There's a more detailed explanation of how it's all implemented on the wiki at picogui.org,
but at the time I'm writing this mail it seems to be down :-/

Anyway, some ways we've been thinking about improving it:

  - There's already part of a spec for 'tags' in the theme format that would be ignored
    by the server. Simple, but if all themes were tagged with a thumbnail and some descriptions,
    you could write a very sweet UI for browsing and loading themes. Since absolutely everything
    visual in picogui can be specified by themes, this would give the user a single place
    to change everything from their wallpaper, to their widgets' appearances, to the set of chess
    pieces used in board games.

  - Extending the above idea, we could include widget templates (sort of like libglade, but
    more efficient) into the theme tags, and allow the user to modify theme properties. This
    could be used to make meta-themes that let the user set any background from a file, or
    adjust colors and translucencies.

  - The small interpreter in the theme language is indeed small, but for more flexibility we've
    been thinking about making an optional python-based theme language. It would have the same
    object-oriented structure and consistency as the current format, but could store any object
    python can represent, including python code. Since themes can read widget properties, this
    would allow as much flexibility as using compiled code for themes, but with easy scripting,
    portability, and the ability to stack themes at runtime.

--Micah


-- 
Only you can prevent creeping featurism!
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.