Re: NSView drawing in tool

> 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