-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So far, all the discussion about POV 4 has centered about SDL, so I
thought I'd bring up something different. We need variety. :-)

How is the Povray GUI code doing, both from a copyright/license
viewpoint, and from a code cleanliness standpoint? If it could stand a
significant re-write, would there be any interest in a new GUI written
on wxWidgets?

http://www.wxwidgets.org/

wxWidgets is a cross-platform GUI toolkit using native widgets written
in C++. (I'm open to other cross-platform toolkits as well--of the ones
that I know of, wxWidgets seems like the best match for POV.)

In one swoop, this would:

* Halve the size of the GUI codebase that needs maintenance, since
separate Windows and Mac code would no longer be needed.
* Ensure that the user interfaces are consistent across all platforms,
since they are all derived from the same code.
* For the first time, create a GUI for Linux/Unix, since wxWidgets
supports GTk+, and, apparently, Motif.

FWIW, this is something that I personally am a lot more comfortable
hacking on than the internals of the raytracer proper.

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you wonder which raytracer
God used.
    -- David Kraics
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBX5CcCmTzQ++ZncRAvDwAJ95fKPjBpSiuwe4+fnNSrL0qCWMiwCeMJtw
cOv9InlnLGsGxdE8RZI3Vus=
=u5Vu
-----END PGP SIGNATURE-----

Post a reply to this message

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> So far, all the discussion about POV 4 has centered about SDL, so I
> thought I'd bring up something different. We need variety. :-)
> 
> How is the Povray GUI code doing, both from a copyright/license
> viewpoint, and from a code cleanliness standpoint? If it could stand a
> significant re-write, would there be any interest in a new GUI written
> on wxWidgets?

 From pvengine.cpp:

NOTICE:
Much of this source code (all of pvengine.exe) should be considered on its last 
legs. The base code was originally written back in early 1995 (with some of the 
code even predating that), and targeted at Win32s under Windows 3.1. An 
additional constraint was a desire for the code to be able to be compiled on a 
DEC Alpha under NT for the Alpha using only a 'C' compiler, and for it to be 
able to run with or without the editor.

So I guess a rewrite of the GUI is indeed a good idea :)

Post a reply to this message

William Tracy wrote:
> How is the Povray GUI code doing, both from a copyright/license
> viewpoint, and from a code cleanliness standpoint? If it could stand a
> significant re-write, would there be any interest in a new GUI written
> on wxWidgets?

Significant effort has been expended in the new 3.7 codebase to provide a
OO-based interface to the renderer so as to make the introduction of a new
front-end (GUI or otherwise) a lot less difficult.

Put another way, it allows the developer to concentrate more on the
development of the UI itself without having to worry so much about the guts
of how POV works.

-- Chris

Post a reply to this message

I personally think that a new official POV editor is overdue.

For this reason I wrote PovClipse, which is a free Eclipse plugin for
editing SDL code, kicking of the renderer and view the rendered images
(just to mention a few things).

------------------------------------------------------------------------------
If there is interest by the POV-team I would hand over the project to
POV-ray.
------------------------------------------------------------------------------
But this is true *only* if it's going to be the *official* SDL editor. I put
lot's on work in it and I do not want to see it wasted.


Having said this, let me point out some PovClipse highlights:
* true platform independence through being a Eclipse plugin (Windows, Linux,
Mac, AIX, you name it. Wherever Eclipse is available PovClipse is it as
well)
* advanced, state-of the art editor featuring things like:
  + syntax highlighting
  + auto-completion
  + code templates
  + error indications (wiggle marks)
  + code folding
  + auto typing
  + code outline view
* specialized graphical editors for colors and color maps (the color-map one
is my favorite, check it out ;-))
* render launcher for kicking of POV-ray having GUI support for all POV-ray
INI file options
* project management by importing and exporting from/into archives
(zip/tar/tgz)
* supports POV-ray and MegaPOV
* built-in online help for:
  + PovClipse
  + POV-ray
  + MegaPOV
* context-sensitive jump into the POV-ray and MegaPOV help (the Eclipse
Shift+F2 thing)
* nearly all options are configurable using preference pages
* Multilanguage support:
  + english
  + german
  + french
  + spanish
  + portugueese

Please check out the PovClipse homepage (http://povclipse.sourceforge.net)
for more details.

-
Wolf

Post a reply to this message

Side note, while taking GUI :
Thierry Charles developed QTPOV
  http://qtpoveditor.sourceforge.net/
which, feature-wise, is a extremely good editor for POV-Ray.
Worth having a look at it.

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

PovClipse *does* look nice. My only concern is how friendly it is going
to be for new users.

Speaking as someone who has never written Eclipse plugins, how hard
would it to be to detangle it from Eclipse and have it run stand-alone?
Having the entire Eclipse SDK is kind of overkill. :-) Other than SWT
proper, I don't know how many of Eclipse's libraries can run
independently of the IDE.

Also, how hard would it be to make it not require the user to set up and
organize projects? The project concept is useful when you're developing
large pieces of software, and could be nice for managing scenes that
have lots and lots of include files. For most users just getting
started, though, I see it becoming just one more stumbling block. :-( It
would be nice to be able to just open up a .pov file and press "render".

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you have ever said "I
don't need no steenking modellers!!!"
    -- Stephan Ahonen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBmU1cCmTzQ++ZncRAuphAJ9OLG3gyozTac578y/L3qJZYcmTSQCgrrBL
pPgM5Zw3gC6AaAKyL+o8S6s=
=yRm7
-----END PGP SIGNATURE-----

Post a reply to this message

speaking as a technical Linux user, I don't care about GUIs, Xlib, GTK+,
Tcl... let alone Swing or Eclipse requiring a whole heavy, bloated and
redundant OS-wrapper (read Java).

I'm happy with vim, bash and povray's command-line visualization option.

so, see, everyone has their bias...

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

nemesis wrote:
> speaking as a technical Linux user, I don't care about GUIs, Xlib, GTK+,
> Tcl... let alone Swing or Eclipse requiring a whole heavy, bloated and
> redundant OS-wrapper (read Java).

I like the command-line interface, myself, but there is a (apparently
small) group of people that have been asking for a Linux GUI; if there
is an easy way to meet their needs, I see no reason not to. I also don't
 see a problem with keeping the CLI interface around in addition to a GUI.

I might also add that Eclipse does not use Swing, it uses SWT (which is
a bit more lightweight than Swing). In addition, Java programs written
against SWT can fairly easily be compiled to native code via GCJ (this
is what Fedora does for their Eclipse binaries), eliminating the
overhead of the JRE altogether. :-)

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you can draw things
quicker in POV-Ray than you can using a pencil and paper.
    -- Dylan Beattie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBuz5cCmTzQ++ZncRAtojAKChNZW/riceB1BxFM3Yt2SY29HPogCgg5FK
xcXQBGqamjaa3m810PeqwzM=
=QFgl
-----END PGP SIGNATURE-----

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I might add that there is some precedence here: MegaPOV distributes both
 GUI and CLI binaries in their Windows installer.

With a little foresight, it might even be feasible to do it with one
binary that accepts command line flags (e.g., povray --gui).

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you've tried to scan your
face for a texture.
    -- Quietly Watching
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBu6KcCmTzQ++ZncRArwaAJ4lVfGGrsOY7u4vAP0KGy5sjRr5JACeOJht
hXG3P3G90Ohqa56BoAkv4qU=
=MTeV
-----END PGP SIGNATURE-----

Post a reply to this message

William Tracy <wtr### [at] calpolyedu> wrote:
> I also don't
>  see a problem with keeping the CLI interface around in addition to a GUI.

It's the contrary:  I don't a reason to keeping a GUI around in a addition
to the povray renderer, which *is* a classical command-line
batch-processing program.

> I might also add that Eclipse does not use Swing, it uses SWT

I know, which is why I mentioned Eclipse:  you don't really use SWT other
than in Eclipse-based apps.

> (which is
> a bit more lightweight than Swing). In addition, Java programs written
> against SWT can fairly easily be compiled to native code via GCJ (this
> is what Fedora does for their Eclipse binaries), eliminating the
> overhead of the JRE altogether. :-)

except for the memory overhead and invariably requiring Eclipse to edit
source code.

Post a reply to this message