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
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
