hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> 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?

the attached is slightly different in that it drives 'gnuplot's stdin, also, it
was "a bit of fun" only, so the code is not .. tidy.  (also,as I write this, I
think I may have posted this before)


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

cannot really tell what might happen, but when a Tk application's windows get
destroyed, it's all done via 'WM_DELETE_WINDOW', see 'wm(n)'.  assume POV-Ray
will simply get notified to close its window.


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

SDL would not do anyway, never found a way to get an (X) window id.


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

the frame, within the app, can be created not to resize, so the scenario can not
happen (famous last words :-)).


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

I use the 'focus-follows-mouse' setting on my machines, so, from experience, I
think it unlikely to be a problem.


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

from POV-Ray's perspective, there's no difference whether the windows manager,
or an application, provides the "toplevel".


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

phew..  I'm not sure what event POV-Ray would want to pass to the application,
could you .. flesh this out a little, please?  but there'd be other mechanisms,
pipes, dbus?


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

yes, but the server does "get told" (XReparentWindow), so not sure "higher
levels of abstraction" libs have additional "needs".


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

if I understand correctly, and aiui, the (preview) window knows nothing about
who "owns" the top-level (ie WM or app).  when created the event mask will allow
for it to receive select events, whoever sends them.


regards, jr.

Post a reply to this message

Attachments:
Download 'wfp_tk.tar.xz.dat' (2 KB)