On 11/12/2017 01:00 AM, clipka wrote:
> 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.

Ok.

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

Yes. I plan on demoing Linux and Windows, which is what I have available.

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

No. I envision a third option in VS2015. Currently, there's "GUI" and 
"Console" iirc. I'd add a third option "Websockets".

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

Ok.

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

Yes, separate the GUI from the render system. I'm trying to be as 
unobtrusive as possible to the current povray source tree.

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

Hmm, interesting. I didn't notice the network aspects of POVMS, but I 
wasn't looking. That would be a lot tighter binding than I was 
contemplating.

One thing about vfe/POVMS, is that file I/O happens in both the frontend 
and backend. This currently limits the networking to localhost.

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

Yes. What I have done is subclass vfeSession. Instead of vfeUnixSession 
there is now vfeWebsocketSession.  I think it will be easy to flesh out 
vfeWebsocketSession because I have a working model of what I need to 
feed vfeSession with the existing vfeUnixSession.


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

s/go away/will be unused in the websockets incarnation/

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

Yes, ain't nothing to a Qt makefile.
http://git.buckosoft.com/gitweb/pov.cgi?p=qtpov.git;a=blob_plain;f=qtpov.pro;hb=HEAD

There is obviously a lot of magic happening behind the scenes to turn 
that into:
g++ -c -pipe -g -std=gnu++11 -Wall -W -D_REENTRANT -fPIC 
-DQT_DEPRECATED_WARNINGS -DQT_QML_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB 
-DQT_CORE_LIB -I../qtpov -I. -I/opt/Qt/5.9.1/gcc_64/include 
-I/opt/Qt/5.9.1/gcc_64/include/QtWidgets 
-I/opt/Qt/5.9.1/gcc_64/include/QtGui 
-I/opt/Qt/5.9.1/gcc_64/include/QtCore -I. -isystem /usr/include/libdrm 
-I. -I/opt/Qt/5.9.1/gcc_64/mkspecs/linux-g++ -o mainwindow.o 
../qtpov/mainwindow.cpp

One nice thing about Qt, is the Windows version supports gcc/MinGW and 
VS2015 compilers. I use the VS2015 because it seems to have more robust 
debugging and seems to generate faster code, at least for bsAniPic.

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

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

All right, I think I see.  You envision a single unified build based on 
Qt.  The GUI and the engine build to make one big happy program.

I could spend months learning and tweaking the Qt build system and CPU 
optimizations to build a well optimized backend. If rendering is 5% 
slower, the users won't adopt it.  This is not my strength, and I'm not 
interested in it at this time. I just want to make it work so I can get 
back to my animation. :)

So Phase 1, I'm going to continue on my websockets, separate source, 
separate build, plan. If it dies, it dies. If it turns out good, then
Phase 2 will be move the GUI tree to ./qt and get the whole thing to 
build with Qt.
Phase 3 will be remove the websockets and give the GUI either a direct 
vfe interface or maybe POVMS.

Sound ok to you?

-- 
dik

Post a reply to this message