Re: New directions with much less objectives (Was Re: Comments?)

[Adrian Ratnapala <s369625@student.uq.edu.au>]

On Sun, 28 Feb 1999, Peter Breitling wrote:

> > Adrian Ratnapala wrote:
> > >Can you use OpenGL and GGI together?
> > Yes.  Mesa once even had a GGI target in its main distribution, but
> > that is badly outdated.
> 
> Mesa on the one hand is a very nice software solution for OpenGL but
> still lacks the most important thing with OpenGL: Hardware acceleration.
> And if  Mesa uses hardware acceleration lets say with next release of
> Xfree including GLX stuff then it will not be based no the pixel
> orientated GGI.
Well, actually such shortcommings are best fixed by the Mesa and XFree
teams, but I think we are acutally in agreement.  See below.
  
> Q: I have an existing OpenGL-App but the Open-Window routine is still
> based on Windows. How can i make this portable?
> 
> A: Use PP! With PP you can also add more functionality like Sound,
> Networking, Input etc.
>
Right!  This is exctly what we are thinking.  If PPlay for now chooses
to use GGI under it, that is not an issue for the end programmer (unless
he want's it to be).
 
> 
> Q: I wrote a QT-App (or tcl/Tk or Gtk) and want to have sound output. QT
> doesn't provide this but my app still needs to work with Windows and
> X11.
> 
> A: Use PP.
> 
OK, actually we hadn't thought of this use, but it illustrates why
the sound needs to be usably independently of graphics.  I mean
if you rewriting the sort of programm for which you would use 
Qt, then you are unlikely to want pg2d.

> 
> What i mean is following: Lets say we have a class ppiInput that
> represents keyboard (or mouse or joystick) input and where you can
> receive messages about input events in any way. Instead of instancing it
> once or using one global instance that represents the hardware itself i
> would initialize it with a Drawable that can be displayed (i think a
> ppgDevice in your hierarchy). So this means the input is always
> initialized with drawables (things on screen). 
> 
> And in practice under a windowing system then always that drawable will
> receive input where the focus is. In a DOS application (or lets say in a
> game console since DOS is dead) then of couse maybe we have only one
> drawable that is the screen itself and we can initialize the input with
> that global drawable.
> 
Right... I think what you are talking about comes under the perview
of the minimal GUI we have design, in such a case events can be received
by windows.

> 
> I think in the development stage it is best to use perceps or doxygen as
> _the_ documentation tool. If you document your classes and methods in a
> grade that when it is converted to a HTML-reference sheet it is complete
> enough for experienced users to use PP, then we don't have to write
> other manuals in the first stage.
Agreed.

> 
> If you don't want me to start from scratch then i need an overview of
> what classes are in at the moment. In effect i would need the base
> classes and the concept itself. I.e.: lets start with the basic object
> functionality and the messaging system. That is important for every
> subpart of PP.


What I'll do is actually act on the item on my TODO list saying
"DOCUMENT!".  Excpect some perceps generated docs when I have time for
pg2d at least. PFile might not be able to do this because of the rewrite.


> 
> So what i am missing is not the arguing but an interesting discussion
> about the framework with all its classes methods, class-interaction and
> porting/efficiency issues. You are right that there should always be one
> resonsible who is in controversy questions actually deciding where to go
> in some cases. Sometimes wrong decisions are better than no decisions.
> 

OK, now I think I see where we were thinking differently.  When I said
we _do_ have an overall design, I mean it in very general terms, as
in we had decided what components PPlay should have, what (approximtely)
their functionality was to be and how they would interelate.  What you
are talking about is something more concrete, in terms of shared classes,
communiction mechanisms etc.

While PPlay will try to avoid such shared functionlity (and dependency)
where it can, I agree with you, more work needs to be done at this level.