Am 12.11.2017 um 00:56 schrieb dick balaska:
> 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,

I think we aren't yet. Somehow we're still talking different language here.

> there is no Qt in the povray source tree.

Of course not (yet). But if you write a Qt-based GUI, and we want to
make it an official part of the POV-Ray package (to replace that
outdated POV-Ray for Windows GUI, for instance), then obviously that
means Qt-based code must get into the POV-Ray 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.)

I'm pretty sure that's not enough -- if the goal is for the Qt-based GUI
to run on all Qt-supported platforms. And from my seat, that's exactly
the goal.


>> 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.

It doesn't matter whether you add a websockets interface to the existing
Unix binary, or create a new Unix binary with the command-line parser
replaced by a websockets interface: Neither binary will run on Windows,
and thus your Qt-based GUI will be mostly useless on Windows.


> The --websockets option to ./prebuild.sh does a substitution of vfe/unix
> with vfe/websockets.

We don't have `./prebuild.sh` on Windows. And just replacing the vfe
package doesn't turn a Unix-specific application into a platform-neutral
one.

Besides, at this point I'm wondering whether you're doing the right
thing with the websockets interface:

- The official interface between the UI and the actual parser/renderer
system is the POVMS layer.

- The VFE layer was placed on top of that for easier use of the POVMS
layer on the UI side.

- Now you're placing a third layer on top of that, to... well, why
exactly? Separate the GUI from the actual parser/renderer system?

I'd like to point out here that although the POVMS layer is currently
only used to communicate between different threads of the same process,
it was originally designed specifically as an interface to be used
between separate processes or even over a network connection. So rather
than bolt websockets on top of the VFE layer, it seems to me the right
thing to do would be to integrate it /into/ POVMS as a channel to
transport POVMS messages. Think POVMS-over-websockets.

I don't claim that to be an easy task, as I do expect some weed still in
there that needs removing. (Somewhen during the development of v3.7.0,
the strict use of the POVMS layer had been eroded quite significantly,
with the VFE communicating directly with the parser/renderer subsystem
at various points. I've been trimming down that wild growth since, but
there may still be remnants of that eposide lurking in there.)

So your Qt-based GUI should really access either VFE or POVMS directly
(or via a layer running in the same process), with the actual
inter-process communication happening within the POVMS layer.


> 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. :)

The `prebuild.sh` script is not an automake system -- rather, it is a
pre-processing script designed to keep our repository as free from
build-process-specific stuff as possible. Most notably, the script:

- /Creates/ certain autotools-specific files from platform-neutral
sources, in order to avoid having to maintain the redundant information
in those autotools-specific files manually.

- /Copies/ other autotools-specific files from other locations to the
root directory of the package, in order to avoid cluttering the root
directory with stuff only required by one particular build process.


> 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.

Ultimately? Yes, I'd like to see a `platform/qt` (in /addition/ to the
existing `platform/*`, mind you), if only because it would instantly
allow us to support a number of additional platforms -- anything
supported by Qt.

In the short run? No. As I said, I expect it easy to replace further
down the road, so why bother when there's still more important stuff in
the way.


> 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.

That is something that I think we should avoid. (And physically removing
files from the tree is a no-go, obviously.)

Qt is a platform-independent framework, so I'd presume it provides
/some/ mechanism to manage the build process in a platform-independent
manner (possibly by maintaining build information in a platform-neutral
form, and auto-generating platform-specific build information from that,
just like we currently do with our Unix `prebuild.sh` script).

So anything specific to the Qt-based incarnation of POV-Ray should
reside in its own dedicated directory (say, `./qt`, instead of `./unix`
or `./windows`, respectively).


I think it is important that we distinguish between what I like to refer
as "platforms" and "incarnations":

- When I talk about "platforms", I think of certain low-level
functionality that is essential for POV-Ray on each and every operating
system, but which can't be implemented in a portable fashion. For
instance the `file_exists()` scene language function requires that we
can determine whether a file exists or not, but on Windows this needs a
different function call than on Unix. In order to solve this, we have
"platform-specific" code tucked away in `./platform` (and probably other
places as well, but those will be weeded out in the long run).

- On the other hand we have "POV-Ray for Windows" and "POV-Ray for
Unix", which I'd like to refer to as "incarnations" of POV-Ray. And
while they happen to run on different platforms, and need different code
to e.g. test whether a directory exists, it's not their main difference.
Instead, they're really different pieces of software, which just happen
to share certain pieces of code (namely the stuff residing in
`./source`, plus a few odds & ends like platform-neutral portions of the
VFE). These should be tucked away in `./windows` and `./unix`,
respectively. Other "incarnations" also exist, such as Yvo's version for
Mac OS, which comes with its own GUI (and presumably uses
platform-specific code for Unix), and I'd also consider the
command-line-only version for Windows a separate "incarnation".

When talking about Qt, we have the same duality:

- As a framework for creating platform-independent software, Qt surely
must provide its own interface to do stuff such as determining whether a
particular file exists or not. While this will actually be a wrapper, it
makes sense of thinking of it as yet another "platform". And any
"incarnation" designed to make use of Qt should better also make use of
this "platform", lest the biggest benefit of Qt -- portability -- be wasted.

- A Qt-based GUI for POV-Ray has to /either/ constitute an "incarnation"
of POV-Ray in its own right, /or/ invoke some "incarnation" to do the
actual work. In the latter case (which I understand is your approach),
this should ideally be a portable "incarnation" (and thus necessarily a
new one, ideally based on Qt as well), again lest the biggest benefit of
Qt be wasted.

Post a reply to this message