« Return to Thread: NSView drawing in tool

Re: NSView drawing in tool

by David Chisnall :: Rate this Message:

Reply to Author | View in Thread

On 24 Jun 2009, at 11:03, Andreas Höschler wrote:

> This sounds more like additions of the kind
>
> if self is a tool than do that
> otherwise connect to back (art) and do something else
>
> to gui than another backend to me!?

As I said in my other email, this is not the correct question.  Tools  
are able to interact with the GUI.  There is nothing stopping a tool  
creating an NSApplication instance, NSWindows, and so on.  The problem  
you are facing is using gui functionality without a GUI available.

Note that you still need either libart or cairo to do drawing  
irrespective of whether you are outputting the result to the screen;  
something still needs to handle the rasterisation.

Did you try, as I suggested, creating a new graphics context backed by  
an image and drawing into that, rather than using an NSView?  NSView  
and NSWindow objects can be expected to manage some window server  
resources (whether the window server is X11, GDI, DirectFB, DPS or  
Quartz) and so will not be available when these resources are not  
available.

If you can not create a graphics context backed by a bitmap image  
representation without a display server available then it is a bug.  
If you can not create display server resources without a display  
server available then it is expected - and desired - behaviour.  
Having programs that try to create windows 'work' but not display  
anything when they can't find the display server would violate the  
principle of least surprise.

David

_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

 « Return to Thread: NSView drawing in tool