Hello,

I am looking for feedback:

This documents is to explain most issues regarding a proposal for new,
additional hooks to significantly better abstract the POV-Ray 4.0 core code
from outside, platform specific implementation details. The goal is a much
more powerful connection with Graphical User Interfaces. These hooks offer
an optional way to specify the render options without a command line and
control rendering as well as replacements and additions for the text stream
based input and output.

Up to version 3.5 POV-Ray only allowed text output and the main control
worked through the command line. Since version 3.0 two more powerful GUI
platforms - Windows and Mac OS - provide text editors but little abstraction
of the command line. However, both platforms surely present the main part of
the POV-Ray users today and a command line environment is no longer state of
the art. Especially Integrated Development Environment applications outline
a reasonable way to move traditionally command line driven programs like
compilers into the GUI age. However, providing IDE like features without
extensive support from the backend, the POV-Ray platform independent core
code, is very hard and resulted in errors and a (today) rather primitive
user interface designs. These new hooks will ease the creation of GUIs on
other platforms as well.

The hooks are designed to be very flexible and extensible. They will allow
future changes in the core code without breaking platform specific code or
forcing changes in it. It can simply ignore the additional information and
immediate changes in platform specific code of all platforms if some hooks
are changed can be avoided in these areas.

In addition, the information about the current hooks is very limited and
some documentation would be helpful for both sides, the GUI as well as the
core code developers, in order to prevent breaking old code by new changes.
So there needs to be a document which contains the details of the POVOC&SS
functions, changes required in each platform specific code and composition
of the messages. It could be used as base for some kind of introduction for
those willing to port POV-Ray to unsupported platforms. With the constantly
increasing complexity of the hooks and other interface functions this has
become a more and more difficult task.

The POV-Ray Output Control & Streaming System (POVOC&SS) is a solution to
the command line and text input and output limitations for GUI systems. It
offers a very easy to extend control mechanism for POV-Ray. Existing command
line driven POV-Ray versions will only need little adjustment while the GUI
platforms may need (more) extensive changes in order to make use of the
newly available features and options. However, nearly full backward
compatibility is provided so GUI platforms do not need to be adapted
immediately.

The current test implementation uses linked lists and some automatically
resized arrays. This is not fast, but speed is not a major design goal,
flexibility is. There is no point to increase speed in most parts, i.e. it
does not matter (much) if an error message output takes 0.1 millisecond or
10 milliseconds.

Comments?

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 
> [...] The goal is a much
> more powerful connection with Graphical User Interfaces. These hooks offer
> an optional way to specify the render options without a command line and
> control rendering as well as replacements and additions for the text stream
> based input and output.

Hmm, sounds interesting, could you give a few examples what would be
possible with this system that does not work with current POV?  Your text
contains quite some information about principal technical aspects but not
about what things will be actually controlled with that 'POVOC&SS'.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Mon, 14 Oct 2002 17:47:23 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> Comments?

Interesting reading. Nice opening for "more opened development" model. I have
to reread and reconsider carefully this whole statement. BTW: are there any
decision about GUI itself ? Similiar to those from 3.5 ?

ABX

Post a reply to this message

In article <qaqlqu0vj236nmug0tljdt7bhl3269fhst@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> BTW: are there any decision about GUI itself ? Similiar to those from 
> 3.5 ?

I'm not sure what your question is. The GUI itself is very platform 
dependant, and will probably remain that way. There are cross-platform 
frameworks, but those are pretty much equally bad on all platforms. ;-)
There will probably be similarities because they are designed to do the 
same thing, and ideas will be shared, but I doubt there will be anything 
like a standardized interface...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

On Mon, 14 Oct 2002 12:54:47 -0400, Christopher James Huff <chr### [at] maccom>
wrote:
> > BTW: are there any decision about GUI itself ? Similiar to those from 
> > 3.5 ?
>
> I'm not sure what your question is. The GUI itself is very platform 
> dependant, and will probably remain that way. There are cross-platform 
> frameworks, but those are pretty much equally bad on all platforms. ;-)
> There will probably be similarities because they are designed to do the 
> same thing, and ideas will be shared, but I doubt there will be anything 
> like a standardized interface...

I did not wrote "standarized" anywhere. I'm just wondering if codemax editor
would be continued in case of Win. But I understand my question is asked in
wrong time. There is no place for GUI decision right now. Anyway if you are
talking about "standardized interface" I'm thinking about making integrated
IDE for recently updated TVision (http://tvision.sf.net). Day after day it is
more portable and works with many compilers and could be nice optional layer
for many platforms. But I have not tested it yet. Just remember flexibility
from days of Borland ruling.

ABX

Post a reply to this message

Christopher James Huff wrote:

 > I'm not sure what your question is. The GUI itself is very platform
 > dependant, and will probably remain that way. There are
 > cross-platform frameworks, but those are pretty much equally bad on
 > all platforms. ;-) There will probably be similarities because they
 > are designed to do the same thing, and ideas will be shared, but I
 > doubt there will be anything like a standardized interface...
 >
Why not? Why not to implement cross-platform UI by using some 
(scriping??) language? I guess suppirting Windows/Linux/Unix/MacOS 
should be sufficient and there is quite a number of tools for such task: 
Tk/Tcl (or whatever it was called, never can't remember it :-), Python 
(Yea, I know, that some here
hate Python, but Pyvon seems to be nice step in direction of 
cross-platformness), Java with JNI for interface with POV-Ray core etc.

Performance of UI shouldn't be problem.

Post a reply to this message

In article <qaqlqu0vj236nmug0tljdt7bhl3269fhst@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> Interesting reading. Nice opening for "more opened development" model. I have
> to reread and reconsider carefully this whole statement. BTW: are there any
> decision about GUI itself ? Similiar to those from 3.5 ?

Well, for a GUI the stuff that is available as part of Mozilla looks very
interesting.  Maybe increasing the level of abstraction and then just
running POV-Ray as a backend to a webbrowser might be sufficient.  After
all, there are plenty of editors out there, so no need for a dedicated
GUI...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3DA### [at] starmanee> , Vahur Krouverk 
<vkr### [at] starmanee>  wrote:

> Why not? Why not to implement cross-platform UI by using some
> (scriping??) language? I guess suppirting Windows/Linux/Unix/MacOS
> should be sufficient and there is quite a number of tools for such task:
> Tk/Tcl (or whatever it was called, never can't remember it :-), Python
> (Yea, I know, that some here
> hate Python, but Pyvon seems to be nice step in direction of
> cross-platformness), Java with JNI for interface with POV-Ray core etc.

Well, as far as a scripting language for 4.0 we have been considering to
allow functions written in Perl or maybe Scheme would be a good idea.  That
would make all those people happy who don't like the current scripting
capabilities.  And users could extend the GUI this way from inside POV-Ray
scene files.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3DA### [at] starmanee>,
 Vahur Krouverk <vkr### [at] starmanee> wrote:

> Why not? Why not to implement cross-platform UI by using some 
> (scriping??) language? I guess suppirting Windows/Linux/Unix/MacOS 
> should be sufficient and there is quite a number of tools for such task: 
> Tk/Tcl (or whatever it was called, never can't remember it :-), Python 
> (Yea, I know, that some here hate Python, but Pyvon seems to be nice 
> step in direction of cross-platformness), Java with JNI for interface 
> with POV-Ray core etc.

I covered that...the results are usually just horrible. Tune things to 
look good on one platform, and it looks awful on all others...different 
interface conventions, different look and feel, etc...you end up having 
to make platform-specific versions anyway.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <3DAAEAD0.B14A350B@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> Hmm, sounds interesting, could you give a few examples what would be
> possible with this system that does not work with current POV?  Your text
> contains quite some information about principal technical aspects but not
> about what things will be actually controlled with that 'POVOC&SS'.

Well, assuming some classes like below, one could remove user interface
dependincies from the core code and just allow overloading of a few classes
to transmit data...

    Thorsten

*******************

class Container
{
 public:
  Container();
  virtual ~Container();
  DataType DataType();
  long Size();
};

class List : public Container, public list<Container>
{
 public:
  List();
  List(List source);
  virtual ~List();
  void Append(Container item);
  void GetNth(int index, Container item);
  void SetNth(int index, Container item);
  void RemoveNth(int index);
  void Clear();
};

class Object : public Container, public map<DataType,Container>
{
 public:
  Object(DataType objclass);
  Object(Object convert);
  Object(Object source);
  ~Object();
  void Get(Container attr, DataType key);
  void Set(Container attr, DataType key);
  void Remove(DataType key);
  void Exist(DataType key);
};

class Status : public Object
{
 public:
  Status(string statusmsg);
  ~Status();
};

class Statistics : public Object
{
 public:
  Status(string statusmsg);
  ~Status();
};

class Warning : public Object
{
 public:
  Status(string statusmsg);
  ~Status();
};

class Error : public Object
{
 public:
  Status(string statusmsg);
  ~Status();
};



____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message