I started on qtpov.
http://www.buckosoft.com/qtpov/g/qtpov.png
I wanted to be further along before saying anything, but...

I thought I remembered that povray used a message bus system, and I was 
going to hook up a websocket server to that.
http://www.buckosoft.com/qtpov/g/qtpovPrefs.png
:)
Then, I can emit websocket messages for parse errors, % completion, and 
graphics data, etc.  I'm still trying to grok the povray message system, 
but it looks to be more point-to-point.

qtpov (the editor) will launch povray and connect to it.  This is 
reversed from the Windows paradigm of pvengine calling the editor in a DLL.



-- 
dik

Post a reply to this message

Am 25.10.2017 um 15:22 schrieb dick balaska:
> I started on qtpov.
> http://www.buckosoft.com/qtpov/g/qtpov.png

Go for it!

If you need /any/ assistance whatsoever, let us know.

Developing some brand-spanking-new frontend based on a
platform-independent framework has been on our agenda for quite a while
now (and as it happens Qt was our first choice for that purpose as
well), but none of the dev team has managed to collect enough Round
Tuits(tm) so far to actually make it happen.

> I wanted to be further along before saying anything, but...

It's further than I had come ;)


> qtpov (the editor) will launch povray and connect to it.  This is
> reversed from the Windows paradigm of pvengine calling the editor in a DLL.

In the terminology we usually apply to POV-Ray for Windows, qtpov
wouldn't be a called an editor, but a GUI. The "editor" in POV-Ray for
Windows is really just the 3rd-party syntax-highlighted multi-line text
input component.

Post a reply to this message

dick balaska <dic### [at] buckosoftcom> wrote:
> I started on qtpov.
> http://www.buckosoft.com/qtpov/g/qtpov.png
> I wanted to be further along before saying anything, but...
>
> I thought I remembered that povray used a message bus system, and I was
> going to hook up a websocket server to that.
> http://www.buckosoft.com/qtpov/g/qtpovPrefs.png
> :)
> Then, I can emit websocket messages for parse errors, % completion, and
> graphics data, etc.  I'm still trying to grok the povray message system,
> but it looks to be more point-to-point.
>
> qtpov (the editor) will launch povray and connect to it.  This is
> reversed from the Windows paradigm of pvengine calling the editor in a DLL.

I just sent you an email with a link to a full repository with a QT frontend
that I just never finished. It shows you how to do all the stuff needed with
regard to networking and does work.

The main catch is that it is based on a way different source tree than the (now)
mainline 3.7, hence some backporting will be required. But given I designed and
wrote POVMS, a diff with the approprite source tree version (a late 3.7 beta)
will give you all the clues you need, I suppose. And you can just email me if
you have questions about the source, too.

The code is all AGPL of course, I just don't want to support it officially, and
I really don't want to put a 133 MB source archive link here either.

Thorsten

Post a reply to this message

On 10/25/2017 09:22 AM, dick balaska wrote:
> I started on qtpov.

I got a bit sidetracked with making a configurable colored editor, 
because *that's* important. (It's better to look good than to feel good, 
and darling, you look mahvelous).

Also, that gave me time to contemplate how best to attack websockets[1].

I was going to piggyback on the unix build and add a -N4041 option to 
open a listen port on 4041. Without the option, it'd be a regular unix 
build.

Perhaps a better approach, certainly easier, is to replace the unix 
frontend with a websocket frontend. This is due to the message system 
being point-to-point, instead of a buss.

I have the basic program built. It is DDS[2] but it builds.
I changed ./prebuild.sh to take a --websockets option to cause it to 
generate the correct Makefiles. I'm not sure I like that from a user's pov.

I keep going back and forth as to whether the separate websockets binary 
is better than a single unix binary that does traditional and websockets.

-- 
dik

[1] It's a stupid name.  Akin to javascript being a stupid name.
[2] DDS - Doesn't Do Shit.

Post a reply to this message

Am 11.11.2017 um 09:41 schrieb dick balaska:
> On 10/25/2017 09:22 AM, dick balaska wrote:
>> I started on qtpov.
> 
> I got a bit sidetracked with making a configurable colored editor,
> because *that's* important. (It's better to look good than to feel good,
> and darling, you look mahvelous).

I hear you. With all the computer games I intended to write as a kid, I
/did/ always complete the title screen ;)


> Also, that gave me time to contemplate how best to attack websockets[1].
> 
> I was going to piggyback on the unix build and add a -N4041 option to
> open a listen port on 4041. Without the option, it'd be a regular unix
> build.
> 
> Perhaps a better approach, certainly easier, is to replace the unix
> frontend with a websocket frontend. This is due to the message system
> being point-to-point, instead of a buss.
> 
> I have the basic program built. It is DDS[2] but it builds.
> I changed ./prebuild.sh to take a --websockets option to cause it to
> generate the correct Makefiles. I'm not sure I like that from a user's pov.
> 
> I keep going back and forth as to whether the separate websockets binary
> is better than a single unix binary that does traditional and websockets.

Uh... wait!
Unix binary?
If you go for Qt, then by all means please make sure the system in its
entirety is portable.
I'd presume that if you really go for separating the GUI from the
program that renders scenes, this means writing a new Qt-based instance
of the latter.

Post a reply to this message

On 11/11/2017 08:04 AM, clipka wrote:

> Uh... wait!
> Unix binary?
> If you go for Qt, then by all means please make sure the system in its
> entirety is portable.
> I'd presume that if you really go for separating the GUI from the
> program that renders scenes, this means writing a new Qt-based instance
> of the latter.
> 

A Qt based render engine? Why?  There is already a cross platform render 
engine. I want to leverage that as much as possible.
What I'm doing is a separate source tree for qtpov. This is the gui.
The gui launches povray (or povconsole.exe) and connects to it via a 
websocket. Then the gui can instruct povray to start a render and 
receive the 5 streams and in-progress graphics info.

I assume portability. I'm just doing the work on Ubuntu 16. I'm not 
looking forward to doing the Windows version since my Windows 8 now is 
limited to a 1024x768 window inside VirtualBox. Visual Studio will be 
fun in that.

I have bsAniPic, a Qt picture viewer using the same API as qtpov. I 
wrote and packaged that on Windows.  I built it on Linux, but I failed 
in packaging it. I have built other c++ based .deb packages, but Qt is a 
bit of a beast.   I figure I'll really work that bit out once I have 
something worth showing in qtpov.

BTW, this is the colored editor:
http://www.buckosoft.com/qtpov/

-- 
dik

Post a reply to this message

Am 11.11.2017 um 21:15 schrieb dick balaska:
> On 11/11/2017 08:04 AM, clipka wrote:
> 
>> Uh... wait!
>> Unix binary?
>> If you go for Qt, then by all means please make sure the system in its
>> entirety is portable.
>> I'd presume that if you really go for separating the GUI from the
>> program that renders scenes, this means writing a new Qt-based instance
>> of the latter.
>>
> 
> A Qt based render engine? Why?  There is already a cross platform render
> engine. I want to leverage that as much as possible.
> What I'm doing is a separate source tree for qtpov. This is the gui.
> The gui launches povray (or povconsole.exe) and connects to it via a
> websocket. Then the gui can instruct povray to start a render and
> receive the 5 streams and in-progress graphics info.

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.

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.

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

Post a reply to this message

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

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

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