Re: Windows port direction

[Alex Perez]

David Lázaro Saz wrote:
> 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.

Quick turn-around. It's very nice to see someone who has a commercial 
need for the GNUstep-win32 stuff to work properly. We've been in need of 
exactly someone like you for quite some time now.

> 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.
Sounds good.
> 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.

I'm not sure there's much info on cross-compiling GNUstep...good luck 
though...it may require some improvements to GNUstep-make.

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

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

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

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

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

When you say common dialog, do you mean the 2K/XP-style open/save 
panels? Or more broadly?

> * 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.
> * In relation with GDI I think that its support should be finished.   
> Make transparency work, for example.

AFAIK, it does, now. Someone fixed it recently.
> 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.
> * 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?
> 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.
> Cheers,
>
> David.