gnustep-dev
[Top][All Lists]
Advanced

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

Re: [Gnu3dkit-dev] GSXView


From: Philippe C . D . Robert
Subject: Re: [Gnu3dkit-dev] GSXView
Date: Tue, 22 Oct 2002 23:41:52 +0200

Hi,

On Tuesday, October 22, 2002, at 08:46  Uhr, Frederic De Jaeger wrote:
Hi lists,

I would like to start a discussion on the design of a new class we
really have to implement.  I call it GSXView.  I is a backend specific
class that inherits from NSView.  The idea is that this class has its
own X subwindow to draw on.

Why do we need such a class?

+  to make applications that are frontends for other applications, like
gv is a frontend of ghostscript.
+  to implement NSOpenGLView (that is what I'm interested in).  It
should be very easy, just attach a GL context to the sub X window,
using glX (I suppose it is the way it is done in gtkglarea)

It would be very nice to have the NSOpenGL* classes in GNUstep, indeed! We should maybe even add dummy classes to GNUstep so that compiling/linking of Cocoa code which makes use of it is at least possible.

There are several issues that need to be discussed:

+ First, such a view may not be rotated (maybe scaled, flipped?).

In the case of a NSOpenGLView, I guess this would be fine.

+ What can we do with X events related to the sub-window.  We can
ignore them and let the ancestor manage them.  (But we could optimize
the dispach of such event)

+ What happens if we add subviews to such a view ?  Probably, we
should not permit this (Anyone sees a good reason to allow this ?).

+ Shall we allow PSoperator in such view ?  Probably not.  In fact
drawing is such views does not concern the gui or the backend.

One more thing wrt OGL: what if there is no OGL installed? How should GNUstep handle this situation then?

I started thinking of the design.  It may not be difficult to
implement.  What I have in mind is simply create the X window when the
view receives viewWillMoveToWindow: foo
where foo is non-nil.
We have to check the focusView mechanism, maybe disable displayRect:
and friends.
We have to trap setFrame and friends, to instruct X to effectively
move the X subwindow.

What are your opinions ?
Is there already someone working on this subject?

You might want to contact Lyndon Tremblay <address@hidden>, he just told me that he is about to start working on this subject as well.

-Phil
--
Philippe C.D. Robert
http://www.nice.ch/~phip





reply via email to

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