Re: Windows port direction

[Sheldon Gill]

> David Lázaro Saz wrote:
> > Yesterday I promised to begin explaining what is that I would like  
> > GNUstep do on the Windows side.  That's what this message is about.

Hi David,

I've been doing a bit of work on the Windows side, too. Your focus, based on 
what you've said so far, is mostly GUI related. My focus at the moment has been 
on -base, getting that sorted first. That isn't to say that I've not been 
considering the GUI side. Rather, my feeling is my time and energy is best 
spent at the moment getting -base work done and moving on to GUI from there.

> > First, I'd like to be capable of doing development both on Windows  
> > and on Mac OS X.  That's because I'm usually on-the-go and the only  
> > thing I have at hand is my PowerBook.  I've got the latest Virtual PC  
> > version installed and running but it is very slow for full  
> > recompiles.  Thanks God for incremental compilation, though.
> >
> > During the last night I got the full MinGW toolchain working on Mac  
> > OS X.  Is there any reference for cross-compiling GNUstep to contrast  
> > what I am doing to see if I'm doing things right?  That way I can  
> > correct any bad behaviour that appears.  The only thing that I found  
> > was last July's responses from Nicola to this mailing list.

There is fragmented information on cross-compiling using the gcc toolchain 
generally. It would be useful for many to prepare better documentation on it 
all and definitely some benefit in packaging it. I'm sure there are a number of 
people who'd be interested in a MinGW development environment for OS X.

There has been some work on -make to support cross-compiling. Nicola is the 
expert on all that...

> > GNUstep's mission statement says that its goal is to create a free,  
> > superior development environment based on OpenStep and some of  
> > Cocoa's advances, taking into account the finer points of the display  
> > model while remaining somewhat look and feel agnostic.  I agree  
> > completely with these goals.  My intentions are only to try to define  
> > some clearer goals for the Windows port so I can work with it in a  
> > production environment.

Good. I've a tasklist of sorts for this so I'm sure we can plan it out.

> > Production quality apps for Windows are somewhat vaguely defined by  
> > the Microsoft logo guidelines.  The technical part of those  
> > guidelines are specified on the Windows Logo Program for Windows at  
> > <http://www.microsoft.com/winlogo/software/downloads.mspx> (sorry,  
> > some of them are Microsoft Office documents).  I think that a  
> > successful development environment should provide almost everything  
> > covered on those guidelines automatically.  Granted that could mean a  
> > long time of development but I think that, technically, GNUstep can  
> > cover those and even more.
>
> If it can one day, great, but I'd say it's better to focus in the short 
> term on the immediate correct functioning of GS under win32, don't you 
> agree?

Long term goals are good to have so we know the direction in which we're 
heading. We do, though, need short term goals and specific tasks which can be 
tackled to get movement.

> >  From the Designed for Windows XP spec v2.3, you can see that three  
> > areas are covered: Windows fundamentals, install/remove, and data and  
> > settings management.  I'll refer you to that spec for the details.

There are some issues with the spec in terms of good behaviour and the GNUstep 
system. Not all that important in the short term.

> > GNUstep still doesn't cover install/remove of specific applications  
> > but in the future I think that it should be.  Maybe a way to  
> > automatically generate installer packages (.msi) and merge modules of  
> > the core libraries for ease of deployment.  There's a lot to say  
> > about this but for I think that it should go to the back of the list.

With Nullsoft and other good packaging tools available this is not really an 
issue. I see it as a separate thing. There is a need to package for platforms 
and some of the work I've been doing on -base is specifically to enable this.

There are, though, a lot of details involved which are platform and 
distribution mechanism specific. Much to say for another time.

> Making MSIs are not difficult, but I think GNUstep on win32 should be a 
> bit more mature before we create them. MSIs are also important for 
> corporate deployment.

Packaging for Win32 is a big topic. There are other projects which make MSI and 
other installation packages. As long as GNUstep can build the executables, 
libraries and resources the actual packaging mechanism can be readily done 
using those other tools.

> > In relation with Windows fundamentals, what I need and think that  
> > GNUstep should cover is support for the Microsoft Windows User  
> > Experience guidelines and what is called _visual styles_ in the  
> > Windows world.  Let's begin with the following list:
> >
> > * Document the points where GNUstep doesn't respect the guidelines.   
> > Menus are, for example, currently in a NeXT-style panel while they  
> > should be on the top of each window.  The OpenStep API covers very  
> > well that case so it should not be difficult.
>
> Nope, there's already even a horizontal menubar hack  (which nets you OS 
> X style global menus) and someone hacked that even further to do 
> per-window menus, if I remember properly. So it's possible.

It is possible and work has progressed in implementing it.

> > Adding support for system colours is another point.  I think that a  
> > complete list should be maintained somewhere.
>
> It is, in the Windows Registry. Don't ask me where, I will have to look, 
> and I will write a follow-up mail with that info later. It's not critical.

Actually, all that is needed here is to properly map the GNUstep color scheme 
to Win32 colors. GetSysColor() and SystemParametersInfo() are relevant API 
calls and should be used rather than direct registry reads.

I've actually already got code for this...

> > The "classic" Windows theme is also specified in the user experience  
> > book.  That is nice and should make it an easy and achievable first  
> > target.

Agreed. The other advantage of "classic" is backwards compatibility.

> I have had some discussions with Nicolas Roard (author of Camaelon, a 
> GNUstep theming engine) about the possibility of making Camaelon support 
> the Windows Theme format (the themes themselves live in 
> %SYSTEMROOT%\resources\Themes) and actually use the information they 
> contain to draw the UI. The reason for doing it this way is it is less a 
> violation of the Steppish Way, where controls draw themselves). 

I agree that the native win32 controls shouldn't be used. There is scope for a 
separate library to do that (or .Net bindings for the UI layer). Getting 
controls to draw themselves appropriately for the platform can be achieved in a 
number of ways. Don't forget the biggest violator of the UI standards is 
MS-Office...

> Extending Camaelon to use msstyle/mstheme files directly will of course 
> only work for Windows XP. If your target organization uses XP, I'd 
> dedicate your efforts there. Even in Win2K, although the uxtheme system 
> doesn't exist, having Camaelon whip up a native windows (non-luna, 
> non-third-party) theme from a native Windows msstyle file should be doable.

It'd need to be separate from uxtheme mechanisms and MS resources.

Themeing on *nix will provide all the needed systems. It'd be a case of 
developing a GS theme which is Win32-ish enough.

> > * The common dialog library should be used, too.  It should be easy  
> > to hook into that as the OpenStep API also was designed with that in  
> > mind, as with the menu system.

Blech, really. We can do better dialogs with our current panels. We should, 
though, make them look sufficiently win32 for user acceptance.

Again I point an accusing finger at MS-Office...

> > * Provide support for visual styles by dynamically hooking into the  
> > UxTheme API.  Or what is the same: make GNUstep aware of what version  
> > of Windows is it running on, and depending on that activate the  
> > visual styles-aware drawing code.  I know how to do that with the  
> > Win32 API, it should be straight to make GSDrawing use that.
>
> Camaelon is far more flexible. I hear parts of camaelon will be rolled 
> into GNUstep, but I'm not sure to what extent. Ask Nicolas. He's been 
> really busy lately.

As I said, theme support for GS will provide all that is needed. A 
library/bundle which maps UxTheme calls to GS is a relatively straight-forward 
task on top of that.

> > * In relation with GDI I think that its support should be finished.   
> > Make transparency work, for example.

Agreed.

> > After that, I think that a wrapper for GDI+ should be developed to  
> > control it using GNUstep's display model.  It should be as easy as  
> > hooking with GDI or even more because that API supports floating  
> > point coordinates, colour spaces and more.  The only problem is that  
> > it is C++, but it should be wrapped with a C interface similar to  
> > Quartz and the DPS operators.  If it is easier, maybe that should be  
> > supported first.  I don't know what would be better.
>
> I'm not so sure that this would be easy, worth it, or even 
> advisable...what are the advantages? I see none.

Well, firstly it is to be the native/preferred drawing mechanism on future 
windows releases.

Secondly, it provides the drawing primitives GS expects. (ie Postscript drawing 
rather than 2D lines/circles/rects/fills & blits)

Thirdly, you're going to see hardware accelerationfor GDI+ which will make it's 
performance outstrip GS on GDI unless GS starts developing it's own hardware 
acceleration.

> > * The defaults system in Windows should read and write to the defined  
> > locations for that.  Maybe GNUstep on Windows should support both.  I  
> > haven't made my mind on this point yet.
>
> When you say "the defined locations for that" I assume you mean to a key 
> in the registry, in HKEY_CURRENT_USER\Software\GNUstep or something?

To be spec compliant it needs to write it's preference data to
HK<CU/LM>\Software\<company>\<app>

so we'd need eg

HKCU\Software\GNU\Gorm\

Supporting this properly requires a different NSUserDefaults module. The amount 
of common code which factors out is small and leads to more confusion in my 
view than separate implementations.

> > There are a lot more things to cover but I think that this should be  
> > enough for the first day, or even week to discuss.  I also hope that  
> > it is clear that I'm not talking about removing anything, only about  
> > adding support for Windows conventions and novelties.
>
> Yep, it's fairly clear...you should also talk to Sheldon Gill, he's been 
> working on various win32 things such as path handlinc recently.

Yes, talk to me :->


Regards,
Sheldon