Re: Gnustep gui and win32 visual styles (theme)

[Gregory John Casamento]

Micheal,

--- Michael Hanni <mhanni@yahoo.com> wrote:

> Folks,
> 
> --- Nicolas Roard <nicolas.roard@gmail.com> wrote:
> 
> > 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.
> 
> Follow GTK-WIMP here... They extended the GTK+ pixmap theme to use the
> Windows
> drawing functions to draw the relevant pixmaps on the fly. (I believe there
> is
> a gtk+ theme that does this with QT as well.) It looks quite close to the
> real
> thing.
> 
> The one problem here, as others have mentioned with GTK-WIMP, is that the
> resulting app looks like Windows but a lot of the feel is wrong -- i.e.
> button
> order is wrong, buttons are too big, too small. I think this is where we have
> a
> big hand up with Gorm. You simply load up the gorm file you created on Linux
> in
> windows with Gorm + WinTheme and modify the gorm file to fit the windows HIG.
> NeXT knew this back in the day and provided a MyApp-windows.nib (or something
> along those lines) with new apps.
> 
> Hell, you could have a MyApp-pda.gorm and a MyApp-gnome.gorm (that uses the
> GNOME HIG), whatever. Gorm is cool like that.

It might be nice to consider having a way to load different nibs based on which
environment automatically.  This way, the app could have a number of different
.gorm files conforming to different HIGs and when the user starts that app on
Windows, it uses the windows .gorm file IF it's available.  If it's not
available it falls back to the default one.

Something to think about.

> > 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
> 
> Aie, this is really not hard. Take WildMenus, sprinkle in some updates and
> some
> love, and you can have a horizontal menu in a window. Take a look at
> http://u.cc.utah.edu/~msh3/xmas_surprise.png for what I had working last year
> after a day of hacking. The biggest issue is this: how do you determine which
> windows get a menu bar in them?
> 
> If someone wants to pick up the WildMenus code, clean it, love it, and make
> this happen I'd be happy to provide input along the way.

I believe that, like Camealon, WildMenus is something that GNUstep should
consider adding to gui.   This way, it's possible to build support into Gorm
and other parts of GNUstep for it directly.   For me, the only blocker for
putting support for WildMenus into Gorm is because it doesn't come with
GNUstep.  If it did, that would change the whole story. :)

> > 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.
> 
> Couldn't agree more...

I agree as well..
 
> Michael

Later, GJC

Gregory John Casamento 
-- Principal Consultant, Open Logic Corp. (A MD Corp.)
## Maintainer of Gorm (IB Equiv.) for GNUstep.