On Fri, Jul 10, 2020 at 08:50:48PM +0100, Aaron Sloman wrote:
> The motif version of 32 bit poplog has worked fine for many years. But as
> far as I know all the 64 bit linux poplog versions have had a strange
> problem with motif.
>
> The symptom is that that in 64 bit motif poplog, using the mouse to kill an
> XVed window works perfectly: the window disappears and poplog continues.
>
> But for any other window, e.g. a non-ved graphical window, killing it kills
> poplog. This problem does not exist in 64 bit poplog without motif.
>
> (This may also apply to some poplog non-ved menu interfaces?)
>
> Towards a diagnosis:
>
> I have recently been streamlining the display on my stonebook mini laptop,
> setting it up to work without titlebars on windows, for which alternative
> functionality is provided nicely in the highly tailorable ctwm window
> manager -- my favourite -- recently given a new lease of life here:
>
> www.ctwm.org/download.html
>
> While setting up headless windows I discovered that ctwm provides support
> for a distincion between 'delete' and 'destroy' functions applied to
> windows. 'destroy' kills not just the window, but the application to which
> the window belongs. 'delete' just removes the window.
>
> In motif poplog using xved, it is possible to use the mouse to kill an xved
> window without killing poplog. But if any non-vededitor process in poplog
> creates a window, then killing that window using a mouse kills poplog. So
> if an rc_graphic window is killed using the mouse poplog is killed, but not
> if an xved window is killed.
>
> Past discussion of this problem has led to the conclusion that there must
> be a bug in the 64 bit motif library that is not present in 32 bit motif.
>
> I now conjecture that there is a different explanation, which should lead
> to a fairly straightforward fix by someone willing to look into the poplog
> X window code.
>
> I assume that the 64-bit motif package supports the distinction between
> a mouse event that kills the whole process and one that kills only the
> window clicked.
>
> Moreover, I also assume that that distinction is used in the motif code for
> the Xved subset of poplog: since xved windows can by shut by mouse actions,
> without killing poplog.
>
> I also assume that that the poplog motif code for non-xved windows, e.g.
> graphical windows, invokes only the kill *process* action rather than the
> kill *window* action for a mouse 'kill' event.
>
> Since I am both over-committed and unfamiliar with the low level internals
> of poplog I shall not try to identify the procedure calls that need to be
> changed in the non-ved graphical bits of poplog motif extensions to match
> the corresponding calls in the ved motif extensions.
>
> I suspect it involves finding a bit of code for removing windows in
> response to mouse events in the xved subsystem and copying it to all other
> bits of code for removing windows in response to mouse events.
>
> It may be as simple as replacing calls of 'destroy' with calls of 'delete'
> throughout the motif extension to poplog?
No. While the 'destroy' versus 'delete' is likely to be crucial, the
actual mechanizm works differently. I have run Popolog under
debugger tracing interaction between Poplog and Motif. From the
point of clicking on 'delete' button to killing Poplog _all_ happens
in Motif code. For me, most likely problem place is code that
created window. Namely, normaly various possible behaviours
are chosen at window creation time. Unfortunaly, window creation
seem to be spread out over rather large area of code...
--
Waldek Hebisch
