hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/15/21 4:09 AM, jr wrote:
> ...
> > love this "stirring paint" effect.
> >
> :-) Thanks.
>
> I inherited an old leather bound book publish sometime in the mid to
> late 1800s; since given it to my daughter. In trying to learn more about
> the book, I corresponded for a time with a librarian at university which
> had a similar book. On the inside covers there were these wonderful
> color swirling patterns and I asked her how they were done.

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>


> FWIW. I took a couple day run at your '-window id' feature idea and failed.
>
> Learned quite a bit about X - enough to address two unix display issues
> Jerome uncovered some years back with all the preview displays. The
> approach tried, I borrowed from 'feh' which just added a window id
> feature. I think a more invasive method is likely necessary for POV-Ray,
> but, maybe I'm still clueless.
>
> Also, in looking at the tcl/tk code supporting such 'adopted' windows, I
> wonder, still, about getting all the event masks and handling lined up
> so nothing is tangled that should not be - except, you know, what should be.

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.

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.


> Maybe I'll take a run at it again down the road. I have an interest in a
> simple generic interface for things like modeling splines on the fly
> using POV-Ray as for both modeling and display - as you know.
>
> 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.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > On 8/15/21 4:09 AM, jr wrote:
> > ...
> > FWIW. I took a couple day run at your '-window id' feature idea and failed.

sheesh.  I never even said thank you, sorry, do so now.


regards, jr.

Post a reply to this message

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

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)

On 8/16/21 8:08 AM, jr wrote:
> 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?

First, thanks for the detailed response. I'll add it to my notes for the 
next attempt. And on seeing your posted example, it does ring a bell... 
Sorry if I did miss it - or forget I saw it posted.

---
Re: dbus, pipes. Your guessing my aims correctly.

There are crude ways to call povray in a loop today - adjusting say 
spline control points. Such an approach which would be made much cleaner 
with some sort of window id / into functionality as you've suggested. 
Such an approach if, working with Tk frame widows, opens up Python and 
Tcl as the scripting mechanism for "modeling/simple POV-Ray created 
widget windows."

However, I'd like something a step beyond this coupled with rtr - which 
in my minds eye at the moment - requires a couple of os level tasks be 
talking to each other(1) continuously - or to, perhaps, be aware of X11 
events in a shared way.

I'm ignorant of too much at the moment to know what I really want.

There are all the widget packages too - Qt, etc. With povr, I'm aiming 
at more of a small utility niche with little or no overhead - something 
'easy'. Pipe dream I expect, but a push here and a push there and maybe 
some path to such a thing opens up....

(1) - POV-Ray has Thorsten's povms which has some facilities for such 
communication. While I've learned tiny bit about that code of late, I'm 
a long, long way from being able to swing that code around as a useful 
hammer inside POV-Ray - let alone extend it.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/16/21 8:08 AM, jr wrote:
> > ...
> Re: dbus, pipes. Your guessing my aims correctly.
>
> There are crude ways to call povray in a loop today - adjusting say
> spline control points. Such an approach which would be made much cleaner
> with some sort of window id / into functionality as you've suggested.
> Such an approach if, working with Tk frame widows, opens up Python and
> Tcl as the scripting mechanism for "modeling/simple POV-Ray created
> widget windows."

XReparentWindow()'s documentation says "...if the specified window was
originally mapped, the X server automatically performs a MapWindow request on
it."

so,wondering whether you'll indulge me and run a test (somewhere under the 'jr
causing trouble' directory. :-)) with a new command-line option.

I looked at xterm code.  the '-into' arg is converted (strtol()) and cast to
Window type.  it is passed to 'misc.c:xtermEmbedWindow', where it's used as
third arg in XReparentWindow.  I also looked at your 'disp_x11.cpp', the
XMapWindow call in line 429.  so, why not try and place a call to
XReparentWindow in line 430?  I've attached a simple Tk UI which provides a
800x600 frame[*] and outputs its window id to stderr.  if you can get that into
povr?!

[*] can easily be changed in line 12.

of course it's a hack, and probably will "flicker" once as it would be unmapped
immediately after line 429, but hey..


> However, I'd like something a step beyond this coupled with rtr - which
> in my minds eye at the moment - requires a couple of os level tasks be
> talking to each other(1) continuously - or to, perhaps, be aware of X11
> events in a shared way.
>
> I'm ignorant of too much at the moment to know what I really want.

didn't the Sex Pistols sing "I don't know what I want, but I know how to get
it"?  :-)


> ... Pipe dream I expect, but a push here and a push there and maybe
> some path to such a thing opens up....

another lyric ;-) -- "little by little, and stone by stone (rich man's mountain
comes crumbling down)" (UB40)


regards,jr.

Post a reply to this message

Attachments:
Download 'frm.tk.txt' (1 KB)

On 8/17/21 9:12 AM, jr wrote:
> so,wondering whether you'll indulge me and run a test (somewhere under the 'jr
> causing trouble' directory. :-)) with a new command-line option.

Very likely :-), but not immediately. I'm working on a couple other bits 
of code at the moment.

Your/xterm's use of XReparentWindow() was not used in the coding 
approach taken by feh(1). Better, it's simpler than what I'd planned to 
try in my next attempt in creating the preview window completely under 
the passed id, where one passed.

(1) - FWIW. I slipped up and didn't say it when I posted the 
f_distribution() sample images, but those were done with feh's caption 
highlight method. You'd been discussion highlight options/colors for 
your table include...

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Your/xterm's use of XReparentWindow() was not used in the coding
> approach taken by feh(1). Better, it's simpler than what I'd planned to
> try in my next attempt in creating the preview window completely under
> the passed id, where one passed.

I use 'xv' and (the window manager's own) 'wmiv' as image viewers, but had a
quick look at 'feh's man page, and would be interested how its '-list' output
compares to '$ identify *'.

re "coding approach", perhaps look at 'xterm' (or some other "old" utility)
source instead.  also, ought to have mentioned that the actual call to
XReparentWindow() is conditional on a call to a wrapper function
('xtermGetWinAttrs()') succeeding; that, essentially, is a
'XGetWindowAttributes()' call to see whether the id is valid.


> (1) - FWIW. I slipped up and didn't say it when I posted the
> f_distribution() sample images, but those were done with feh's caption
> highlight method. You'd been discussion highlight options/colors for
> your table include...

I think they should be called labels not captions, as they're inside the images
:-).  natty dash separators, are they supplied or did you have to type them?


regards, jr.

Post a reply to this message

On 8/19/21 4:58 AM, jr wrote:
...

FWIW.

'identify hmm.png'

hmm.png PNG 160x120 160x120+0+0 8-bit sRGB 25661B 0.000u 0:00.000

'feh --list hmm.png'

NUM     FORMAT  WIDTH   HEIGHT  PIXELS  SIZE    ALPHA   FILENAME
1       png     160     120      19k     26k    -       hmm.png

Both generate a lot of noise if you ask them to read files / formats 
they cannot.

> I think they should be called labels not captions, as they're inside the images
> :-).  natty dash separators, are they supplied or did you have to type them?

Labels/captions. I leaned on feh's thumbnails and - caption directory 
text files for each image - feature. These are sometimes actual captions 
and sometimes more like labels depending on - a lot of things. FWIW... :-)

The dashes I added on the fly while editing the caption files. The 
caption files can be paragraphs of text or what ever you want to put in 
them. Positioning is limited to lower left corner or lower centered when 
over an image and pretty sure something similar for actual 
index/thumbnail captions.

---
Wild aside on feh:

I moved to feh as my 'quick' image viewer because it can use a large 
cache and so not bang on my actual disk drive while displaying and 
visually comparing images. The latter I do a lot - a quick switch 
between two images to see what my eyes pick up. I could never get 
programs like eog not to not use my actual disk drive without a fair bit 
of extra set up/work.

Anyhow, feh has some interesting features like being able to create on 
the fly hot index/thumbnail images. Further, you can code up a number of 
actions on key sequences while an image is displayed.

Not explored it too much yet, but this looks a fair bit of the framework 
needed to create additional automation around my full scene test cases.

Or, perhaps to back a collection of images with help text / actual scene 
files / rendering changed files on the fly / ...  At this point just a 
possible path to such things I guess, but looks interesting.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> 'identify hmm.png'
>
> hmm.png PNG 160x120 160x120+0+0 8-bit sRGB 25661B 0.000u 0:00.000
>
> 'feh --list hmm.png'
>
> NUM     FORMAT  WIDTH   HEIGHT  PIXELS  SIZE    ALPHA   FILENAME
> 1       png     160     120      19k     26k    -       hmm.png

thank you v much.  I may yet install this, to try out, quite like the tiled
view, and am intrigued by the (snipped) mention of keyboard macros executing.


> > :-).  natty dash separators, are they supplied or did you have to type them?
>
> Labels/captions. I leaned on feh's thumbnails and - caption directory
> text files for each image - feature. These are sometimes actual captions
> and sometimes more like labels depending on - a lot of things. FWIW... :-)

and per directory caption files too sounds an interesting feature, know of no
equivalent.


> The dashes I added on the fly while editing the caption files.

now thinking of adding dashes to Tabulated()'s caption.  :-)

the 'frm.tk' script has the drawback that it exits when the client's window is
closed (ok for terminal, not so for this use).  attached a version which uses a
different "pattern", providing as many frames as needed, one at a time; the
frame's dimensions too are now easily adapted.


regards, jr.

Post a reply to this message

Attachments:
Download 'f2.tk.txt' (1 KB)