On 11/23/05, Frode <[EMAIL PROTECTED]> 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 _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
