hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/19/21 3:51 PM, jr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >> ...
> >> The concern over the behavior of the token hashing function ...
> >
> > might be worth comparing with other, say the Berkeley DB, hash implementations.
>
> Not committed, but I've added such a TODO to the code along with notes
> on the versions I tested.

had I been thinking, I'd have mentioned "or anything with a decent associative
array implementation".  awk and Tcl :-) come to mind.


> >>> ...option to supply an X window to 'povr'?
> >> ...
> >> Not sure what you are after with the -windowid?
> >
> > so I could do the equivalent of 'xterm -into $id', ie have 'povr's output go
> > into a window supplied by my app.
>
> By 'output' taking you to mean the preview window.

yes.  (will try + remember to stick with correct terminology)


> It could be useful. I've not done enough X11 windows stuff to understand
> the implications. Today, certain events are captured by the preview
> window set up. Meaning - I think - the larger application would not have
> complete control the 'POV-Ray' sub window.

I suspect one would need to use the 'pause_when_done' option, cf gnuplot's
'-persist'.  the window remains povr's, the display is "live" while povr runs.
from Tk I'd create an empty frame with the '-container' option and get its id,
then run povr with an option to display itself in window '$id'.

afair, povr, when it asks for a "toplevel" (or "root"?) window, it gets a
handle.  bar one (or two) event mask stuff things, there's be no difference, and
neither povr or the user can really tell.

wish I could be more precise but when I lost my previous life a little over a
decade ago, among the losses was a near complete set of O'Reilly's X11R5 books.
so all from (dimmed) memories.


> Dreaming : As you know, I've carried for a while the thought of POV-Ray
> being it's own simple modeler for splines an such. Further, if we get to
> the point where the 'scene' rendered is responding to window events, why
> couldn't POV-Ray be a sort of infinitely configurable dynamic window gui
> widget sub-app for other applications. The executable is small enough
> (performance?). With it one could get whatever windowing look they
> wanted and not be locked into available ones with particular widget
> packages and appearances.

(I like where this is going.. :-))

a little like embedding a Tcl interpreter[*], I guess.  that particular way of
doing would not be difficult if the parser could deal with being fed piecemeal.
and even if a whole scene is required, one could generate that from boilerplate,
mostly.  thinking that other projects too might benefit, like BE's complete
keyword generator idea.

[*] have a look at df3tcl.


> Aside: Years back, I ran across a windowing package with a similar idea.
> The displayed, apparent widgets collection was decoupled from the larger
> display. It looked like there were widget gui windows everywhere, but it
> worked with only one gui 'event window' and a single dynamically
> generated and mapped image underneath. The image looking like a
> collection of gui widgets. But, I've never again been able to find my
> notes or the package!

a db with the image "hot spots", linked to event (procedures), and Robert's your
mother's brother.  :-)


> Sorry about the ramblings.

on occasion the highlight of the day.


> I'll put the -windowid thing on my 'interested in it list' - no promises.

it's a start.  :-)


regards, jr.

Post a reply to this message