NSView drawing in tool

[Andreas Höschler]

Hi all,

I have a tool (service) that is supposed to generate PNG images using
NSView drawRect and

       NSBitmapImageRep *rep = [[NSBitmapImageRep alloc]
initWithFocusedViewRect:[mapView bounds]];

When running this tool and calling the above method (NSView, NSImage
stuff,...) I get

GSFontInfo.m:71  Assertion failed in GSFontEnumerator(class), method
sharedEnumerator.  Called with fontEnumeratorClass unset. The shared
NSApplication instance must be created before methods that need the
backend may be called.

OK, I modified my main.m to call

       [NSApplication sharedApplication];

before starting the event loop with [[NSRunLoop currentRunLoop] run],
but this gives me

        /opt/GNUstep/Local/Tools/OSMMapServer: Uncaught exception
WindowServerCommunication, reason: Unable to connect to X Server `'

What am i missing?

Thanks a lot!

Regards,

   Andreas



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

[Andreas Höschler]

Hi all,

> I have a tool (service) that is supposed to generate PNG images using
> NSView drawRect and
>
>       NSBitmapImageRep *rep = [[NSBitmapImageRep alloc]
> initWithFocusedViewRect:[mapView bounds]];
>
> When running this tool and calling the above method (NSView, NSImage
> stuff,...) I get
>
> GSFontInfo.m:71  Assertion failed in GSFontEnumerator(class), method
> sharedEnumerator.  Called with fontEnumeratorClass unset. The shared
> NSApplication instance must be created before methods that need the
> backend may be called.
>
> OK, I modified my main.m to call
>
>       [NSApplication sharedApplication];
>
> before starting the event loop with [[NSRunLoop currentRunLoop] run],
> but this gives me
>
> /opt/GNUstep/Local/Tools/OSMMapServer: Uncaught exception
> WindowServerCommunication, reason: Unable to connect to X Server `'
>
> What am i missing?

I tried to run my  OSMMapServer. There I get

2009-06-22 23:58:50.268 OSMMapServer[3122] *** Assertion failure in
-[MapView lockFocus], AppKit.subproj/NSView.m:2343
lockFocus sent to a view whose window is deferred and does not yet have
a corresponding platform window

It seems I am on the wrong track with my approach!? Is there any
example of a GNUstep tool that generates PNGs or TIFFs from a NSView
after drawing NSBezierPaths?
How is this done correctly? Hints are greatly appreciated!

Thanks a lot!

   - Andreas



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

[Fred Kiefer]

Andreas Höschler wrote:

> Hi all,
>
>> I have a tool (service) that is supposed to generate PNG images using
>> NSView drawRect and
>>
>>       NSBitmapImageRep *rep = [[NSBitmapImageRep alloc]
>> initWithFocusedViewRect:[mapView bounds]];
>>
>> When running this tool and calling the above method (NSView, NSImage
>> stuff,...) I get
>>
>> GSFontInfo.m:71  Assertion failed in GSFontEnumerator(class), method
>> sharedEnumerator.  Called with fontEnumeratorClass unset. The shared
>> NSApplication instance must be created before methods that need the
>> backend may be called.
>>
>> OK, I modified my main.m to call
>>
>>       [NSApplication sharedApplication];
>>
>> before starting the event loop with [[NSRunLoop currentRunLoop] run],
>> but this gives me
>>
>>     /opt/GNUstep/Local/Tools/OSMMapServer: Uncaught exception
>> WindowServerCommunication, reason: Unable to connect to X Server `'
>>
>> What am i missing?
>
> I tried to run my  OSMMapServer. There I get
>
> 2009-06-22 23:58:50.268 OSMMapServer[3122] *** Assertion failure in
> -[MapView lockFocus], AppKit.subproj/NSView.m:2343
> lockFocus sent to a view whose window is deferred and does not yet have
> a corresponding platform window
>
> It seems I am on the wrong track with my approach!? Is there any example
> of a GNUstep tool that generates PNGs or TIFFs from a NSView after
> drawing NSBezierPaths?
> How is this done correctly? Hints are greatly appreciated!
>

Was this the result of running your code on MacOSX? You didn't say so,
but the error message clearly isn't from GNUstep.

Why do you insist on your code being a tool? Wouldn't an application be
a better fit?
On MacOSX you could try to work with an NSImage instead of an NSView.
You can just draw on that instead of drawing to the view. On GNUstep
this is currently not fully supported. Any help to improve that would be
highly appreciated

Fred


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

[Andreas Höschler]

Hi Fred,

>>> I have a tool (service) that is supposed to generate PNG images using
>>> NSView drawRect and
>>>
>>>       NSBitmapImageRep *rep = [[NSBitmapImageRep alloc]
>>> initWithFocusedViewRect:[mapView bounds]];
>>>
>>> When running this tool and calling the above method (NSView, NSImage
>>> stuff,...) I get
>>>
>>> GSFontInfo.m:71  Assertion failed in GSFontEnumerator(class), method
>>> sharedEnumerator.  Called with fontEnumeratorClass unset. The shared
>>> NSApplication instance must be created before methods that need the
>>> backend may be called.
>>>
>>> OK, I modified my main.m to call
>>>
>>>       [NSApplication sharedApplication];
>>>
>>> before starting the event loop with [[NSRunLoop currentRunLoop] run],
>>> but this gives me
>>>
>>>     /opt/GNUstep/Local/Tools/OSMMapServer: Uncaught exception
>>> WindowServerCommunication, reason: Unable to connect to X Server `'
>>>
>>> What am i missing?
>>
>> I tried to run my  OSMMapServer. There I get
>>
>> 2009-06-22 23:58:50.268 OSMMapServer[3122] *** Assertion failure in
>> -[MapView lockFocus], AppKit.subproj/NSView.m:2343
>> lockFocus sent to a view whose window is deferred and does not yet
>> have
>> a corresponding platform window
>>
>> It seems I am on the wrong track with my approach!? Is there any
>> example
>> of a GNUstep tool that generates PNGs or TIFFs from a NSView after
>> drawing NSBezierPaths?
>> How is this done correctly? Hints are greatly appreciated!
>>
>
> Was this the result of running your code on MacOSX? You didn't say so,
> but the error message clearly isn't from GNUstep.

No this last output was from my attempt on MacOSX and can be rather
ignored since I have to get this to run on GNUstep. On GNUstep I get

Abort (core dumped)Tools/OSMMapServer: Uncaught exception
WindowServerCommunication, reason: Unable to connect to X Server `'

> Why do you insist on your code being a tool? Wouldn't an application be
> a better fit?

No, definitely not. The tool is a service running in the background
(managed by cron), responding to XML requests from client apps. In this
special case the purpose of the service is to generate images (map
tiles) (PNG or TIPP) according to a given XML request. The service has
the logic to generate the images and the connection to the database
holding the data, not the client apps.

> On MacOSX you could try to work with an NSImage instead of an NSView.
> You can just draw on that instead of drawing to the view. On GNUstep
> this is currently not fully supported. Any help to improve that would
> be
> highly appreciated

I just realized that the tool works as expected on GNUstep when being
logged in on the console of the machine supposed to run the service.
However, in production this service is supposed to be started by cron
with noone being logged in!? Any idea how to get around the

Abort (core dumped)Tools/OSMMapServer: Uncaught exception
WindowServerCommunication, reason: Unable to connect to X Server `'

problem then?

Thanks a lot!

Regards,

     Andreas








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

[Andreas Höschler]

Hi all,

> I just realized that the tool works as expected on GNUstep when being
> logged in on the console of the machine supposed to run the service.
> However, in production this service is supposed to be started by cron
> with noone being logged in!? Any idea how to get around the
>
> Abort (core dumped)Tools/OSMMapServer: Uncaught exception
> WindowServerCommunication, reason: Unable to connect to X Server `'
>
> problem then?

I forgot to mention that one needs to generate a window around the view
to get this to work. My tool code basically looks as follows now:

       NSWindow *window = [[NSWindow alloc]
initWithContentRect:NSMakeRect(0,0, _imageSize.width,
_imageSize.height) styleMask:0 backing:NSBackingStoreNonretained
defer:NO];
       MapView *mapView = [[MapView alloc] initWithFrame:NSMakeRect(0,0,
_imageSize.width, _imageSize.height)];
       [window setContentView:mapView];
       ...
       // fetch data from the database and do some magic with
NSBezierPath in drawRect:
       ...
       [mapView display];
       [mapView lockFocus];
       NSBitmapImageRep *rep = [[NSBitmapImageRep alloc]
initWithFocusedViewRect:[mapView bounds]];
       NSData *data = [[[rep TIFFRepresentation] retain] autorelease];
       [mapView unlockFocus];
       [rep release];
       [mapView release];
       [window release];
       return data;

As reported in my last email this code works great on GNUstep as long
as I am looged in and have started the tool via Terminal.app. However,
starting the tool from a ssh session or via cron gives me

Abort (core dumped)Tools/OSMMapServer: Uncaught exception
WindowServerCommunication, reason: Unable to connect to X Server `'

! :-(

Hints still greatly appreciated!

Thanks,

   Andreas



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

[Fred Kiefer]

Andreas Höschler wrote:

> Hi all,
>
>> I just realized that the tool works as expected on GNUstep when being
>> logged in on the console of the machine supposed to run the service.
>> However, in production this service is supposed to be started by cron
>> with noone being logged in!? Any idea how to get around the
>>
>> Abort (core dumped)Tools/OSMMapServer: Uncaught exception
>> WindowServerCommunication, reason: Unable to connect to X Server `'
>>
>> problem then?
>
> I forgot to mention that one needs to generate a window around the view
> to get this to work. My tool code basically looks as follows now:
>
>       NSWindow *window = [[NSWindow alloc]
> initWithContentRect:NSMakeRect(0,0, _imageSize.width, _imageSize.height)
> styleMask:0 backing:NSBackingStoreNonretained defer:NO];
>       MapView *mapView = [[MapView alloc] initWithFrame:NSMakeRect(0,0,
> _imageSize.width, _imageSize.height)];
>       [window setContentView:mapView];
>       ...
>       // fetch data from the database and do some magic with
> NSBezierPath in drawRect:
>       ...
>       [mapView display];
>       [mapView lockFocus];
>       NSBitmapImageRep *rep = [[NSBitmapImageRep alloc]
> initWithFocusedViewRect:[mapView bounds]];
>       NSData *data = [[[rep TIFFRepresentation] retain] autorelease];
>       [mapView unlockFocus];
>       [rep release];
>       [mapView release];
>       [window release];
>       return data;
>
> As reported in my last email this code works great on GNUstep as long as
> I am looged in and have started the tool via Terminal.app. However,
> starting the tool from a ssh session or via cron gives me
>
> Abort (core dumped)Tools/OSMMapServer: Uncaught exception
> WindowServerCommunication, reason: Unable to connect to X Server `'
>
> ! :-(
>
> Hints still greatly appreciated!

Is there at all an X server running while the service is executing? In
that case "xhost +" might help. If there isn't any X server then you
will need a different GNUstep backend that is capable of initializing
itself and do the drawing without the help of X. We currently have
nothing in that direction, but theoretically it is possible to write
this sort of backend.



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

[Andreas Höschler]

Hi Fred,

> Is there at all an X server running while the service is executing? In
> that case "xhost +" might help.

If I log into the machine with ssh or start the tool via cron as root
then I get (as expected)

xhost +
xhost:  unable to open display ""

> If there isn't any X server then you
> will need a different GNUstep backend that is capable of initializing
> itself and do the drawing without the help of X. We currently have
> nothing in that direction, but theoretically it is possible to write
> this sort of backend.

This sort of backend would be very nice to have for the problem
described in earlier mails of this thread. I must admit that I need gui
for the first time in a tool. But for mapservers and the like that's
what is needed. It were really neat if GNUstep would support that. I
unfortunately don't have the expertise to write such a backend. :-(
Moreover this new backend should live well together with the normal art
backend on the same machine. When a user logs in on the console (or any
of the Thin Clients connected to the machine) and starts an app he
should get art backend, but when a tool is started within a ssh session
or by cron (with gui linked in) this tool should make use of the other
backend. 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!?

Regards,

   Andreas







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

[David Chisnall]

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

[Robert J. Slover]

On Jun 24, 2009, at 6:14 AM, David Chisnall wrote:

> 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

David has the best approach here, however, if you must do this with an  
NSWindow/NSView, you can look at using Xvfb (virtual X framebuffer) or  
starting an Xvnc session locked down to the local machine.

--Robert



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

[Fred Kiefer]

David Chisnall wrote:

> 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.

Hi David,

there are two problems with your suggestion. The first one is that
currently when a backend gets selected it tries to fully initialize
itself. For any of the X backends this means that we call XGServer
_initXContext, which tries to set up the X display and if we aren't able
to do so we just give up. Now most of the time this surely is the right
thing to do, when somebody starts up a GNUstep application and there
isn't any X server we better tell the user as soon as we know. As for
Andreas "tool", how could GNUstep know that it will be only using an
image to draw on and never will need any windows or events?

The second problem is that currently we don't have the full support for
drawing on a bitmap image representation. What we currently do here is
draw on a cached image, that is a resource from the window system (Even
there are some bugs). With the cairo backend it seems to be possible to
improve on this, but I don't have any idea how to do this for the other
backends. I hope to get around to implement the cairo version soon, but
I wouldn't mind if somebody beats me on that.

Fred


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