plib-devel

Re: [Plib-devel] path for PLIB

[Steve B. <sjb...@ai...>]

Christian Mayer wrote:
> 
> Steve Baker wrote:
> >
> > Christian Mayer wrote:
> >
> > > as the last SuSE (6.4) had PLIb at the wrong place (somewhere below
> > > /X11/) I was curious if anything had changed for the yet-to-come 7.0.
> > >
> > > But it seems that it's still in the wrong place :-(
> >
> > What version are they shipping?
> 
> They say that they'll ship 7.0 on the 21. August

Sorry - I mean't what version of PLIB!

> Their packet description at
> 
> http://www.suse.de/de/produkte/susesoft/linux/Pakete_prof/paket_plib.html
> 
> says (it's German):
> 
> Autor: Steve Baker <sjb...@ai...>
> Copyright: (C) LGPL
> Version: 1.1.11-41

Urgh!  Ancient history.
 

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] reading directories

[Steve B. <sjb...@ai...>]

> Dave McClurg wrote:
> 
> i added some functions for reading directories to "ul"

Cool!

> Steve- could you create a folder for me so i can add my test program to CVS?
> plib/examples/src/ul

I called it 'util' rather than 'ul' because the directories in that area
are named after the library name and not the function prefix.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] PUI questions

[Steve B. <sjb...@ai...>]

Wolfram Kuss wrote:
> 
> Steve wrote:
> 
> >    ppeDeleteMeLater ( this ) ;
>      ^^^
> 
> LOL.
> I see you are dialed into PPE, aren't you ;-) ?

Between PLIB, PUI and PPE - my brains are utterly scrambled!

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] path for PLIB

[<Va...@t-...>]

Steve Baker wrote:
> 
> Christian Mayer wrote:
> 
> > as the last SuSE (6.4) had PLIb at the wrong place (somewhere below
> > /X11/) I was curious if anything had changed for the yet-to-come 7.0.
> >
> > But it seems that it's still in the wrong place :-(
> 
> What version are they shipping?

They say that they'll ship 7.0 on the 21. August

Their packet description at

http://www.suse.de/de/produkte/susesoft/linux/Pakete_prof/paket_plib.html

says (it's German):

Autor: Steve Baker <sjb...@ai...> 
Copyright: (C) LGPL 
Version: 1.1.11-41 

Platzbedarf:

     /usr: 24 k 
     /usr/X11: 5489 k 
     Gesamtgröße: 5513 k 

[... Needed disk space:

/usr: 24 k
/usr/X11: 5489 k
Total: 5513 k]

> 
> > Shouldn't we talk to them about that?
> 
> I've talked to them before - they have this fixation that
> anything that *uses* X11 should be stored *inside* X11.
> 
> That's just plain silly IMHO - I use lots of other things
> too - but I don't expect to be stored inside their directory
> trees!
> 
>     "uses" != "is_a_part_of"

That's the same as with inheritance of C++ classes...

> Unfortunately, if you've already seen it in 7.0, it's
> probably too late to fix it.  I'll try though.

As I said, it's not out yet (but perhaps already at production)

CU,
Christian

[Plib-devel] reading directories

[Dave M. <Dav...@dy...>]

i added some functions for reading directories to "ul"

/*
  Directory Reading
*/

#define UL_NAME_MAX 256
typedef struct _ulDir ulDir ;
struct ulDirEnt
{
  char d_name [ UL_NAME_MAX+1 ];
  bool d_isdir ;
} ;

ulDir* ulOpenDir ( const char* dirname ) ;
ulDirEnt* ulReadDir ( ulDir* dir ) ;
void ulCloseDir ( ulDir* dir ) ;

i tested the win32 implementation and wrote a unix implementation
could some kind soul please comple and test my unix implementation?

here is my test program:

#include <plib/ul.h>

void list_files( const char* dirname )
{
  static int level=-1;
  level++;
  
  ulDir* dirp = ulOpenDir(dirname);
  if ( dirp != NULL )
  {
    ulDirEnt* dp;
    while ( (dp = ulReadDir(dirp)) != NULL )
    {
      for ( int i=0; i<level; i++) printf(" ");
      printf("%s", dp->d_name );
      if ( dp->d_isdir )
        printf("/");
      printf("\n");

      if ( dp->d_isdir &&
        strcmp (dp->d_name, ".") &&
        strcmp (dp->d_name, ".."))
      {
        char path[ UL_NAME_MAX+1 ];
        strcpy (path, dirname);
        strcat (path, "/");
        strcat (path, dp->d_name);

        list_files( path );
      }
    }
    ulCloseDir(dirp);
  }
  level--;
}

int main(int argc, char* argv[])
{
  list_files(".");
  return 0;
}

Steve- could you create a folder for me so i can add my test program to CVS?
plib/examples/src/ul

--Dave

[Plib-devel] RE: Deleting a widget from inside its callback (was RE: [Plib-dev el] PUI questions)

[Dave M. <Dav...@dy...>]

nice patch John!
I commited the changes to CVS.

notes:
- i made puCleanUpJunk a private static function
- puDisplay calls puCleanUpJunk (along with puMouse and puKeyboard)
- i changed complex.cxx to use puDeleteObject
- http://plib.sourceforge.net/pui/index.html should be updated
- john-- the button assignment in "int puMouse ( int x, int y )" in your
code uses -1 whereas the code in CVS uses 0.  i left it zero

> 
> int puMouse ( int x, int y )
> {
>   puCursor ( x, y ) ;
> 
>   if ( last_buttons == 0 )
>     return FALSE ;
> 
>   int button = (last_buttons & (1<<PU_LEFT_BUTTON  )) ?  
> PU_LEFT_BUTTON   :
>                (last_buttons & (1<<PU_MIDDLE_BUTTON)) ?  
> PU_MIDDLE_BUTTON :
>                (last_buttons & (1<<PU_RIGHT_BUTTON )) ?  
> PU_RIGHT_BUTTON
>  : -1 ;
> 
>   int h = puGetWindowHeight () ;
> 
>   int return_value = puGetBaseLiveInterface () -> checkHit ( button,
> PU_DRAG, x,
>                                                              h - y ) ;
> 
>   puCleanUpJunk () ;
> 
>   return return_value ;
> }
> 
> 
> John F. Fay
> joh...@eg...

Deleting a widget from inside its callback (was RE: [Plib-devel] PUI questions)

[John F. F. <joh...@eg...>]

I had the problem of the demo program crashing when I tried to close the
dialog box. (I use MSVC 6.0, mea culpa.)  I fixed it by adding a linked list
of "puObjects" which I called "objects_to_delete".  Then I made one function
"puDeleteObject" which simply added the object (and any children objects if
it was a puGroup) to the "objects_to_delete" list.  Finally, I made a
function "puCleanUpJunk" which deleted everything on the "objects_to_delete"
list.  The "puDeleteObject" function is called from within the widget's
callback and the "puCleanUpJunk" function is called in "puKeyboard" after
the "checkKey" call and in both "puMouse" functions after the "checkHit"
calls.

Here is the new code:

puObject *objects_to_delete = NULL;  // Pointer to linked list of objects to
delete
                                     // as a result of keyboarding or mouse
clicking

void puDeleteObject ( puObject *ob )
{
  puGroup *parent = ob->getParent () ;

  if ( parent != ob && parent != NULL )   // Remove from parent interface
    parent -> remove ( ob ) ;

  ob -> prev = NULL ;                       // Add to linked list to be
deleted
  ob -> next = objects_to_delete ;
  objects_to_delete = ob ;
  ob -> setParent ( NULL ) ;
}

void puCleanUpJunk ()
{
  // Step through the linked list of objects to delete, removing them.

  if (objects_to_delete)
  {
    for ( ; objects_to_delete != NULL ; )
    {
      puObject *next_ob = objects_to_delete ->next ;
      delete objects_to_delete ;
      objects_to_delete = next_ob ;
    }
  }
}


Here are the changes to puKeyboard and puMouse:

int puKeyboard ( int key, int updown )
{
  int return_value = puGetBaseLiveInterface () -> checkKey ( key, updown ) ;

  puCleanUpJunk () ;

  return return_value ;
}


static int last_buttons = 0 ;
int puMouse ( int button, int updown, int x, int y )
{
  puCursor ( x, y ) ;

  int h = puGetWindowHeight () ;

  if ( updown == PU_DOWN )
    last_buttons |=  ( 1 << button ) ;
  else
    last_buttons &= ~( 1 << button ) ;

  int return_value =  puGetBaseLiveInterface () -> checkHit ( button,
updown, x,
                                                              h - y ) ;

  puCleanUpJunk () ;

  return return_value ;
}

int puMouse ( int x, int y )
{
  puCursor ( x, y ) ;

  if ( last_buttons == 0 )
    return FALSE ;

  int button = (last_buttons & (1<<PU_LEFT_BUTTON  )) ?  PU_LEFT_BUTTON   :
               (last_buttons & (1<<PU_MIDDLE_BUTTON)) ?  PU_MIDDLE_BUTTON :
               (last_buttons & (1<<PU_RIGHT_BUTTON )) ?  PU_RIGHT_BUTTON
 : -1 ;

  int h = puGetWindowHeight () ;

  int return_value = puGetBaseLiveInterface () -> checkHit ( button,
PU_DRAG, x,
                                                             h - y ) ;

  puCleanUpJunk () ;

  return return_value ;
}


John F. Fay
joh...@eg...


-----Original Message-----
From: Dave McClurg [mailto:dp...@ef...]
Sent: Tuesday, August 01, 2000 21:38
To: pli...@li...
Subject: RE: [Plib-devel] PUI questions

<snip>
any thoughts on how to deal with deleting widgets inside a callback?
it seems so natural to get rid of widgets inside the callback when a
button is pressed.  i'll figure *something* out if there are no
approaches you already have in mind.

<snip>

--Dave

_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

Re: [Plib-devel] PUI questions

[Wolfram K. <w_...@rz...>]

Steve wrote:

>    ppeDeleteMeLater ( this ) ;
     ^^^

LOL.
I see you are dialed into PPE, aren't you ;-) ?

Bye bye,
Wolfram.

Re: [Plib-devel] PUI questions

[Steve B. <sjb...@ai...>]

Dave McClurg wrote:

> any thoughts on how to deal with deleting widgets inside a callback?
> it seems so natural to get rid of widgets inside the callback when a
> button is pressed.

Yes - and you 'get away with it' in Linux - but under Windoze, it
crashes.  I'm a bit suprised at that.  If the delete operator is
the last function in the callback, the only code the compiler
will generate afterwards should be a return instruction - what
is there to crash?!?

>  i'll figure *something* out if there are no
> approaches you already have in mind.

Make a list of objects for deletion - and wipe them out at
the end of the main PUI entrypoint.

    ppeDeleteMeLater ( this ) ;

...or something.
 
> also, i'd like to add "const" in several places in the plib interfaces.
> char* parameters often lack "const" where they should have it.
> any thoughts about that?

Sure - I'm just a bit lazy about that.  I learned to program C/C++
*long* before 'const' was invented - and it's hard to shake old habits.


-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

RE: [Plib-devel] PUI questions

[Dave M. <dp...@ef...>]

Steve wrote:
> Try not to break existing PUI applications - quite a 
> lot of people use PUI.
> 

understood.

any thoughts on how to deal with deleting widgets inside a callback?
it seems so natural to get rid of widgets inside the callback when a
button is pressed.  i'll figure *something* out if there are no
approaches you already have in mind.

void go_away_cb ( puObject * )
{
  /*
    Delete the dialog box when its 'OK' button is pressed.

    Doing a 'delete dialox_box' here seems to crash on MSVC
    compilers - probably because dialog_box's member function
    is indirectly calling this function. Hence we return to
    something that is in a distinctly 'iffy' state.

    So, we'll set a flag and delete it later when it's safe.
  */

  delete_the_dialog_box_please = TRUE ;
}

also, i'd like to add "const" in several places in the plib interfaces.
char* parameters often lack "const" where they should have it.
any thoughts about that?

--Dave

RE: [Plib-devel] PUI File Browser Implementation

[Dave M. <dp...@ef...>]

Hi John,

I have interest in this.  Could you place your source online somewhere and
post the link or just email it to me?  I'm writing an ssg viewer and I made
a puListBox widget much like your puLargeInput.  I would like to compare
sources and add something to PLIB.  I'm also going to add utility functions
to read directories (ulOpenDir, ulReadDir, ulCloseDir).

adios,
--Dave

> I made a file browser out of a "puLargeInput" widget.  The
> "puLargeInput" is
> essentially a multiple-line input box with a slider to the right and a
> slider below it.  (The "puText" widget won't work because it
> doesn't support
> mouse hits.)  The file browser doesn't return a file name like
> Steve wanted
> it to ( filename = puFileBrowser ("*.*"); ), but it does display a list of
> files and allow the user to pick one.  I found that I had to save
> the widget
> and a callback in order to let the program remember what it
> wanted the file
> name for.  I don't think it's very elegant, but it works; if there is a
> better way I would like to hear about it.
>
> My user interface has a button that allows the user to read the
> text from a
> file into a "puLargeInput" widget.  The callback for this button calls a
> function that opens the file browser window.  The callback passes to this
> function a character string to hold the file name when the user
> has selected
> it, a pointer to a function to be called when the user has
> selected the file
> name (I call this the "action function"), and the pointer to the
> "puLargeInput" widget which is to receive the text from the file (the
> "receiving widget").
>
> The file browser window contains a second "puLargeInput" widget
> to hold all
> the files, a "puInput" widget to hold the selected file name, and an "OK"
> button.  (It also contains a few other widgets which are not
> relevant to the
> present discussion.)  The "puLargeInput" widget gets a list of
> files written
> into it.  If the user clicks in the "puLargeInput" widget, the file name
> which he clicks on gets written into the "puInput" widget.  When he clicks
> on the "OK" button, and if the name in the "puInput" widget is a regular
> file name, the program calls the action function and passes to it the
> pointer to the receiving widget.
>
> I'm not sure if this explanation is clear.  If there is any interest in
> further details, ask me for them and I'll do my best.
>
> John F. Fay
> joh...@eg...

Re: [Plib-devel] Quaternion multiplication bug in sg in plib v.1.2.0

[Steve B. <sjb...@ai...>]

Sam Stickland wrote:

> The quaternions multiplication routines in v1.2.0 appear to be broken.

Oh - oh.

> I'm surprised this one slipped by (surely people must use quaternions) - so maybe it's my code?

Well, *I* don't use them - but I know several people do because they have contributed
patches and optimisations - and people don't usually do that unless they have self-interest
in using those routines.

 "Negative0" <neg...@ea...>
     -- Contributed the most recent patches.

 Sylvan Clebsch <si...@si...>
     -- Provided some optimisations.

 Kevin Thompson <kev...@ya...> 
     -- Provided the original Quaternion code.
     -- Fixed a bug in sgIdentityQuat

You might ask these people.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] sg & STL

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:
> 
> Amit Bakshi writes:
> > Has anyone tried putting any of the sg* types into an STL container yet?
> > I tried it but it doesnt work as most types are typedef'd to float[n]. I was
> > thinking of wrapping the simple types into a class which provides proper
> > operators so that the sg* functions still work. Has anyone done this yet?
> 
> Just so you know, the plib author is not exactly thrilled with using
> the STL (probably mostly because of the portability issues it
> creates.)  There is a wide variety of STL implimentations (or various
> stages of implimentations) out there which can cause a lot of
> compatibility problems between the various compilers.

Yep - as Curt predicts - I'm not very fond of STL - but I don't think
that's the issue here.
 
> Before you get too far down this path, you probably will want to have
> a serious discussion about it with Steve because I doubt he will be in
> favor of making these sorts of modifications to plib.

Does this actually require making changes to SG?

SG is really the most basic low level thing - I quite expect you to
want to wrap it with other things when you need to - but to use it
"raw" when speed is needed (eg in SSG).

However, I don't see a whole lot of benefit to including those
wrappers in PLIB...and as usual I'm very averse to adding dependancies
to PLIB.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] path for PLIB

[Steve B. <sjb...@ai...>]

Christian Mayer wrote:

> as the last SuSE (6.4) had PLIb at the wrong place (somewhere below
> /X11/) I was curious if anything had changed for the yet-to-come 7.0.
> 
> But it seems that it's still in the wrong place :-(

What version are they shipping?
 
> Shouldn't we talk to them about that?

I've talked to them before - they have this fixation that
anything that *uses* X11 should be stored *inside* X11.

That's just plain silly IMHO - I use lots of other things
too - but I don't expect to be stored inside their directory
trees!

    "uses" != "is_a_part_of"

What's more, PLIB doesn't actually use X11 at all - it
uses GLUT and OpenGL - but (in principal) there can be
versions of those that don't use X11...and PLIB is supposed
to be portable after all.

Unfortunately, if you've already seen it in 7.0, it's
probably too late to fix it.  I'll try though.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] sg & STL

[<Va...@t-...>]

Amit Bakshi wrote:
> 
> Has anyone tried putting any of the sg* types into an STL container yet?
> I tried it but it doesnt work as most types are typedef'd to float[n]. I was
> thinking of wrapping the simple types into a class which provides proper
> operators so that the sg* functions still work. Has anyone done this yet?

The WeatherDatabase of the FlightGear project has wrappers for the basic
sg types (actually, only the vectors).

The reason why I had to wrap them, was that I wanted to store them in a
vector (or was it a list?).

It's very easy to achieve that. So I think that everybody could do it
himself in the own code if Steve doesn't want it in PLIB. But we might
consider putting it in the yet to come Aux library.

Hm, it'll perhaps might be a good idea to move the FGFS STL
inportability handling to the Aux library, so that other projects can
benefit.

CU,
Christian

Re: [Plib-devel] sg & STL

[Curtis L. O. <cu...@in...>]

Amit Bakshi writes:
> I was under the impression that STLport was quite portable.
> Anyway, I don't care too much if my modification would make
> it to the official plib. I was just wondering if anyone has attempted
> this before. Surely I can't be the only one using STL :)

We use the STL extensively in the flightgear project, but have had to
do a lot of fancy stepping, portability work, etc. to maintain
compatibility.  You'd really be surprised at the STL variants out
there.  They are often generally the same, but between different
versions of the STL, different stages of implimentation, etc.  It's
not even just differences between platforms or compilers, there are
often differences between versions of compilers.  The STL has a lot of
good points which is why the flightgear project uses it, just be
prepaired for a lot of headaches and a lot of extra work if you want
your project to be portable.

Regards,

Curt.
--
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] sg & STL

[Amit B. <am...@de...>]

I was under the impression that STLport was quite portable.
Anyway, I don't care too much if my modification would make
it to the official plib. I was just wondering if anyone has attempted
this before. Surely I can't be the only one using STL :)

Regards,
Amit

 "Curtis L. Olson" wrote
>
> Just so you know, the plib author is not exactly thrilled with using
> the STL (probably mostly because of the portability issues it
> creates.)  There is a wide variety of STL implimentations (or various
> stages of implimentations) out there which can cause a lot of
> compatibility problems between the various compilers.
> 
> Before you get too far down this path, you probably will want to have
> a serious discussion about it with Steve because I doubt he will be in
> favor of making these sorts of modifications to plib.
> 
> Regards,
> 
> Curt.

Re: [Plib-devel] sg & STL

[Curtis L. O. <cu...@me...>]

Amit Bakshi writes:
> Has anyone tried putting any of the sg* types into an STL container yet?
> I tried it but it doesnt work as most types are typedef'd to float[n]. I was
> thinking of wrapping the simple types into a class which provides proper
> operators so that the sg* functions still work. Has anyone done this yet?

Just so you know, the plib author is not exactly thrilled with using
the STL (probably mostly because of the portability issues it
creates.)  There is a wide variety of STL implimentations (or various
stages of implimentations) out there which can cause a lot of
compatibility problems between the various compilers.

Before you get too far down this path, you probably will want to have
a serious discussion about it with Steve because I doubt he will be in
favor of making these sorts of modifications to plib.

Regards,

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

[Plib-devel] sg & STL

[Amit B. <am...@cr...>]

Has anyone tried putting any of the sg* types into an STL container yet?
I tried it but it doesnt work as most types are typedef'd to float[n]. I was
thinking of wrapping the simple types into a class which provides proper
operators so that the sg* functions still work. Has anyone done this yet?

[Plib-devel] path for PLIB

[<Va...@t-...>]

Hi,

as the last SuSE (6.4) had PLIb at the wrong place (somewhere below
/X11/) I was curious if anything had changed for the yet-to-come 7.0.

But it seems that it's still in the wrong place :-(

Shouldn't we talk to them about that?

CU,
Christian

[Plib-devel] Quaternion multiplication bug in sg in plib v.1.2.0

[Sam S. <sa...@sp...>]

Hi,

The quaternions multiplication routines in v1.2.0 appear to be broken.  I knocked up some code to demonstrate this, that's attached.

Basically it does this:

i  - identity quaternion
a - (x, y, z, w) = (0, cos(1.25), sin(1.25)
r - result

Doing: sgMult(&r, &a, &i) in 1.1.11 gives:

x:    0.315322
y:   -0.000000
z:    0.948985
w:   0.000000

and doing: sgMult(r, a, i) in 1.2.0 gives:

x:    0.948985
y:    0.000000
z:    0.315322
w:  -0.000000

so it appears x <-> z and y<-> w.  I haven't had the time to check the plib code to find the error yet - I just hacked the transform
into my code :/

I'm surprised this one slipped by (surely people must use quaternions) - so maybe it's my code?

(Btw, I did notice that the quaternion layout is different between these versions)

Sam

[Plib-devel] PUI File Browser Implementation

[John F. F. <joh...@eg...>]

I made a file browser out of a "puLargeInput" widget.  The "puLargeInput" is
essentially a multiple-line input box with a slider to the right and a
slider below it.  (The "puText" widget won't work because it doesn't support
mouse hits.)  The file browser doesn't return a file name like Steve wanted
it to ( filename = puFileBrowser ("*.*"); ), but it does display a list of
files and allow the user to pick one.  I found that I had to save the widget
and a callback in order to let the program remember what it wanted the file
name for.  I don't think it's very elegant, but it works; if there is a
better way I would like to hear about it.

My user interface has a button that allows the user to read the text from a
file into a "puLargeInput" widget.  The callback for this button calls a
function that opens the file browser window.  The callback passes to this
function a character string to hold the file name when the user has selected
it, a pointer to a function to be called when the user has selected the file
name (I call this the "action function"), and the pointer to the
"puLargeInput" widget which is to receive the text from the file (the
"receiving widget").

The file browser window contains a second "puLargeInput" widget to hold all
the files, a "puInput" widget to hold the selected file name, and an "OK"
button.  (It also contains a few other widgets which are not relevant to the
present discussion.)  The "puLargeInput" widget gets a list of files written
into it.  If the user clicks in the "puLargeInput" widget, the file name
which he clicks on gets written into the "puInput" widget.  When he clicks
on the "OK" button, and if the name in the "puInput" widget is a regular
file name, the program calls the action function and passes to it the
pointer to the receiving widget.

I'm not sure if this explanation is clear.  If there is any interest in
further details, ask me for them and I'll do my best.

John F. Fay
joh...@eg...

[Plib-devel] FW: 3D Map Editor Advice?

[Norman V. <nh...@ca...>]

Forwarded from OPENGL-GAMEDEV-L

Stephen J Baker wrote:

>I like FLTK too - but neither GTK nor FLTK can use OpenGL to render the
GUI,
>GLUI and PUI both do all their rendering using OpenGL.

This is why I posed the question about making a
OpenGL driver for microwindows.

FLTK has been ported to run on top of microwindows.
Basically with a blit of an offscreen buffer.

The thought of having FLTK using OpenGL for its GUI rendering
I find very appealing.

Norman

Re: [Plib-devel] PUI questions

[Steve B. <sjb...@ai...>]

> Dave McClurg wrote:

> i know that PUI is considered fairly static and stable but would anyone
> mind some refinement of PUI to occur.

That would be great!

I do use PUI - but only as I originally intended it - as a *SIMPLE* way to add
*SIMPLE* GUI to existing OpenGL applications without massive restructuring.

An excellent example would be the title screen for TuxKart - which has:

 * Four radio buttons to let you pick a track to race on.
 * One slider to let you set the number of laps in the race.
 * Two buttons: "Start Game" and "Quit".

...then within the game, there is menu bar with about a dozen controls in it.

I havn't enhanced it because I don't *need* any enhancements - although a
file browser would be nice.

The reason I didn't make a file browser initially is that I realised that GLUT
was basically incapable of letting me say things like:

   filename = puFileBrowser ( "*.*" ) ;

...because you have to return from the GLUT callback before you can make it
swapbuffers again - and hence puFileBrowser cannot be written with standard
PUI widgets if you want to use it within GLUT.

Yuck!

>  basically, my goal would be to enhance PUI to the point where i can build
> a nice looking SSG viewer.  For that, I need a listbox and other controls
> (which could be in the viewer) to allow something that looks as good as GLUI
> example #5.  Any reason not to go forward in this direction?

If you can figure out how to do it, you certainly have my enthusiastic
support.  Try not to break existing PUI applications - quite a lot of people
use PUI.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

RE: [Plib-devel] PUI questions

[Norman V. <nh...@ca...>]

Dave McClurg 

>i know that PUI is considered fairly static and stable 
>but would anyone mind some refinement of PUI to occur.  

Not me !

[OT]
A far fetched idea would be to create an
OpenGL based driver for microwindows.
http://microwindows.censoft.com/

Norman