WM_DELETE_WINDOW does not send ClientMessage

[Carsten Haitzler (The Rasterman)]

On Sun, 19 Jan 2020 19:05:58 +0100 Roland Plüss <roland at rptd.ch> said:

> In many cases I can do it purely on the render thread only if this
> helps. If though a toolkit is involved (FOX in this case) then I need to
> "inject" the render window.
> 
> I can prevent synchronization issues easily if this is required as I
> have a specific synchronization window so no two display would access X
> at the same time. Would this help?

well you already hit a problem... you had events going to different places.
you'll hit more as time goes on if you use 2 display connections and actively
do different things in each. especially things like create a window in one of
them then listen for events for it in another. you will find wonderful gotchas
like only one of those display connections can get mouse button press/release
events, both can get mouse motion but only until some button is held down... in
this case "first come, the only one served". you will find things like handling
of operation now goes out of order. i hope you set an x error handler rather
than rely on the standard xlib one too... or you're in even deeper trouble etc.

just fair warning. you walk down a dangerous path i wouldn't advise unless you
are an old x hack who has been around the block a few times and knows the
nasties that shall happen... :)

> On 1/19/20 6:28 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Sun, 19 Jan 2020 15:17:17 +0100 Roland Plüss <roland at rptd.ch> said:
> >
> >> Hi Lucien,
> >>
> >> Depends what you call the same display. The window is created in the
> >> render thread while event looping is done in the main thread. In both
> >> places XOpenDisplay(getenv("DISPLAY")) is called. Is this not the same
> >> display? If not how can I "attach" them together? It's a requirement
> >> that the render thread creates the window while the main thread has to
> >> handle the event loop (to my knowledge only this works).
> > you use 2 display handles? oooooh... you're asking for trouble. you're
> > asking for ownesrship and lifecycle issues there as well as race conditions.
> >
> > xlib can handle threads on the same Display handle, you just need to
> > XInitThreads() before you go using more than 1 thread with it. :)
> >
> >> On 1/19/20 2:43 PM, Lucien Gentis wrote:
> >>> Hello Roland,
> >>>
> >>> While defining delAtom and calling XSetWMProtocls, you specifiy
> >>> "display", and in your loop, you specify "pDisplay" ; is it the same
> >>> display ?
> >>>
> >>> Le 19/01/2020 à 13:33, Roland Plüss a écrit :
> >>>> I'm finishing up my software for releasing but run into a big issue. If
> >>>> I use window mode instead of full-screen mode the user should be able to
> >>>> close the window using the X button. I can prevent this from happening
> >>>> using this code:
> >>>>
> >>>> Atom delAtom = XInternAtom( display, "WM_DELETE_WINDOW", False );
> >>>> XSetWMProtocols( display, pWindow, &delAtom, 1 );
> >>>>
> >>>> The window will not be destroyed when X is pressed so I think this
> >>>> worked. The problem is though that I do not received ClientMessage and
> >>>> thus I am unable to close the window. This is the event loop:
> >>>>
> >>>> XEvent event;
> >>>> while( XPending( pDisplay ) ){
> >>>>    XNextEvent( pDisplay, &event );
> >>>>    log("Event %d", event.type);
> >>>>    switch( event.type ){
> >>>>    ...
> >>>>    case ClientMessage:
> >>>>       log("Quit Request Received");
> >>>>       break;
> >>>>    }
> >>>> }
> >>>>
> >>>> Window is created like this:
> >>>>
> >>>> #define BASIC_EVENT_MASK     ( StructureNotifyMask | ExposureMask |
> >>>> PropertyChangeMask \
> >>>>                              | EnterWindowMask | LeaveWindowMask |
> >>>> KeyPressMask \
> >>>>                              | KeyReleaseMask | KeymapStateMask |
> >>>> FocusChangeMask )
> >>>>
> >>>> #define NOT_PROPAGATE_MASK   ( KeyPressMask | KeyReleaseMask |
> >>>> ButtonPressMask \
> >>>>                              | ButtonReleaseMask | PointerMotionMask |
> >>>> ButtonMotionMask )
> >>>>
> >>>> XSetWindowAttributes swa;
> >>>> swa.colormap = colMap;
> >>>> swa.backing_store = NotUseful;
> >>>> swa.border_pixel = 0;
> >>>> swa.event_mask = BASIC_EVENT_MASK;
> >>>> swa.do_not_propagate_mask = NOT_PROPAGATE_MASK;
> >>>> swa.override_redirect = False;
> >>>> swa.save_under = False;
> >>>> swa.cursor = 0;
> >>>> swa.bit_gravity = ForgetGravity;
> >>>> swa.win_gravity = NorthWestGravity;
> >>>>
> >>>> Any idea what else I need to do to get this working?
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> xorg at lists.x.org: X.Org support
> >>>> Archives: http://lists.freedesktop.org/archives/xorg
> >>>> Info: https://lists.x.org/mailman/listinfo/xorg
> >>>> Your subscription address: %(user_address)s
> >>> _______________________________________________
> >>> xorg at lists.x.org: X.Org support
> >>> Archives: http://lists.freedesktop.org/archives/xorg
> >>> Info: https://lists.x.org/mailman/listinfo/xorg
> >>> Your subscription address: %(user_address)s
> >> -- 
> >> Mit freundlichen Grüssen
> >> Plüss Roland
> >>
> >> Leader und Head Programmer
> >> - Game: Epsylon ( http://www.indiedb.com/games/epsylon )
> >> - Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine
> >> , http://dragengine.rptd.ch/wiki )
> >> - Sowie verschiedene Blender Export-Skripts und Game-Tools
> >
> 
> -- 
> Mit freundlichen Grüssen
> Plüss Roland
> 
> Leader und Head Programmer
> - Game: Epsylon ( http://www.indiedb.com/games/epsylon )
> - Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine
> , http://dragengine.rptd.ch/wiki )
> - Sowie verschiedene Blender Export-Skripts und Game-Tools
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com