Radiance cross-platform issues & GUIs, oh my!

I've been looking into this. I'm planning a thesis involving Radiance, so I think I'll have some time to put into this. (I am probably rehashing older discussions here; forgive me.)

I'm looking at a cross-platform set of build scripts, which I think are plausible now that we're down to three or four platforms, though I'm going to carefully avoid the problem of building, for instance, X windows components on Microsoft Windows. These proposed scripts are intended to be in addition to current scripts rather than replacements. I think I can make these simple and effective; we'll have to see how well I do.

Perhaps I can embed most of the the existing commands in C++ classes. Ideally, all the current code would be left unchanged; this would also be "in addition to," rather than "instead of". The classes could then be invoked from conventional cross-platform GUI code. I am looking at WxWidgets for the GUI, but in principle any GUI classes or functions could be used--even native Windows or Mac classes.

One area where I think Radiance might reap some benefit from changes in the core code--though if the community doesn't want to go this way I'll leave it be--would be to integrate some shell functionality in the processing of the Radiance Scene Description Language (RSDL?) Perhaps we can imagine an rdsl_open() routine which contains a simple non-interactive shell and implements pipes, simple argument quoting, xform, tmesh2rad, gen*, and perhaps a few other operations as built-ins. Anything complicated and shellish rdsl_open() would forward to the system shell, with the understanding that this makes the RDSL code system-dependent. This would enormously simplify Microsoft porting, and might even lead to speed improvements in oconv, since it would trade memory for process creation. Memory is cheap these days; probably cheaper than Unix processes and probably much cheaper than MS processes.

What do people think?

Randolph

Hi Randolph,

Just a quick comment on your idea of implementing a mini-shell within Radiance's scene description language -- I assume you mean this to take care of the "!command" lines in the input, correct? In any case, you should not underestimate the difficulties in converting even a small number of command-line tools into library calls, as the general assumption of separate process spaces means the use of i/o and globals is a big mess to clean up. Personally, I can't imagine it being worth the effort, as there would be no real gain in functionality, and worse maintenance headaches down the line. Taking a system like Radiance, which is based on the Unix toolbox model, and turning it into a set of library routines, is not a weekend task. Do you know of any examples of systems that have been successfully converted in this way? I'd be interested to hear of any.

I'm curious how a system like Radiance could be fit into a set of C++ classes. There must be a way, and I'm not saying it's a bad idea, but the general toolbox approach is standardized on a (preferably small) set of stream data formats. I guess you would try to hook the output of one object into the input of another, or something like that. It seems feasible, at least in principle.

Anyone else have thoughts on this?

-Greg

···

From: R Fritz <[email protected]>
Date: July 7, 2008 10:24:21 PM PDT

I've been looking into this. I'm planning a thesis involving Radiance, so I think I'll have some time to put into this. (I am probably rehashing older discussions here; forgive me.)

I'm looking at a cross-platform set of build scripts, which I think are plausible now that we're down to three or four platforms, though I'm going to carefully avoid the problem of building, for instance, X windows components on Microsoft Windows. These proposed scripts are intended to be in addition to current scripts rather than replacements. I think I can make these simple and effective; we'll have to see how well I do.

Perhaps I can embed most of the the existing commands in C++ classes. Ideally, all the current code would be left unchanged; this would also be "in addition to," rather than "instead of". The classes could then be invoked from conventional cross-platform GUI code. I am looking at WxWidgets for the GUI, but in principle any GUI classes or functions could be used--even native Windows or Mac classes.

One area where I think Radiance might reap some benefit from changes in the core code--though if the community doesn't want to go this way I'll leave it be--would be to integrate some shell functionality in the processing of the Radiance Scene Description Language (RSDL?) Perhaps we can imagine an rdsl_open() routine which contains a simple non-interactive shell and implements pipes, simple argument quoting, xform, tmesh2rad, gen*, and perhaps a few other operations as built-ins. Anything complicated and shellish rdsl_open() would forward to the system shell, with the understanding that this makes the RDSL code system-dependent. This would enormously simplify Microsoft porting, and might even lead to speed improvements in oconv, since it would trade memory for process creation. Memory is cheap these days; probably cheaper than Unix processes and probably much cheaper than MS processes.

What do people think?

Randolph

Hi,

Perhaps I can embed most of the the existing commands in C++ classes.

Not sure if that's the best way to go, although I didn't look deep into
the code yet, I could imagine that it would make sense to create one (or
probaly several) shared libraries, which could be used instead of
embedding commands.

Ideally, all the current code would be left unchanged; this would also
be "in addition to," rather than "instead of". The classes could then be
invoked from conventional cross-platform GUI code. I am looking at
WxWidgets for the GUI, but in principle any GUI classes or functions
could be used--even native Windows or Mac classes.

if you're looking for c++, platform-compatible toolkits, I'd suggest to
use QT4 instead of wxwidgets. QT4 is nice to work with, and more
important, it has - in my opinion - a much more reliable upstream and
less bugs than wx. QT4 supports all important platforms - including OSX
and Windows, and supports OpenGL out of the box.

Cheers,

Bernd

···

--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79

Qt's great, but it doesn't support Python, my preferred environment, when I don't need great speed. Sigh. What I've seen of WxWidgets doesn't thrill me, either, but it works in a broad range of environments. There aren't really any good FOSS solutions that I've seen, and the ones that aren't FOSS are too expensive to consider.

Oh, well. Maybe this is less of an issue than I think; right now I'm still struggling to build shared libraries; I'll know more when I start doing serious UI work.

Randolph

···

On Jul 8, 2008, at 1:22 PM, Bernd Zeimetz wrote:

Hi,

Perhaps I can embed most of the the existing commands in C++ classes.

Not sure if that's the best way to go, although I didn't look deep into
the code yet, I could imagine that it would make sense to create one (or
probaly several) shared libraries, which could be used instead of
embedding commands.

Ideally, all the current code would be left unchanged; this would also
be "in addition to," rather than "instead of". The classes could then be
invoked from conventional cross-platform GUI code. I am looking at
WxWidgets for the GUI, but in principle any GUI classes or functions
could be used--even native Windows or Mac classes.

if you're looking for c++, platform-compatible toolkits, I'd suggest to
use QT4 instead of wxwidgets. QT4 is nice to work with, and more
important, it has - in my opinion - a much more reliable upstream and
less bugs than wx. QT4 supports all important platforms - including OSX
and Windows, and supports OpenGL out of the box.

Cheers,

Bernd

--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

Not sure if that's the best way to go, although I didn't look deep into
the code yet, I could imagine that it would make sense to create one (or
probaly several) shared libraries, which could be used instead of
embedding commands.

I'm aiming at shared libraries wrapped in C++ classes, actually. I've been digging in the code and it's written so as to use Unix IPC rather than shared libraries. It's elegant, damnably hard to port, and seems central to the design of Radiance, hence this approach. My idea, right now--I may change my idea--is to provide classes which cover the same ground and use most of the same code as the existing commands, which can then be easily invoked in a GUI environment. Right now, though, I am still struggling with Mac shared library system.

Randolph

R Fritz wrote:

Qt's great, but it doesn't support Python,

Uh, it supports python pretty well, I'm just not sure how plat-form
compatible the bindings are - but as they're only bindings to the QT
libraries I'd expect that they work on all platforms which are supported
by python and QT. http://www.riverbankcomputing.co.uk/software/pyqt/ is
what you want to look at :slight_smile:

0 bzed@think:~$ apt-cache show python-qt4
Package: python-qt4
Priority: optional
Section: python
Installed-Size: 22432
Maintainer: Debian Python Modules Team
<[email protected]>
Architecture: amd64
Version: 4.4.2-4
Provides: python2.4-qt4, python2.5-qt4
Depends: libc6 (>= 2.7-1), libgcc1 (>= 1:4.1.1), libqt4-assistant (>=
4.4.0), libqt4-designer (>= 4.4.0), libqt4-help (>= 4.4.0),
libqt4-network (>= 4.4.0), libqt4-script (>= 4.4.0), libqt4-svg (>=
4.4.0), libqt4-test (>= 4.4.0), libqt4-webkit (>= 4.4.0), libqt4-xml (>=
4.4.0), libqt4-xmlpatterns (>= 4.4.0), libqtcore4 (>= 4.4.0), libqtgui4
(>= 4.4.0), libstdc++6 (>= 4.1.1), python2.5 (>= 2.5), python (<< 2.6),
python (>= 2.4), python-central (>= 0.6.7), python-sip4 (>= 4.7.6),
python-sip4 (<< 4.8), python-elementtree, python-qt4-common
Suggests: python-qt4-dbg
Filename: pool/main/p/python-qt4/python-qt4_4.4.2-4_amd64.deb
Size: 5706516
MD5sum: 2b7275f74e76a15110593e2b0ea93f2d
SHA1: ab36639b61f6fa94eebf7612c45cabeb05e7c926
SHA256: 512bae33558d8191e56b88fb43dbf147ca6abaf28124d0d6ad3eb3e327481994
Description: Python bindings for Qt4
PyQt4 exposes the Qt4 API to Python. The following modules are supported:
  * QtCore
  * QtGui
  * QtNetwork
  * QtXml
  * QtScript
  * QtSvg
  * QtTest
  * QtAssistant
  * QtWebKit
  * QtOpenGL (in python-qt4-gl)
  * QtSql (in python-qt4-sql)
Homepage: http://www.riverbankcomputing.co.uk/software/pyqt/
Python-Version: 2.4, 2.5
Tag: devel::lang:python, devel::ui-builder, uitoolkit::qt

Cheers,

Bernd

···

--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79