On Tuesday 19 February 2008, Niall Douglas wrote:
> On 19 Feb 2008 at 18:57, Michael wrote:
>
> > I have not attached anything yet. I just wanted to know if anybody has
> > already worked on theming before - to be sure not to reinvent the wheel :-)
> > So I will try to code a simple demo just to start with something we can
> > discuss. As far as the look and feel is concerned I think the look should
> > be the first part just because its easy to implement and its the first thing
> > users get confronted with. The feel which is IMHO much more work should be
> > done after the look is fully implemented.
> >
> > I think the reason why Jeroen is not working on it, is just simple the fact
> > that his customers do not need it. I think we have to respect this.
> > Nevertheless he gave us a great toolkit to work with, and I understand that
> > if I want themeing support I have to code it on my own.
>
> No Jeroen hasn't done it yet because it's nothing like as
> straightforward as it looks.
Indeed. The challenge is to introduce theming in such a way that the following
goals are met:
1) Since the toolkit is extensible, the theme stuff must be
extensible too. In particular, if we have a custom control
"MyWidget" derived from some "StandardWidget", then we would
like to have the corresponding MyWidgetTheme also share the
info with "StandardWidgetTheme". This seems to call for a
parallel class hierarchy in some way.
2) We don't want to lose the "Lean and mean" for those people that
don't care about themes. Themes may involve arbitarily complex
drawing code, and what runs zippy on a modern PC may be totally
unworkable on someone's legacy hardware. What I'm trying to say
is, some people would rather spend their CPU cycles on application
code rather than waste them on theme drawing.
3) We also need to work in the current per-widget customizability
with the theme stuff. If one currently has a single red button
in the GUI, we don't want to have to allocate a whole separate
theme-set just so we can have one button be red. So to some
extent, a theme is also parameterized by some per-widget
attributes.
> ...
> You might /think/ it's just a matter of redirecting to OS-provided
> drawing commands. And to some extent, yes it is - except, also, no it
> isn't. WxWindows tried that approach and have tried dumping it last
> few years because it's highly unreliable and fundamentally breaks
> cross-platform portability because your code won't behave the same
> way on all platforms. You really, really don't want that, ask any old
> school wxWindows user.
> ...
What Niall is trying to say here is that FOX does its own drawing, i.e.
it does not wrap some other toolkit or API. Which means if you want to
reproduce e.g. the Platinum or BeOS look, then you'd have to code these
up with your own implementation. To be portable, this needs to be done
within the capabilities of FXDCWindow.
> FOX could go the other way, which is that it has one theme called
> "FOX" and that theme is identical on all platforms. I chose that
> route, it's not like the users aren't pretty familiar with it even if
> it looks really out of place - my BIG problem is lack of native (non-
> X11) Apple support. But then XP progs look and act out of place on
> Vista!
> ...
> Jeroen has hinted he has been thinking of using OpenGL as the 2D
> renderer and hence the v1.7 upgrade of the OpenGL support. I
> personally think that's also an excellent solution, though printing
> it may be a little tricky.
I don't think OpenGL for 2D is liable to be very successful. Not that
it can't be done, but its simply not that easy to do this on the application-
level.
As opposed to, say, writing your own display-manager/X11/GDI server type
thing that can manage overlapping windows of multiple applications.
In other words, we're relying on lots of functionality in the underlying
system. We can't realistically do without that...
--
The most likely way it will be done in FOX is through some sort of parallel
class hierarchy. When we're talking themes, what we're really doing is
separating the look (theme) from the feel (widget). That means changing
themes will only change the look, and not the feel. To have a different
feel is outside of the scope of what we want to do with themes. If you
want a new feel, you need to implement a new custom control.
Besides the issues mentioned above, we also have issues with security and
reliability. If you go through plug-in route, you're essentially letting
some 3rd party library, written by god-knows-who, play inside your application.
Maybe its not a problem for a CD Player, but it is a problem for commercial
software where support calls cost you money. So we probably want to do
themes three different ways:
1) Built-in, hardwired theme for those who don't care about it or
those who run on less capable hardware.
2) Themes hardwired into application by application vendor.
3) Parametric themes where looks are defined in terms of some sort
of data file(s). We may be able to load images and draw gradients,
but we won't execute code from unknown 3rd parties.
The above three methods are appropriate for commercial applications
or applications which need to meet certain security requirements.
4) Plug-in themes where we load a shared library to install theme
drawing code. Code is obviously more flexible than the parametric
method, but the downside is it may be a bit more difficult to write.
The last method is the most flexible, but if I were shipping commercial
software I wouldn't allow it since I might be getting support calls for
code written by others not under my control.
Nevertheless, I realize the "cottage industry" that would be enabled
by this capability, and certainly, not all applications are so mission
critical that we need to be paranoid....
OK, so these are a few of my thoughts on themes. As usual, the devil is in
the details....
Cheers,
- Jeroen
|