discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gnustep gui and win32 visual styles (theme)


From: Nicolas Roard
Subject: Re: Gnustep gui and win32 visual styles (theme)
Date: Wed, 23 Nov 2005 22:14:34 +0000

On 11/23/05, Frode <frode@bredband.net> wrote:
> Hi!
>
> Nicola Pero wrote:
> > Everyone would be interested in having a more native look&feel for
> GNUstep on Windows.
> I feel the plans of gui control drawing is like reinventing the wheel.
> But maybe my intuition is wrong.:-)

Well :-)

> In short, what is the status of the back-end and what more is planned to
> be added? Should the menu-handling go into the back-end?
>
> Is the goal to make gui-sources (core/gui/Source/*.m) essential non-OS
> dependent and put the OS-depending code in the backend
> (core/back/Source/<os>/*.m)? Will this create performance degradations
> for the final product?
>
> I'm quite new to GNUstep coding so don't expect I have all answer, just
> questions. :-)

Basically, you have two options to have an "integrated" UI for the look. One
is to handle yourself the drawing and mimicking the host platform. The other
is to use the host platform widget. The problem is, this second option is
not really an option for GNUstep -- host widgets won't fit into the
AppKit model,
you'll have incompatibilities, etc. NeXT at the time of OPENSTEP/Windows
didn't use Win32 widgets, they used theirs, but with a "theme" similar to win32.
Qt works the same. Afaik, the only toolkits that does not work like that are
WxWidgets and Java AWT/SWT, and they have many problems to
keep everything consistent between each platform.

So, while handling yourself the drawing and not using host widgets
directly isn't
perfect, it's the best option you have, else you won't have good compatibility.
I think that's the best approach for GNUstep.

Now, if you can change the "theme" (the look) of the GNUstep widgets, you can
do it in two different ways: with some kind of pixmap theme, or by
using the host
platform theme api (if one is available). This second approach is better than a
pixmap theme (as you'll keep track of the current theme) and as close
as possible as using "real" widgets.

Good news: there is a theme engine for GNUstep (a pixmap theme engine). It is
currently beeing integrated into GNUstep (that is, the part that
modify AppKit to have
proper theming, not the pixmap theme engine itself).

So when it's done, you can either 1) use the pixmap theme engine to
create a "windows theme" using pixmaps -- easy and quick, but as
explained, not perfect -- you can even already start, just grab
Camaelon and create a theme ! 2) create your own theme engine using
the extended GSDrawFunctions api, that will use the Windows theme api
for the drawing -- ideal.

After that steps, you'll have a GNUstep AppKit that will _look_ the
same as Win32. But then you'll have some behaviors that will be
missing or different. Luckily, you don't need to reinvent the wheel
here (..or..not entirely), you just need to provide a gui bundle that
implement what you want. For instance, Menu "in windows" could be
implemented in two steps:
- create an horizontal menu (see the WildMenu gui bundle for such a feat)
- integrate that horizontal menu in the windows, possibly using the
existing hooks used by NSToolbar

I'm more versed about the _look_ than about the behavior though, and
there's certainly a lot of other things that would need a
modification. Still, it will be much better to participate in GNUstep,
because whatever modification that is needed should be included, as
the hability for GNUstep to "blend in" Windows will very likely
necessitate the same steps and hooks that the hability of blending in
KDE or GNOME, so working to have a proper GNUstep integration on
Windows will in fact be good for everybody.

Cheers,

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
  -Arthur C. Clarke




reply via email to

[Prev in Thread] Current Thread [Next in Thread]