[Top][All Lists]

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

Re: Mixing X and GNUstep

From: Adam Fedor
Subject: Re: Mixing X and GNUstep
Date: Fri, 11 Jul 2003 11:43:11 -0600

On Friday, July 11, 2003, at 11:15 AM, Raffael Herzog wrote:


I'm learning GNUstep programming and thought a GNUstep frontend to Xine would be a relatively easy task for a first application - except one thing, which is very special about that: Embedding Xine into a GNUstep window.

I do the following to get the information I need for Xine:

 // use XGServer dynamically -> no need to link against gnustep-back
 Class xgServer = objc_get_class("XGServer");
 IMP imp = [xgServer methodForSelector: @selector(_windowWithTag:)];
 gswindow_device_t *dev = (gswindow_device_t *)imp(xgServer,
@selector(_windowWithTag:), [window windowNumber]);
 xineVisual.display = dev->display;
 xineVisual.screen = dev->screen;
 xineVisual.d = dev->ident;

-> is there a cleaner way? I mean, this is now really hacking in the middle of the internals of the backend... :-/

Use the GSDisplayServer methods



Display *dpy = [[GSDisplayServer currentServer] serverDevice];

Although there's no way to check that you're actually running on X-Windows - perhaps I should add something that lets the GUI know which backend is being used...



for info.

When I run the program and make Xine display its logo, it appears for a short time, but then the program segfaults:

 2003-07-11 18:41:14.598 GSXine[2915] Class: 409ded00
 2003-07-11 18:41:14.603 GSXine[2915] imp: 409b0bbc
 2003-07-11 18:41:14.606 GSXine[2915] Display: 8194890
 2003-07-11 18:41:14.609 GSXine[2915] Screen: 0
 2003-07-11 18:41:14.612 GSXine[2915] Window ID: 5800025
 Benchmarking memcpy methods (smaller is better):
         glibc memcpy() : 716135828
         linux kernel memcpy() : 682846012
         MMX optimized memcpy() : 687281104
         MMXEXT optimized memcpy() : 444966988
         SSE optimized memcpy() : 422982120
 2003-07-11 18:41:17.185 GSXine[2915] Received an untrapped event
 Speicherzugriffsfehler (core dumped)

Any ideas what's going on there? Is my idea realisable at all?

Well, the last log message shows that the backend is getting an event that we don't handle. Perhaps you could debug it and find out which event it is (or make the log statement more informative ---see back/Source/x11/XGServerEvent.m: 1269)

Then continue debugging and get a backtrace after the segfault...

reply via email to

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