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. :-)
Post a reply to this message