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 <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]> >> 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. >> >>
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
