Windows port direction

[David Lázaro Saz]

Hi there,

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.

What I would like it to be?  The quick answer would be everything to  
everybody!  But as agreeable as that would be, it won't be a very  
clear goal. So let's begin defining those goals and explain the  
current situation as I see it.


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.

That's enough of what I'm doing right now.  Let's continue with the  
bigger picture.


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.


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.

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.

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.

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.

Adding support for system colours is another point.  I think that a  
complete list should be maintained somewhere.

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.

* 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.

* 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.

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

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.

* 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.

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.

Cheers,

David.