PLIB

On Mon, 18 Mar 2002, john.fay@... (Fay John F Contr AAC/WMG)
wrote:
> Date: Mon, 18 Mar 2002 16:49:46 -0600
> To: plib-devel@...
> From: john.fay@... (Fay John F Contr AAC/WMG)
> Subject: RE: [Plib-devel] PLIB on GLFW
>
> As another pretty heavy PUI user I really don't care whether it depends
> on GLUT or not.

As a heavy PUI user you should care ! Maybe you'd like to use PUI in an
application that creates windows using, say, SDL in the future ...


> I have a standing preference for not having one thing depend
> on another, though, so I will agree with Sebastian.

Yes.

If it were only that the library itself depends on the GLUT library - but
currently, without that non-GLUT "hack" (it's really a hack and no real
solution), PUI *requires* you to manage your windows (at least the ones
you'd like to use it in) using GLUT. I wonder how many people could not use
PUI in the past when they wanted to do so due to that fact ...


-Sebastian

I'm not sure I follow the reasoning here.  First I need to make clear that
my knowledge in this subject is very shallow:  I use PUI with GLUT and
nothing else.  (That explains why I really don't care about the dependency;
I don't know about any other windowing systems.)

But how does PUI require the user to manage his windows with GLUT?  I
thought the only dependence was some fonts that I was able to hack out.

Frankly, I do think that removing GLUT from PUI would be a worthwhile thing
just on general principles.  If we could do it without breaking existing
applications, I would even put some work into it.

John F. Fay
john.fay@...

"Et verbum caro factum est, et habitavit in nobis; et vidimus gloriam eius."



-----Original Message-----
From: Sebastian Ude [mailto:ude@...]
Sent: Monday, March 18, 2002 6:25 PM
To: plib-devel@...
Subject: RE: [Plib-devel] PLIB on GLFW




On Mon, 18 Mar 2002, john.fay@... (Fay John F Contr AAC/WMG)
wrote:
> Date: Mon, 18 Mar 2002 16:49:46 -0600
> To: plib-devel@...
> From: john.fay@... (Fay John F Contr AAC/WMG)
> Subject: RE: [Plib-devel] PLIB on GLFW
>
> As another pretty heavy PUI user I really don't care whether it depends
> on GLUT or not.

As a heavy PUI user you should care ! Maybe you'd like to use PUI in an
application that creates windows using, say, SDL in the future ...


> I have a standing preference for not having one thing depend
> on another, though, so I will agree with Sebastian.

Yes.

If it were only that the library itself depends on the GLUT library - but
currently, without that non-GLUT "hack" (it's really a hack and no real
solution), PUI *requires* you to manage your windows (at least the ones
you'd like to use it in) using GLUT. I wonder how many people could not use
PUI in the past when they wanted to do so due to that fact ...


-Sebastian

_______________________________________________
plib-devel mailing list
plib-devel@...
https://lists.sourceforge.net/lists/listinfo/plib-devel

On Tue, 19 Mar 2002, john.fay@... (Fay John F Contr AAC/WMG)
wrote:
> Date: Tue, 19 Mar 2002 08:17:52 -0600
> To: plib-devel@...
> From: john.fay@... (Fay John F Contr AAC/WMG)
> Subject: RE: [Plib-devel] PLIB on GLFW
>
> I'm not sure I follow the reasoning here.  First I need to make clear
> that my knowledge in this subject is very shallow:  I use PUI with GLUT
> and nothing else.  (That explains why I really don't care about the
> dependency; I don't know about any other windowing systems.)
>
> But how does PUI require the user to manage his windows with GLUT?  I
> thought the only dependence was some fonts that I was able to hack out.

It currently really *does* require the user to manage his windows with GLUT
unless he uses that PU_NOT_USING_GLUT hack.

The problem are not only OpenGL fonts but also how to retrieve window
dimensions, which PUI needs to set up the OpenGL viewport, to keep
puMenuBar widgets at the top of a window and for many other things.

Furthermore, I consider the current modification only as a hack and not as
a solution. Think about it - it requires that some textured fonts are
always present, that means that a programmer will always have to distribute
them along with his application. It does not work with multiple windows
either.


> Frankly, I do think that removing GLUT from PUI would be a worthwhile
> thing just on general principles

That one is not only about "general principles", but about the usability of
PUI. We all know that you are a probably the heaviest PUI user around. If
somebody would come up to you and say "Uhm ... John, I need a set of basic
UI widgets for OpenGL to integrate into my application ...", you'd surely
mentition PUI and ask the person "You do use GLUT to create your windows,
don't you ?" - and what if the person would tell you that he uses something
else but would like to use PUI in multiple windows nevertheless ?

That limitation is brain-dead, but difficult to remove ...


> If we could do it without breaking existing applications, I would even
> put some work into it.

Tell me how to do it without breaking existing applications and I'll be
working on it immediately !

However, I can't think of a way to do it without breaking existing
applications. Getting some built-in fonts isn't a problem. But the
retrieval of the window size is. Either we must have the user to supply us
with window dimensions, or we would have to look at as many window systems
as possible and find out how to retrieve window sizes, but either way, we
would require applications to supply is with some information (either
window sizes or window structures of the appropiate system) that they do
not hand over to us currently. Hence, we would break them.


Quick question for the list: GLUI depends on GLUT too, doesn't it ?


- Sebastian

Sebastian Ude wrote:

> It currently really *does* require the user to manage his windows with GLUT
> unless he uses that PU_NOT_USING_GLUT hack.

There are three issues here (as far as I can tell).

1) The dependancy on two GLUT calls to read the window width and height.
   I don't see an easy way to get those two numbers in a way that's
   independent of the underlying GLUT-like window handling layer.  We
   could make the end user application tell us the numbers - but not if
   we want to keep reverse compatibility with existing applications.

   Yukky.

   I think it may be time to break reverse compatibility and simply
   demand that the application tell us the window dimensions by calling
   a puResize(w,h) function.

2) Fonts.  This is a problem if programs don't use FNT library texture
   fonts.  The simple fix for this is to steal the freeglut fonts and
   associated rendering code and dump it into PUI.  If someone wants
   to volunteer to do that, I'd be most grateful.

3) Windowing.  It has been reported that PUI doesn't work with multiple
   windows unless GLUT is present.  I don't see how that can be true.
   What's more likely is that whatever was tested used texture fonts
   but forgot to tell GLX to share texture maps between rendering
   contexts.  That's the default behaviour in GLUT - but possibly not
   in some other libraries.

   If that's the case then this isn't a PUI problem - but we might want
   to devise some way to detect whether the font textures are valid in
   the current graphics context and complain if they aren't.  I have
   no idea how to do that.

   Someone needs to test this hypothesis.

> > Frankly, I do think that removing GLUT from PUI would be a worthwhile
> > thing just on general principles

I disagree.

SDL is becoming *VERY* popular - and an inability to interoperate with it
is "A Bad Thing".
 
> That limitation is brain-dead, but difficult to remove ...

Yes.  The initial dependancy on GLUT for window dimensions is entirely my
fault and could trivially have been avoided if I'd only thought about it
at the time...now it's going to be painful to remove the limitation since
every single PUI application has to be changed to make it go away.

> > If we could do it without breaking existing applications, I would even
> > put some work into it.
> 
> Tell me how to do it without breaking existing applications and I'll be
> working on it immediately !

Exactly.
 
> However, I can't think of a way to do it without breaking existing
> applications. Getting some built-in fonts isn't a problem. But the
> retrieval of the window size is. Either we must have the user to supply us
> with window dimensions...

...which would be fine if I could think of a way to do it without breaking
compatibility.

> ...or we would have to look at as many window systems
> as possible and find out how to retrieve window sizes...

I can't see a way to do that cleanly for Xfree.

> but either way, we
> would require applications to supply is with some information (either
> window sizes or window structures of the appropiate system) that they do
> not hand over to us currently. Hence, we would break them.

Well, there is *one* other way.

We could make a new library called libplibpu_noGLUT.a (or hopefully something
more elegant) which breaks reverse compatibility - and keep libplibpu.a for
existing applications.  We'd tell everyone that libplibpu.a will 'go away'
in a year or so and to convert to the new API (and link to the new library)
ASAP.

The two libraries would use all the same '.o' files - except for one which
would contain the hack to allow old PUI programs not to supply the window
sizes.

> Quick question for the list: GLUI depends on GLUT too, doesn't it ?

Dunno - I kinda doubt it - but it's never been terribly popular so I
don't think it matters.
 
----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@...>   WorkMail: <sjbaker@...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

On Mon, 25 Mar 2002, sjbaker1@... (Steve Baker) wrote:
> Date: Mon, 25 Mar 2002 16:46:44 -0600
> To: ude@...
> From: sjbaker1@... (Steve Baker)
> CC: plib-devel@...
> Reply-To: sjbaker1@...
> Subject: Re: [Plib-devel] PLIB on GLFW


> 3) Windowing.  It has been reported that PUI doesn't work with multiple
>    windows unless GLUT is present.  I don't see how that can be true.
>    What's more likely is that whatever was tested used texture fonts
>    but forgot to tell GLX to share texture maps between rendering
>    contexts.  That's the default behaviour in GLUT - but possibly not
>    in some other libraries.

No, Steve - that's *not* the point. I do realize that if texture maps are
not shared between rendering context, one will have to re-load the textured
font for each and every window ...

The problem is that when puDisplay () is called, we have to know whether
the window we are rendering in is the same window that a widget is supposed
to reside in. There is a check that looks like this at the top of each
widget's draw () member function:

if ( window != puGetWindow () )
  return ;

Without that check, widgets would render into windows in which they do not
belong.

Without GLUT, however, we currently do not give numbers to windows and "int
puGetWindow ()" will always return 0. Because each widget holds the
information to reside in window 0, the above check will always be true.


> > > Frankly, I do think that removing GLUT from PUI would be a
> > > worthwhile thing just on general principles
>
> I disagree.
>
> SDL is becoming *VERY* popular - and an inability to interoperate
> with it is "A Bad Thing".

Err ... Steve, John just said breaking from GLUT dependancy and being able
to interoperate with any window system would be a "worthwhile thing" ...


> > ...or we would have to look at as many window systems
> > as possible and find out how to retrieve window sizes...
>
> I can't see a way to do that cleanly for Xfree.

Neither can I for any other window system, AS LONG as we do not have any
knowledge on how the user constructed the window. Since we would require
the user to provide us with this information, he could supply us with
window dimensions directly ...


> Well, there is *one* other way.
>
> We could make a new library called libplibpu_noGLUT.a (or hopefully
> something more elegant) which breaks reverse compatibility - and keep
> libplibpu.a for existing applications.  We'd tell everyone that
> libplibpu.a will 'go away' n a year or so and to convert to the new API
> (and link to the new library) ASAP.

Yeah, we could do that. It might go away with PLIB 2.0 then ...


> > Quick question for the list: GLUI depends on GLUT too, doesn't it ?
>
> Dunno - I kinda doubt it - but it's never been terribly popular so I
> don't think it matters.

But it basically does the same thing as PUI does and it would be intresting
to know how they solved the problem. But I just looked at their website:

[...] It is window-system independent, relying on GLUT to handle [...]
window [...] management. [...] Complete integration with GLUT toolkit.
[...]

So they seem to rely on GLUT, too ...


- Sebastian