|
 |
On 4/19/21 3:51 PM, jr wrote:
> hi,
>
> William F Pokorny <ano### [at] anonymous org> 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.
>
>>> ...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.
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.
---
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.
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!
Sorry about the ramblings. I'll put the -windowid thing on my
'interested in it list' - no promises.
Bill P.
Post a reply to this message
|
|
