gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AppKit (Win32) generals questions


From: Thierry DELHAISE
Subject: Re: AppKit (Win32) generals questions
Date: Fri, 9 May 2008 09:28:50 +0200

Hi Fred and others
 
Thx for your precisions : that help a lot !
 
I came back with my original question and will try to precise what I want to do, and how, I understood, I must do the job with gnustep to fit in the Framework.
 
I want to use the low level GetOpenFileName on Windows. This function take a big C structure to allow it to get all informations to configure the dialog box and the feature that will be display to user to allow him/her to choose a file name.
 
So in GNUstep way, I use NSOpenPanel, later the theme Framework detect that this is a NSOpenPanel and the theme Framework call the appropriate (and specifique win32) DisplayServer (win32) code whitch call the OS GetOpenFileName. Does it is the trick ?
 
The scheme should be the same for PrintDialog, Color dialog, Fonts dialog, etc....
 
 
Second question to all : where is the code for Theme Framework, does it is available in trunk,(gui ?) and how does it get called (I took a quick look yesterday at the NSWindow.m code and saw nothing about theme, but I m certainly wrong ...
 
Thx for your help and answer.
 
Thierry 

2008/5/9 Fred Kiefer <address@hidden>:
I agree, this is a great answer. Still before we put it into the FAQ we may need to extend it a bit.

There are of course two main interface classes between gui and back one of them is GSDisplayServer, the one that has been talked about and the other is NSGraphicsContext. The later does the actual drawing whereas the former manages windows and events. This separation is just great to have multiple graphics backends like art, xlib and cairo share the same x11 display server. (OK, there is room for improvement on this in our current implementation, but there always is)

We may also want to point out that there is already theming code out there, written by Chrstopher Armstrong, that does the drawing of controls with native Windows functionality. Perhaps later this year, when the new theming framework is in place it will be possible to make a clean release of that theme.

As for the drawing into a native window, there is the method initWithWindowRef: on NSWindow, which will create a GNUstep window from a native window reference. Allowing you to carefully create an NSView at the right place to draw into. This functionality requires a method on the display server that is currently not implemented on MS Window, but should be easy to add. (The only complex bit will be the GWL_USERDATA)



Gregory John Casamento wrote:
We should probably put this in the FAQ someplace since the question regarding using Win32 controls comes up relatively often.  
I've found it necessary to explain this to a number of people in the past.

----- Original Message ----
From: Richard Frith-Macdonald <address@hidden>
On 8 May 2008, at 15:04, Thierry DELHAISE wrote:
Gregory John Casamento a écrit :
Thierry,

GNUstep can be made to have a native win32 look through the use of  themes.

Great ! But ... this is not enought and this is my fault (sorry)  since  I've asked about look and should not have to. What I want is  that my Application be a Native win32 application using MS Windows  application recommendations : using of standards panel, alowing  interaction with clipboard, and Windows services (ODBC, COM, OLE) ,  Windows toolbar's, etc ...So what I want , is that GNUstep be a  layer between my application code and Win32.

That's roughly what GNUstep is supposed to be ... but it's a little  more complex than that

Currently there is no plan for using the standard panels.   This  would be a welcome change, since it would help GS blend into the OS  better.

Yes, I saw, and this is where I can may be contribute to the project  but with the directions/recommendations of some old steppers ;-)  (let call them gurus ! ;-) ).

After spending my morning time to dig into GNUstep implementation  I've some (certainly stupid) questions about  how  is  port  GNUstep  on Win32 :

So on Win32, the concept of  DisplayServer have been port ? What was  the functionnal need for this, I mean for Win32 ? It seems to me  (but may be I'm wrong) that the display server have the functionnal  job to draw all (GNUstep) windows inside an application. So,  DisplayServer is in charge of drawing low level window letting  gnustep gui drawing all controls with the look of GNUsetp since gui  don't use native control on win32 (?). It seems too that it have to  handle drag and drop operations and may be clipboard interaction ?  Why not have let this jobs to operating system ? Since on win32  windows could do the jobs ? (I know that win32 do mostly bad job ;-)  but this one, since it do it since so many years, we can hope it  will do it mostly correctly ;-), no ?

The GNUstep GUI code is divided into two library ... the gui proper  (gnustep-gui), which handles most of the work of implementing the  AppKit API, and the backend (gnustep-back) which handles the interface  to the native operating system.  The display server (GSDispalyServer)  is the class which provides the main interface between the two parts.  So code in gnustep-gui calls methods in the display server, and code  in gnustep-back translates them to native calls of the system you are  running on.

This means that application developers use the OpenStep/GNUstep/MacOS- X AppKit API to write their applications, and the gnustep-back library  uses the native functionality to do the job where possible.
For instance, you do cut and paste or DnD using the OpenStep API for  that, and the actual calls to perform the operations are the native  windows ones.  ie we do leave the job to the operating system.
Of course, where the two APIs (OpenStep and win32) operate in very  different ways, the conversion between the two is hard, but often the  layer between the two is quite thin.

One area where there is not much scope for overlap is drawing within a  window ... the way that the OpenStep API operates is so different that  high level code for drawing things inside a windows using the native  operating system generally cannot fit with OpenStep, so the gui  library does all the drawing inside the window with quite low level  code rather than trying to map OpenStep 'controls' to native 'widgets'.

In this area, does controls in the spirit of GNUstep have to be draw  by GNUstep or could those be the native one's ? This questions since  I pretty sure that developping a Win32 theme could spent a lot of  time to recreate the exact look and feel (and function) of an  allready existing control under the native platform. And I'm not  sure (but may be I'm wrong) that Mac's users, or *nix one's want to  have a win32 native look on their host platform ? I know that *Step  one's want to remember the good day's ... so I understand why there  is a need to draw controls or windows or menus with *Step look and  feel in mind ;-) (my Sun's OpenStep workstation died last  years ... ;-) )

Well, the amount of use of native controls can be quite variable.  The  basic design of the two libraries is, to draw OpenStep controls rather  than try to map to native controls, because that's generally easier.  However, a theme engine is free to try to draw parts of a window using  the native controls where that's a practical solution.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]