[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Windows port direction
From: |
Sheldon Gill |
Subject: |
Re: Windows port direction |
Date: |
Sat, 21 May 2005 20:32:25 +0800 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
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