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