On 11/11/2017 03:53 PM, clipka wrote:

> No, not a Qt based render engine -- just a Qt based program (which acts
> as a wrapper for the actual render engine) that you invoke from the GUI
> to render scenes.

yes.

Hmm, just to be sure we're on the same page, there is no Qt in the 
povray source tree.  The "wrapper" is a separate program and 
communicates via a socket.  My pollution to the source consists of 
adding an std/boost based header only websocket library.
https://github.com/zaphoyd/websocketpp
(Although oddly, I had to add -lstd++ to the build for 
std::basic_string, which I thought would have been there.)

> It appears to me that the way you're approaching it, that would be a
> replacement for both the Unix command-line version as well as
> povconsole.exe.

Yes. And it's the "replacement" part that I internally debate.  I have 
chosen to generate povrayws as a separate unix binary to povray, because 
the unix frontend (command line parser) is ripped out and replaced.

But I wonder if instead I should have kept a single binary with a new 
povray option -N4401 to switch to the websockets version at runtime.
The vfe(s) are nicely thin, and I don't see a problem switching to that 
technique if later it is preferred.

> 
> The reason being that ideally the system as a whole should run on /any/
> platform supported by Qt, not just those for which we /happen/ to
> already have a command-line version of POV-Ray.
> 
> In terms of source files, this means that your system should compile and
> run fine without any of the files residing in `unix`, `windows`,
> `vfe/unix` or `vfe/win`, and ultimately even without any of the files in
> `platform/unix` or `platform/windows` (though these last two are
> probably comparatively easy to fix further down the road, by
> establishing some `platform/qt` instead).
> 

The --websockets option to ./prebuild.sh does a substitution of vfe/unix 
with vfe/websockets.
At first, I thought ./prebuild.sh was really overengineered. It is the 
most complicated automake system I've ever seen. (A script to create 
./configure.in and massive Makefile.in(s) ? Why not just have those 
files?) But it works for me because now I do the directory substitutions. :)

platform/[unix|windows] has to stay because that is backend system grunt 
work (timers).  I don't know if I see value in platform/qt. Do you 
really want to drag in all of the Qt baggage (custom build system, 
custom packaging) just to provide a backend timer. -- If it ain't 
broken, don't fix it.

The source files in $(povray)/unix are now unused (display a picture), 
but I need the control foo in there. I think the same thing happens to 
$(povray)/windows, too. The *.cpp go away but the vs2015 directory, at 
least, will remain.

-- 
dik

Post a reply to this message