On 8/15/21 5:50 PM, jr wrote:
> I too remember (vaguely) seeing such a book once.  thanks for the (snipped)
> explanation.  thinking that you might like the types of patterns designed by W
> Morris, if you don't know (of) him already.
> <https://en.wikipedia.org/wiki/William_Morris>
> 

Thanks for the pointer.

> 
>> FWIW. I took a couple day run at your '-window id' feature idea and failed.
>>
...
> I'm wondering whether you aren't .. over-complicating.  on the Tcl/Tk side - the
> app provides a 'frame' created with '-container', frames have no (default)
> bindings.  I envisage generating a temp scene (and perhaps ini), then 'exec'
> povray and tell it to put the preview yonder.
> 

Very likely so... ;-) I should also say up front while I use Tcl daily, 
I've only, ever been, a light user of Tk on the programming side of 
things. My testing during my attempt used c code to create a frame 
window, not Tk.

Do you have a simpler tcl/tk script creating a frame window I could steal?

My view is certainly fuzzy, but are there not events which should always 
be handled - like someone closing the parent window into which POV-Ray 
displays(1). POV-Ray couldn't stop a user from doing this if the parent 
window permits it.

(1) Aside. Closing the preview window causes segfault with povr's x11 
display - while the sdl2.0 version won't permit the window to be closed 
except by the POV-Ray approved events. On my list to fix - someday.

There are things like window re-sizing which POV-Ray doesn't handle 
today, so if someone starts re-sizing the parent I don't know what 
happens upstream. Does X11 just handle having an child it cannot re-size 
or do unfortunate things happen?

While POV-Ray is running with a preview window, for it's own event loop 
to work to pause or exit, say, that preview window must have the overall 
window manager's focus. What happens in the larger containing app's 
window as focus moves around to sub windows? That's something likely to 
happen if the preview window is wrapped in a larger set of windows.

Further, in my attempt, I tried to bypass the icon set up and handling 
because it didn't seem like there should be an icon if the preview 
window wasn't owned by the root window. Without an icon though, it's 
harder to get the focus back on the POV-Ray preview window.

Lastly, in my simpler modeler scenario I'd want some events passed to 
the parent window's event handler loop from the one POV-Ray is running 
for it's own purposes. I'm not clear on how all that would work.

I'm fuzzy/lost as to how much of this works/should work. If I could get 
something basic going, I could start working through the questions - but 
I didn't get that far. :-(

> re '-into'.  I had a v cursory look at xterm source ('xterm-325'), of interest
> in only 'main.c' in that it processes options, and its call to a function
> 'misc.c:xtermEmbedWindow()', which wraps 'XReparentWindow()'; the rest of
> 'misc'c' will probably also provide insights.
> 

Yes, I should look at that code ahead of another attempt.

> 
...
>> I played some with the xcb alternative to xlib too. Why? Well, I
>> strongly suspect that threads xlib fix we came up with isn't going to
>> fly with a -window id / -into feature.
> ??  the window would be the same, just a different owner.

My understanding is the issue with multiple xlib threads addressed by 
XInitThreads() in part protects 'global' variables in X. My thinking is 
this requires something of the x server being used - at least to the 
window level taking up parentage - which is probably OK when I have the 
access to change the parent's behavior. What happens when I don't?

I'll guess from your question, perhaps XInitThreads() 'access ordering' 
is localized at the preview window and below? In other words, it doesn't 
involve the frame window or any above it?

Bill P.

Post a reply to this message