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

William Tracy escribió:
> -----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

William Tracy <wtr### [at] calpolyedu> wrote:

> PovClipse *does* look nice.
Thanks a lot ;-))

> My only concern is how friendly it is going
> to be for new users.

True, Eclipse has quite a bit to learn about, but it offers a great platform
in turn.

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

That's the lovely thing, you do not need the full-blown Eclipse platform at
all! The minimal thing you need is the Eclipse "Platform Runtime Binary"
edition. It's extremely easy to build a complete custom application using
the Eclipse platform and developed plug-ins. In fact this is what many
companies are doing right now: moving from their own self-written
application to the Eclipse platform, probably re-writing much of their
code.
This way it's still in the hand of the development team which Eclipse
version they support, there can be even complete OS-dependent installer for
the GIU application if necessary.
The plugin itself can not be deattached completely from Eclipse, they are
ways to much interweaved. The plugin is written *for* Eclipse, not *with*.

BTW, I would suggest splitting the renderer from the GUI application
completely, like mentioned by nemesis above. The one wanting to be a
"hardcore-hacker" can still use their vim, emacs or what-so-ever editor,
but and the one wanting support by a specialized, feature-rich editor
should be supported by a GUI application like PovClipse or QtPovEditor.

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

The project thing is extremely easy to understand and to use. You need just
a couple of clicks to set-up your project in the default manner.
There is also a tutorial describing it.
IMHO the new users should be "trained" to utilize well-proved design
patterns like projects. In fact this was a thing I always missed in the
actual POV version: structuring your scene code and preserving it. Yes, you
can do it yourself by putting everything in a folder and ZIP that, but there
is nothing appealing to you to do so.

- Wolf

Post a reply to this message

"Wolf" <nomail@nomail> wrote:
> BTW, I would suggest splitting the renderer from the GUI application
> completely, like mentioned by nemesis above. The one wanting to be a
> "hardcore-hacker" can still use their vim, emacs or what-so-ever editor,
> but and the one wanting support by a specialized, feature-rich editor
> should be supported by a GUI application like PovClipse or QtPovEditor.

BTW, I'm still to see the editor component of an IDE -- even Eclipse,
Netbeans or VS -- to be as "feature-rich" as vim or emacs.  No, just
similar keybinbings for a given subset of the functionality isn't enough...

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> "Wolf" <nomail@nomail> wrote:
> > BTW, I would suggest splitting the renderer from the GUI application
> > completely, like mentioned by nemesis above. The one wanting to be a
> > "hardcore-hacker" can still use their vim, emacs or what-so-ever editor,
> > but and the one wanting support by a specialized, feature-rich editor
> > should be supported by a GUI application like PovClipse or QtPovEditor.
>
> BTW, I'm still to see the editor component of an IDE -- even Eclipse,
> Netbeans or VS -- to be as "feature-rich" as vim or emacs.  No, just
> similar keybinbings for a given subset of the functionality isn't enough...

I'm not going to comment this as I do not want to start another
"what-is-the-best-editor-out-there" discussion.
All I was saying is that there are people like you, using generic editors
like vim or emacs, and people like me, using specialized editors like
PovClipse to edit the POV SDL code, and let's support both.

- Wolf

Post a reply to this message

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

Wolf wrote:
> That's the lovely thing, you do not need the full-blown Eclipse platform at
> all! The minimal thing you need is the Eclipse "Platform Runtime Binary"
> edition.

That's very good to hear.

> BTW, I would suggest splitting the renderer from the GUI application
> completely, like mentioned by nemesis above.

That's increasingly sounding like the way to go.

> The project thing is extremely easy to understand and to use. You need just
> a couple of clicks to set-up your project in the default manner.

You'd be surprised by just how much that can trip up first-time users.
Just a few weeks ago I watched much confusion when a bunch of students
were expected to use Visual Studio for an assignment the first time
(including myself...why would I need VS when I have vim?). I heard lots
of people asking "what was that menu that he clicked?".

A process that should have been as simple as "vim <filename>" turned
into a half-dozen mouse clicks (file -> new project, select "Console
application", select next, go to properties, unselect "precompiled
headers", and so on).

Of course, part of the problem is that what *should* have been printed
on some handout, the instructor just did on a big screen and expected us
to follow along. Invariably, students fell behind and got lost.

Now, in the Unix world, the people who don't like projects will just
wander off and use vim (or emacs, or pico (eww), or ed, or...). However,
I'm still worried about turning away new users in Windows/Mac. The
concept of a "project" is going to be completely alien to people coming
from 3DS, or Photoshop, or whatever. They're going to have enough
trouble adjusting to the concept of SDL as it is.

I'm asking for a stupid-easy way to hop in, create or open a stand-alone
scene file, and render it. (And no, as far as I am concerned, a
pre-populated sample project isn't enough.) We don't need to give up the
projects feature, but I want a way to bypass it.

Think of it as some scratchboard feature for transient test code that
just doesn't deserve the overhead of creating a full-blown project.

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

You know you've been raytracing too long when even though you've
explained raytracing to them, your family doesn't really understand what
you're talking about, and they wonder why you won't just admit you took
those pictures with a camera.
    -- Jeff Lee
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHB76JcCmTzQ++ZncRAm9gAKCQnLE7kwVxxL/0JD7+azoh0ls94QCgkSw+
OGfi5tovmtZSsXCxJ94GdCA=
=64wm
-----END PGP SIGNATURE-----

Post a reply to this message

nemesis escribió:
>> 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.

When and if I make my own Java-based GUI app, I will probably use SWT. I 
really prefer having native widgets instead of "looks and feels like it 
but not quite", ie. Swing.

Azureus uses SWT, first Java app I saw that actually looks like 
everything else on my system.

Post a reply to this message

William Tracy <wtr### [at] calpolyedu> wrote:
> Now, in the Unix world, the people who don't like projects will just
> wander off and use vim (or emacs, or pico (eww), or ed, or...)

such people are still working on projects, on file at a time.  Or multiple
files, if you load a session file.

but I recon wizard-based templated makefile making is a Windows thing,
luckly...

Post a reply to this message

nemesis escribió:
> William Tracy <wtr### [at] calpolyedu> wrote:
>> Now, in the Unix world, the people who don't like projects will just
>> wander off and use vim (or emacs, or pico (eww), or ed, or...)
> 
> such people are still working on projects, on file at a time.  Or multiple
> files, if you load a session file.

Vim can split windows and show multiple files. At least on the GUI 
version, you can have *tabs* too.

I don't know anything about emacs.

Post a reply to this message