plib-users

Re: [Plib-users] Problem with setLabel, weirdness ensues.

[M&M <gon...@gm...>]

Hi,

Why contact seperately? Why not to the mailing list?

Cheers





On Wed, Jun 11, 2008 at 8:30 PM, Fay John F Dr CTR USAF 46 SK <
joh...@eg...> wrote:

> Cory,
>
>        That is indeed weird.  I will contact you separately about it.
>
> John F. Fay
> Technical Fellow
> Jacobs Technology TEAS Group
> 850-883-1294
>
> -----Original Message-----
> From: pli...@li...
> [mailto:pli...@li...] On Behalf Of cory
> barton
> Sent: Wednesday, June 11, 2008 2:28 PM
> To: pli...@li...
> Subject: [Plib-users] Problem with setLabel, weirdness ensues.
>
> I am trying to use the the set label command: and I am having weird
> problems.
> something like this works: puObject->setLabel( "label" );
>
> this fails:
> char txt[ PUSTRING_MAX ];
> ...
>        //kp slider
>        kp_slider = new puSlider ( 100, 60, 200, TRUE );
>        kp_slider->setMinValue( GAIN_MIN );
>        kp_slider->setMaxValue( GAIN_MAX );
>        kp_slider->setValue( ( float ) aileron_pid->get_kp() ); //set
> value
> to aileron gains since roll is selected by default
>        sprintf( txt, "Kp: %.3f", aileron_pid->get_kp() ); //format
> label
>        kp_slider->setLabel( txt );
>
> the label comes out like: *****>*****0****** *****
>
> but I can make it work by adding an unused variable?!
> this works:
>        //unused variable bbb
>        char bbb[ PUSTRING_MAX ]; //if I remove this setLabel() fails!
>        char txt[ PUSTRING_MAX ];
> ...
>        //kp slider
>        kp_slider = new puSlider ( 100, 60, 200, TRUE );
>        kp_slider->setMinValue( GAIN_MIN );
>        kp_slider->setMaxValue( GAIN_MAX );
>        kp_slider->setValue( ( float ) aileron_pid->get_kp() ); //set
> value
> to aileron gains since roll is selected by default
>        sprintf( txt, "Kp: %.3f", aileron_pid->get_kp() ); //format
> label
>        kp_slider->setLabel( txt );
>
> I also cannot set the label in the callback function.
>
> Please help.
>
> Cory
>
> ------------------------------------------------------------------------
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
>

Re: [Plib-users] Problem with setLabel, weirdness ensues.

[Fay J. F Dr C. U. 46 S. <joh...@eg...>]

Cory,

	That is indeed weird.  I will contact you separately about it.

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of cory
barton
Sent: Wednesday, June 11, 2008 2:28 PM
To: pli...@li...
Subject: [Plib-users] Problem with setLabel, weirdness ensues.

I am trying to use the the set label command: and I am having weird
problems.
something like this works: puObject->setLabel( "label" );

this fails:
char txt[ PUSTRING_MAX ];
...
	//kp slider
	kp_slider = new puSlider ( 100, 60, 200, TRUE );
	kp_slider->setMinValue( GAIN_MIN );
	kp_slider->setMaxValue( GAIN_MAX );
	kp_slider->setValue( ( float ) aileron_pid->get_kp() ); //set
value
to aileron gains since roll is selected by default
	sprintf( txt, "Kp: %.3f", aileron_pid->get_kp() ); //format
label
	kp_slider->setLabel( txt );

the label comes out like: *****>*****0****** *****

but I can make it work by adding an unused variable?!
this works:
	//unused variable bbb
	char bbb[ PUSTRING_MAX ]; //if I remove this setLabel() fails!
	char txt[ PUSTRING_MAX ];
...
	//kp slider
	kp_slider = new puSlider ( 100, 60, 200, TRUE );
	kp_slider->setMinValue( GAIN_MIN );
	kp_slider->setMaxValue( GAIN_MAX );
	kp_slider->setValue( ( float ) aileron_pid->get_kp() ); //set
value
to aileron gains since roll is selected by default
	sprintf( txt, "Kp: %.3f", aileron_pid->get_kp() ); //format
label
	kp_slider->setLabel( txt );

I also cannot set the label in the callback function.

Please help.

Cory

------------------------------------------------------------------------
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
plib-users mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-users

[Plib-users] Problem with setLabel, weirdness ensues.

[cory b. <co...@gm...>]

I am trying to use the the set label command: and I am having weird problems.
something like this works: puObject->setLabel( "label" );

this fails:
char txt[ PUSTRING_MAX ];
...
	//kp slider
	kp_slider = new puSlider ( 100, 60, 200, TRUE );
	kp_slider->setMinValue( GAIN_MIN );
	kp_slider->setMaxValue( GAIN_MAX );
	kp_slider->setValue( ( float ) aileron_pid->get_kp() ); //set value
to aileron gains since roll is selected by default
	sprintf( txt, "Kp: %.3f", aileron_pid->get_kp() ); //format label
	kp_slider->setLabel( txt );

the label comes out like: *****>*****0****** *****

but I can make it work by adding an unused variable?!
this works:
	//unused variable bbb
	char bbb[ PUSTRING_MAX ]; //if I remove this setLabel() fails!
	char txt[ PUSTRING_MAX ];
...
	//kp slider
	kp_slider = new puSlider ( 100, 60, 200, TRUE );
	kp_slider->setMinValue( GAIN_MIN );
	kp_slider->setMaxValue( GAIN_MAX );
	kp_slider->setValue( ( float ) aileron_pid->get_kp() ); //set value
to aileron gains since roll is selected by default
	sprintf( txt, "Kp: %.3f", aileron_pid->get_kp() ); //format label
	kp_slider->setLabel( txt );

I also cannot set the label in the callback function.

Please help.

Cory

Re: [Plib-users] Question re PUI sizes & frames

[James F. <fr...@cs...>]

On Sun, 11 May 2008, Steve Baker wrote:

> Units (like in all of 3D graphics) are arbitary until you define your
> viewport and transformation stack.
>
> By default, PUI sets up the window such that one unit == one pixel.  But
> as soon as you override PUI's initial transform stack, you're setting
> what the units "mean" and your question becomes meaningless.


OK, maybe I'm asking the wrong question.  Let me make it more general: 
when I'm creating a menu from individual objects, how do I position them 
within the group?

To illustrate, Here's a snippet of code from a test program, in which I'm 
trying to create a menu group with a few items.  Added functions should 
allow 3D position, rotation, and scaling.  I'm trying to position the 
items in the group so they pack vertically.  (getStringSize is a function 
added to get the size of a string in the vector font.)


   G1 = new puGroup (0, 0);
   G1->Add3DLocation (x, y, z, 0.0, 0.0, 0.0);

   G1->getStringSize (&ww, &hh, "Say Hello");
   printf ("ww = %d, hh = %d\n", ww, hh);
   w = ww;
   h = hh;
   G1->getStringSize (&ww, &hh, "Say Goodbye");
   printf ("ww = %d, hh = %d\n", ww, hh);
   if (ww > w) w = ww;
   if (hh > h) h = hh;
   w += 16;
   h += 8;

   b1 = new puOneShot (0, 0, w, h);
   b2 = new puOneShot (0, -2 * h, w, -h);
   bx = new puButtonBox (0, -7 * h, w, -3 * h, bxLabels, 1);


//G1->recalc_bbox ();
   G1->setSize (w, 7 * h);
   G1->close ();

So I run this, and it gives me the items, but with a vertical space 
between each about equal to the height.  With different parameters, I 
might get boxes on top of one another.  Also, when I use the recalc_bbox 
function, it doesn't seem to calculate the bounding box of all the items, 
just the first, as the rotation &c are all around the center of the "Say 
Hello" box rather than around the center of G1.

I must be missing something important here, but what?

Thanks,
James

Re: [Plib-users] Question re PUI sizes & frames

[Steve B. <st...@sj...>]

Units (like in all of 3D graphics) are arbitary until you define your 
viewport and transformation stack.

By default, PUI sets up the window such that one unit == one pixel.  But 
as soon as you override PUI's initial transform stack, you're setting 
what the units "mean" and your question becomes meaningless.

John F. Fay wrote:
> James,
> 
> 	If I remember correctly, PUI uses pixels as its units of distance.  The 
> origin is the lower left-hand corner of the screen (or group), the x-axis 
> extends to the right, and the y-axis extends upwards.
> 
> 	Yes, you do have to create the frame first, before creating the buttons. 
>  It is possible, though, to resize the frame after the buttons have been 
> created.

Re: [Plib-users] Question re PUI sizes & frames

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

James,

	If I remember correctly, PUI uses pixels as its units of distance.  The 
origin is the lower left-hand corner of the screen (or group), the x-axis 
extends to the right, and the y-axis extends upwards.

	Yes, you do have to create the frame first, before creating the buttons. 
 It is possible, though, to resize the frame after the buttons have been 
created.

		- John


-----Original Message-----
From:	James Frye
Sent:	Sunday, May 11, 2008 11:45 AM
To:	PLIB Users
Subject:	[Plib-users] Question re PUI sizes & frames


Hi,

I'm making some progress on modifying PUI to work with VR, but have a
couple more questions.  After a few modifications (such as replacing the
bitmapped text with GLUT vector fonts), I've got groups containing buttons
and such that I can move around & rotate at will.  Now I want to add a
nice frame around a group, but it seems that I have to create the frame
before creating the objects that go in it.  IOW the code needs to look
something like

   group = new puGroup (size...)
   frame = new puFrame (x1, y1, x2, y2);
   button1 = new puButton (x, y, label);
   button2 = new puButton (x, y, label);
   group->close ();

The problem is how to know the dimensions for frame before I create at
least one button, and find its size?

That leads to a larger question: what does PUI use as its internal
coordinate system?  At some point I'll need to add scaling of the PUI
coordinate system to the VR one, so that the menus appear at virtual world
sizes.  I'd rather not do this by trial & error, but I don't understand
the internal coordinates from the code.

Thanks,
James


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j  
avaone
_______________________________________________
plib-users mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-users

[Plib-users] Question re PUI sizes & frames

[James F. <fr...@cs...>]

Hi,

I'm making some progress on modifying PUI to work with VR, but have a 
couple more questions.  After a few modifications (such as replacing the 
bitmapped text with GLUT vector fonts), I've got groups containing buttons 
and such that I can move around & rotate at will.  Now I want to add a 
nice frame around a group, but it seems that I have to create the frame 
before creating the objects that go in it.  IOW the code needs to look 
something like

   group = new puGroup (size...)
   frame = new puFrame (x1, y1, x2, y2);
   button1 = new puButton (x, y, label);
   button2 = new puButton (x, y, label);
   group->close ();

The problem is how to know the dimensions for frame before I create at 
least one button, and find its size?

That leads to a larger question: what does PUI use as its internal 
coordinate system?  At some point I'll need to add scaling of the PUI 
coordinate system to the VR one, so that the menus appear at virtual world 
sizes.  I'd rather not do this by trial & error, but I don't understand 
the internal coordinates from the code.

Thanks,
James

Re: [Plib-users] Readable user docs for PUI?

[James F. <fr...@cs...>]

On Thu, 8 May 2008, Steve Baker wrote:

> James Frye wrote:
>> Hummm... I had been thinking I'd have to re-write most of the drawing
>> code to do 3D drawing instead of 2D - e.g. calling glVertex3f instead of
>> glVertex2i - then changing setPosition & setSize to take 3D coords, adding
>> a setRotation, etc.
>>
> Oh - no, no, no!  Certainly not!   PUI uses glVertex2D - but all that
> does is generate a full 3D vertex with Z=0,W=1.  The subsequent
> rotate/translate/perspective transforms operate exactly the same way
> they do for 3D vertices.  You CERTAINLY won't have to do anything like
> that if all you want to do is to simulate a 2D GUI on a virtual 2D
> display placed somewhere out in the 3D world.

Well, I do want more than that: the ability to use the functions in any 
way needed.  It might be a display on a simulated device somewhere in the 
world, or it might be simulated buttons on a device the user carries with 
him, or "magic" system menus that the user can pull out of thin air, as it 
were.

So it seems that somehow pui has to be altered/extended so that each menu 
carries around its 3D transform information, then puDisplay (or code 
beneath) contains a loop that sets the transform for each menu.  And of 
course the transform can be dynamically modified, if for instance the menu 
is attached to a moving object...

> Once you have the right transform on the stack, PUI will render in full
> 3D just fine.
>
> One thing you MIGHT have problems with is that PUI doesn't clip it's
> underlying primitives to the screen - it lets OpenGL do that.  You'll
> need to set up some user clip planes to fix that properly - but you
> could consider cheating and building your virtual monitor with a nice
> chunky frame that Z-buffers out the PUI widgets that hang off the edges
> of the screen a bit.

May not be a problem, since in a CAVE environment there aren't any 
edges...


> Actually - the super-modern way to do this would be to leave PUI 100%
> alone and simply have it render to an RGB texture instead of to the
> screen.  Set up a render-to-texture rendering target - run PUI exactly
> as you would normally - then apply that texture to your virtual computer
> screen.  That would completely take care of the clipping problem and
> allow you to use PUI's standard puDisplay() function.  Then you can
> apply that texture to any polygon(s) in your 3D scene and be utterly
> assured that everything will play nicely.  If you have multiple PUI
> screens in your virtual world then you could also gain some performance
> by only re-rendering the texture for the screen that the user is
> interacting with.  That would be really cool actually - you could easily
> have PUI displayed on translucent screens (like on the movie "Minority
> Report") or whatever.
>
> If you are familiar with the render-to-texture approach then you should
> be able to get this working with just a couple of hour's work and no
> changes whatever to the PUI source.   This would be by far the simplest
> way to do it.

I'm not really familiar with textures at all.  What I've done with OpenGL 
has always been things like data display, where you draw objects/surfaces, 
and color them according to data values.

Re: [Plib-users] Readable user docs for PUI?

[Steve B. <st...@sj...>]

James Frye wrote:
> Hummm... I had been thinking I'd have to re-write most of the drawing 
> code to do 3D drawing instead of 2D - e.g. calling glVertex3f instead of 
> glVertex2i - then changing setPosition & setSize to take 3D coords, adding 
> a setRotation, etc.
>   
Oh - no, no, no!  Certainly not!   PUI uses glVertex2D - but all that 
does is generate a full 3D vertex with Z=0,W=1.  The subsequent 
rotate/translate/perspective transforms operate exactly the same way 
they do for 3D vertices.  You CERTAINLY won't have to do anything like 
that if all you want to do is to simulate a 2D GUI on a virtual 2D 
display placed somewhere out in the 3D world.

Once you have the right transform on the stack, PUI will render in full 
3D just fine.

One thing you MIGHT have problems with is that PUI doesn't clip it's 
underlying primitives to the screen - it lets OpenGL do that.  You'll 
need to set up some user clip planes to fix that properly - but you 
could consider cheating and building your virtual monitor with a nice 
chunky frame that Z-buffers out the PUI widgets that hang off the edges 
of the screen a bit.

Actually - the super-modern way to do this would be to leave PUI 100% 
alone and simply have it render to an RGB texture instead of to the 
screen.  Set up a render-to-texture rendering target - run PUI exactly 
as you would normally - then apply that texture to your virtual computer 
screen.  That would completely take care of the clipping problem and 
allow you to use PUI's standard puDisplay() function.  Then you can 
apply that texture to any polygon(s) in your 3D scene and be utterly 
assured that everything will play nicely.  If you have multiple PUI 
screens in your virtual world then you could also gain some performance 
by only re-rendering the texture for the screen that the user is 
interacting with.  That would be really cool actually - you could easily 
have PUI displayed on translucent screens (like on the movie "Minority 
Report") or whatever.

If you are familiar with the render-to-texture approach then you should 
be able to get this working with just a couple of hour's work and no 
changes whatever to the PUI source.   This would be by far the simplest 
way to do it.
> This is intended to work within an existing VR library (freeVR), so the 
> basic graphics environment gets set up there.  It gives you 3D "wand" 
> coordinates.  I imagine that will involve a bit of work to find what is 
> selected, but it seems simple in principle.
>   
That should make finding the "mouse" coordinates a lot simpler.
>> You can even make PUI draw a software cursor so that your control panels
>> have cursors that move around in perspective and such.
>>     
> Already handled by the VR lib - and of course in a CAVE-like environment 
> it's actually tracking hand or wand position.
>   
OK...But I think I'd leave PUI's software cursor alone because seeing 
that start to track when your virtual hand touches the PUI screen would 
give the end user the confidence that they are indeed driving this 
virtual touch-screen.  But that's obviously something you are better 
placed to figure out than me!

-- Steve.

Re: [Plib-users] Readable user docs for PUI?

[James F. <fr...@cs...>]

On Wed, 7 May 2008, Steve Baker wrote:

> I believe you can easily attach PUI widgets to 3D surfaces - I did that
> a LONG time ago though and lots has changed since then.   I think you
> can just get into pu.cxx and write a new function that is just like
> puDisplay() but calls your own code instead of using
> puSetOpenGLState().  Take out the glViewport() call, the glOrtho() and
> the two glLoadIdentity() calls and push whatever transform you want onto
> the stack instead.  PUI disables depth-testing, fog and lighting - and
> you may need to change that too.  The biggest problem (IIRC) as in
> transforming your mouse coordinates when you feed them to puMouse().

Hummm... I had been thinking I'd have to re-write most of the drawing 
code to do 3D drawing instead of 2D - e.g. calling glVertex3f instead of 
glVertex2i - then changing setPosition & setSize to take 3D coords, adding 
a setRotation, etc.

This is intended to work within an existing VR library (freeVR), so the 
basic graphics environment gets set up there.  It gives you 3D "wand" 
coordinates.  I imagine that will involve a bit of work to find what is 
selected, but it seems simple in principle.

> You can even make PUI draw a software cursor so that your control panels
> have cursors that move around in perspective and such.

Already handled by the VR lib - and of course in a CAVE-like environment 
it's actually tracking hand or wand position.

> If you are concerned about LGPL issues...

Not at all.  This is just a project for a class, so odds are it won't get 
used afterwards.  If it does, it would go into the freeVR lib that's also 
LGPL'd (or similar).

Re: [Plib-users] Readable user docs for PUI?

[Steve B. <st...@sj...>]

Fay John F Dr CTR USAF 46 SK wrote:
> Even though this is a PLIB mailing list, I personally have no problem
> with people recommending other software packages.  The PLIB libraries
> are being offered free of charge with the LGPL license in the hope that
> people will find them useful; the primary focus is on enabling people to
> do things.
>   
Yes - no problem.  If another package is better suited than PUI to doing 
the job - then by all means let us discuss that.

The problems I had with GLUI (which resulted in me writing PUI in the 
first place) was that it didn't 'play nicely' with other rendering 
software.  It wants to "own the main loop" - PUI can be invoked as a 
subroutine call at any point in the rendering cycle you like.   That was 
a long time ago though - it's possible that GLUI has evolved ways to 
play more nicely with a primarily-non-GUI interactive application.  PUI 
may well be better suited on those grounds alone.

I believe you can easily attach PUI widgets to 3D surfaces - I did that 
a LONG time ago though and lots has changed since then.   I think you 
can just get into pu.cxx and write a new function that is just like 
puDisplay() but calls your own code instead of using 
puSetOpenGLState().  Take out the glViewport() call, the glOrtho() and 
the two glLoadIdentity() calls and push whatever transform you want onto 
the stack instead.  PUI disables depth-testing, fog and lighting - and 
you may need to change that too.  The biggest problem (IIRC) as in 
transforming your mouse coordinates when you feed them to puMouse().

You can even make PUI draw a software cursor so that your control panels 
have cursors that move around in perspective and such.

If you are concerned about LGPL issues, you could avoid modifying PUI 
altogether by writing:

   extern void puCleanUpJunk(void);
   void my_puDisplay ( void )
   {
        ...set up your opengl state...
        glDisable ( GL_CULL_FACE  ) ;
        puCleanUpJunk () ;
        puGetUltimateLiveInterface () -> draw ( 0, 0 ) ;
        puDrawCursor ( myCursor_x, myCursor_y ) ;
        puRefresh = FALSE ;
        ...restore opengl state...
   }

Re: [Plib-users] Readable user docs for PUI?

[Fay J. F Dr C. U. 46 S. <joh...@eg...>]

Goncalo,

Even though this is a PLIB mailing list, I personally have no problem
with people recommending other software packages.  The PLIB libraries
are being offered free of charge with the LGPL license in the hope that
people will find them useful; the primary focus is on enabling people to
do things.

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of M&M
Sent: Wednesday, May 07, 2008 5:41 AM
To: PLIB Users
Subject: Re: [Plib-users] Readable user docs for PUI?

Hi James,
 
I, some how agree with you about, not only the PUI documentation, but
also, all PLIB documentation...
 
This is a PLIB maling list, so, maybe i shouldn't do this, but my real
interest is to help you, so, maybe you could check other libraries, like
GLUI, i've already used it, it is "supremmelly" easy to use and there is
very nice documentation, google it!
 
I hope i could help ya,
Goncalo
 

Re: [Plib-users] Readable user docs for PUI?

[James F. <fr...@cs...>]

On Wed, 7 May 2008, M&M wrote:

> I, some how agree with you about, not only the PUI documentation, but also,
> all PLIB documentation...
>
> This is a PLIB maling list, so, maybe i shouldn't do this, but my real
> interest is to help you, so, maybe you could check other libraries, like
> GLUI, i've already used it, it is "supremmelly" easy to use and there is
> very nice documentation, google it!

I've used GLUI, and agree that it is easy to use.  (Haven't really used 
plib yet, so I can't compare the two.)  However, what I'm working on now 
involves seriously modifying & extending whatever code I start from, and I 
haven't made much progress in understanding the GLUI code.  I'm hoping pui 
will be easier to work with.

Thanks,
James

Re: [Plib-users] Readable user docs for PUI?

[M&M <gon...@gm...>]

Hi James,

I, some how agree with you about, not only the PUI documentation, but also,
all PLIB documentation...

This is a PLIB maling list, so, maybe i shouldn't do this, but my real
interest is to help you, so, maybe you could check other libraries, like
GLUI, i've already used it, it is "supremmelly" easy to use and there is
very nice documentation, google it!

I hope i could help ya,
Goncalo





On Wed, May 7, 2008 at 5:52 AM, James Frye <fr...@cs...> wrote:

> On Tue, 6 May 2008, Fay John F Dr CTR USAF 46 SK wrote:
>
> >       Hello and welcome to the PLIB community.  I have found that
> > clicking on the text, pressing "Ctrl-A" to select all of it, and then
> > copying and pasting it into a word processor works decently.
>
> Duh!  Why didn't I think of that?  I guess because I seldom use a word
> processor - what little of that nature I do usually gets done in Latex.
>
> > There's also a "short introduction" at ...
> >
> > http://plib.sourceforge.net/pui/BasicPUI.html
> >
> > ... which I had completely forgotten about.  And if you have any
> > questions I will probably be able to answer them.
>
> Thanks for the offer.  What I'm trying to do is get a menu system that
> will work within a virtual reality library, so that instead of menus being
> tied to window/screen geometry, they become objects in the world.  So for
> example if I had an ATM machine in the world, I could use the menu system
> to simulate the ATM buttons.
>
> Being no fonder than most of reinventing the wheel, I figured it might be
> simpler to modify some existing library than to start from scratch, and
> PUI seems much simpler (or at least the code's smaller) than the other
> OpenGL UIs I've found.
>
> Comments and advice are of course welcome, even (maybe especially) if
> they're of the "omigawd you don't know what you're getting into" sort.
>
> Thanks,
> James
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
>

Re: [Plib-users] Readable user docs for PUI?

[James F. <fr...@cs...>]

On Tue, 6 May 2008, Fay John F Dr CTR USAF 46 SK wrote:

> 	Hello and welcome to the PLIB community.  I have found that
> clicking on the text, pressing "Ctrl-A" to select all of it, and then
> copying and pasting it into a word processor works decently.

Duh!  Why didn't I think of that?  I guess because I seldom use a word 
processor - what little of that nature I do usually gets done in Latex.

> There's also a "short introduction" at ...
>
> http://plib.sourceforge.net/pui/BasicPUI.html
>
> ... which I had completely forgotten about.  And if you have any
> questions I will probably be able to answer them.

Thanks for the offer.  What I'm trying to do is get a menu system that 
will work within a virtual reality library, so that instead of menus being 
tied to window/screen geometry, they become objects in the world.  So for 
example if I had an ATM machine in the world, I could use the menu system 
to simulate the ATM buttons.

Being no fonder than most of reinventing the wheel, I figured it might be 
simpler to modify some existing library than to start from scratch, and 
PUI seems much simpler (or at least the code's smaller) than the other 
OpenGL UIs I've found.

Comments and advice are of course welcome, even (maybe especially) if 
they're of the "omigawd you don't know what you're getting into" sort.

Thanks,
James

Re: [Plib-users] Readable user docs for PUI?

[Steve B. <st...@sj...>]

I don't know what browser you are using - but Firefox has no problem in 
printing the online PUI manual.
When you print it, the background is automatically removed and the text 
is printed black.
I don't see any patterned green in the printed version - although there 
are some diagrams.

As far as I know, all browsers do that by default.

Anyway, the online PUI manual is the only documentation in existence.

James Frye wrote:
> Hi,
>
> Does anyone know where I can find a readable/printable manual for PUI? 
> I'd like to use it for a project I'm doing, but on my browser, the online 
> version has chunks of a patterned green background splashed through it, 
> making it very difficult to even read on the screen, let alone print.  I 
> don't know enough about HTML to think of an easy way to convert it to 
> readable form.
>
> Thanks,
> James
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
>   

Re: [Plib-users] Readable user docs for PUI?

[Fay J. F Dr C. U. 46 S. <joh...@eg...>]

James,

	Hello and welcome to the PLIB community.  I have found that
clicking on the text, pressing "Ctrl-A" to select all of it, and then
copying and pasting it into a word processor works decently.

There's also a "short introduction" at ...

http://plib.sourceforge.net/pui/BasicPUI.html

... which I had completely forgotten about.  And if you have any
questions I will probably be able to answer them.

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of James
Frye
Sent: Tuesday, May 06, 2008 4:13 PM
To: pli...@li...
Subject: [Plib-users] Readable user docs for PUI?

Hi,

Does anyone know where I can find a readable/printable manual for PUI? 
I'd like to use it for a project I'm doing, but on my browser, the
online 
version has chunks of a patterned green background splashed through it, 
making it very difficult to even read on the screen, let alone print.  I

don't know enough about HTML to think of an easy way to convert it to 
readable form.

Thanks,
James

------------------------------------------------------------------------
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
avaone
_______________________________________________
plib-users mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-users

[Plib-users] Readable user docs for PUI?

[James F. <fr...@cs...>]

Hi,

Does anyone know where I can find a readable/printable manual for PUI? 
I'd like to use it for a project I'm doing, but on my browser, the online 
version has chunks of a patterned green background splashed through it, 
making it very difficult to even read on the screen, let alone print.  I 
don't know enough about HTML to think of an easy way to convert it to 
readable form.

Thanks,
James

Re: [Plib-users] Errors building plib1.8.5

[Stuart M. <stu...@bl...>]

Hi,

   I'm afraid I'm not up on specifics as in how to fix this, but I can 
explain the process and hopefully that might help you track down the 
problem.

What the configure script is doing is generating test code which it 
compiles to see if it can find various libraries that are needed.So for 
example to see if ti can find the OpenGL library it generates code which 
calls glNewList (a function that must be in the library). It compiles 
and links that code and if works then it found the library.

So the /usr/include/GL won't afect this since it's about libraries, not 
include files. You need to find the location of libraries and ensure the 
-L compiler flag sets the path to search for those libraries e.g. if 
they are in /usr/local/lib then you need a -L /usr/local/lib so that 
-lMesaGL flag will find the /usr/local/lib/libMesa.sl library (name 
probably is different, like I said I don't know much about specifics on 
different machines).

Hopefully that is some help.

   Cheers,

Stuart.


Felipe De La Puente wrote:
> Hello guys, I'm using Ubuntu 8.04 with nvidia drivers 169.12 and 
> Kernel 2.6.24-16 in a AMD64 machine, and in the "./configure" stage of 
> the building process i got the following error:
>
> configure:6285: checking for pthread_create in -lpthread
> configure:6320: gcc -o conftest -g -O2    conftest.c -lpthread    -lSM 
> -lICE -lXi -lXmu -lXext -lX11  -lm >&5
> /usr/bin/ld: cannot find -lXi
> collect2: ld returned 1 exit status
> configure:6326: $? = 1
> configure: failed program was:
> | /* confdefs.h.  */
> | #define PACKAGE_NAME ""
> | #define PACKAGE_TARNAME ""
> | #define PACKAGE_VERSION ""
> | #define PACKAGE_STRING ""
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE "plib"
> | #define VERSION "1.8.5"
> | /* end confdefs.h.  */
> |
> | /* Override any GCC internal prototype to avoid an error.
> |    Use char because int might match the return type of a GCC
> |    builtin and then its argument prototype would still apply.  */
> | #ifdef __cplusplus
> | extern "C"
> | #endif
> | char pthread_create ();
> | int
> | main ()
> | {
> | return pthread_create ();
> |   ;
> |   return 0;
> | }
> configure:6344: result: no
>
>
> And the following:
>
> configure:6428: checking for glNewList in -lMesaGL
> configure:6463: gcc -o conftest -g -O2    conftest.c -lMesaGL    -lSM 
> -lICE -lXi -lXmu -lXext -lX11  -lm >&5
> /usr/bin/ld: cannot find -lMesaGL
> collect2: ld returned 1 exit status
> configure:6469: $? = 1
> configure: failed program was:
> | /* confdefs.h.  */
> | #define PACKAGE_NAME ""
> | #define PACKAGE_TARNAME ""
> | #define PACKAGE_VERSION ""
> | #define PACKAGE_STRING ""
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE "plib"
> | #define VERSION "1.8.5"
> | /* end confdefs.h.  */
> |
> | /* Override any GCC internal prototype to avoid an error.
> |    Use char because int might match the return type of a GCC
> |    builtin and then its argument prototype would still apply.  */
> | #ifdef __cplusplus
> | extern "C"
> | #endif
> | char glNewList ();
> | int
> | main ()
> | {
> | return glNewList ();
> |   ;
> |   return 0;
> | }
> configure:6487: result: no
> configure:6497: error: could not find working GL library
>
> I have executed ./configure --prefix=/usr/local --with-GL=/usr because 
> I have the directory /usr/include/GL.
>
> Hope anyone can help, I'll really apreciate it.
>
> Greetings, Felipe.
>
>
> PS: I've attached the config.log file.
> PS2: I have installed all the libgl1-mesa-dev, libgl1-mesa-dri, 
> libgl1-mesa-glx, libglu1-mesa, libglu1-mesa-dev, and almost *mesa* 
> packages.
> -- 
> ATTE:
> Hernán Felipe De la Puente Christen
> Móvil: 093199807
> ICQ : 58547127
> MSN : fde...@gm... <mailto:fde...@gm...>
> Web : http://www.udec.cl/%7Ehdelapuente
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> ------------------------------------------------------------------------
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
>   

Re: [Plib-users] plib fnt bug

[Fay J. F Dr C. U. 46 S. <joh...@eg...>]

Paul,

	While the bug tracker is the appropriate place to file bugs,
there hasn't been a lot of activity on the PLIB site lately and in fact
the mailing lists are probably a better choice.

	I doubt that there is a guide for porting TexFont to PLIB.  I'm
probably more familiar with the "fnt" library than most people, though,
and while I'm a bit busy right now I am certainly willing to answer
questions and help when I can.

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Paul Wise
Sent: Tuesday, April 15, 2008 12:18 AM
To: pli...@li...
Subject: [Plib-users] plib fnt bug

Hi all,

I'm porting Chromium BSU from Mark J. Kilgard's non-free[1] TexFont code
to plib's fnt library. The first issue I came across was that the plib
fnt code does not store and use the max descent value for the font and
it stores the max ascent value in a field called max_height. In TexFont,
max_ascent - max_descent is returned by the txfStringHeight function.
I've filed a bug about this at [2].

I'm wondering if the tracker is the right place to file bugs?

I'm wondering if there is a guide to porting TexFont code to plib? The
rest of the TexFont functions used by Chromium BSU are txfStringLength,
txfRenderString and txfBindFontTexture. 

     1. http://bugs.debian.org/467123
     2. http://sf.net/support/tracker.php?aid=1942632

-- 
bye,
pabs

http://pabs.zip.to

[Plib-users] plib fnt bug

[Paul W. <pa...@bo...>]

Hi all,

I'm porting Chromium BSU from Mark J. Kilgard's non-free[1] TexFont code
to plib's fnt library. The first issue I came across was that the plib
fnt code does not store and use the max descent value for the font and
it stores the max ascent value in a field called max_height. In TexFont,
max_ascent - max_descent is returned by the txfStringHeight function.
I've filed a bug about this at [2].

I'm wondering if the tracker is the right place to file bugs?

I'm wondering if there is a guide to porting TexFont code to plib? The
rest of the TexFont functions used by Chromium BSU are txfStringLength,
txfRenderString and txfBindFontTexture. 

     1. http://bugs.debian.org/467123
     2. http://sf.net/support/tracker.php?aid=1942632

-- 
bye,
pabs

http://pabs.zip.to

[Plib-users] Portability issue in plib 1.8.4 class netAddress

[Miguel L. S. R. <mi...@an...>]

Hi,

I've just joined this list to find out more about this issue.
I've come across plib several times as it is used as a base for several other
projects.
In this case, I came across this problem when trying to get FlightGear to work on FreeBSD;
whenever I tried to have it create a socket, it failed. I found out that it was failing with
the following error: Address family not supported by protocol family.
That's the message for EAFNOSUPPORT.

So, I checked the file src/net/netSocket.h in the underlaying plib-1.8.4, and found out
that a wrapper class is being used for sockaddr_in, the netAddress class (line 50 of the said
file).
I was a bit chocked by seeing that the layout of a structure which is supposed to be
internal to the OS was being reproduced in the layout of netAddress. The code is
as follows:

class netAddress
{
  /* DANGER!!!  This MUST match 'struct sockaddr_in' exactly! */
  short          sin_family     ;
  unsigned short sin_port       ;
  unsigned int   sin_addr       ;
  char           sin_zero [ 8 ] ;

Well, I cannot guess what reason took plib's designers to choose this strategy,
it would seem safer to me if a member variable of the type sockaddr_in existed inside
the netAddress class.
That way, the code would be protected from any differences in the layout of
sockaddr_in of different OSes.
All I can say is that in FreeBSD, the layout of sockaddr_in does not match that
structure. On FreeBSD, we have:

/* Socket address, internet style. */
struct sockaddr_in {
        uint8_t sin_len;
        sa_family_t     sin_family;
        in_port_t       sin_port;
        struct  in_addr sin_addr;
        char    sin_zero[8];
};

Of course, FreeBSD headers themselves are isolated from changes in the types
sa_family_t, etc... In practice, the only thing that differs is that the
two byte sin_family member is split into two members of one byte each, sin_len
and sin_family.
Because the i386 is a LSB first machine, filling the sin_family member of the
netAddress class will end up filling the sin_len member of sockaddr_in instead
of the sin_family member.

Therefore, any operations involving plib-1.8.4, AF_INET sockets and FreeBSD 7
fail with EAFNOSUPPORT. QED.

For my part, I would be happier if this would change, so I could play FlightGear
right out-of-the-ports-collection. Anyway, I'm curious about the rationale
behind this design issue. Could it be to avoid including OS specific headers?


Greetings,

Miguel Ramos
Lisboa, Portugal

Re: [Plib-users] R: Problem with a PUI-Win32-Native

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

The calls to "puMouse" on lines 133 and 140 have a first argument of one; 
which is defined (see pu.h, line 37) to be the middle mouse button.  The 
active mouse button for the menu defaults to the left mouse button, which 
has a value of zero.  The "WM_LBUTTONDOWN" and "WM_LBUTTONUP" blocks should 
call "puMouse ( PU_LEFT_BUTTON, ...".  Here is what the section of code 
will look like if all three buttons are supported:

	case WM_LBUTTONDOWN:
		oldMousePos.x = currentMousePos.x = LOWORD (lParam);
		oldMousePos.y = currentMousePos.y = HIWORD (lParam);
		if( puMouse ( PU_LEFT_BUTTON, PU_DOWN, currentMousePos.x, 
currentMousePos.y ))
		{ }//MessageBox(NULL,"DOWN","down",MB_OK); }
		break;

	case WM_LBUTTONUP:
		currentMousePos.x = LOWORD (lParam);
		currentMousePos.y = HIWORD (lParam);
		if( puMouse ( PU_LEFT_BUTTON, PU_UP, currentMousePos.x, currentMousePos.y 
))
		{}// MessageBox(NULL,"UP","UP",MB_OK); }
		break;

	case WM_MBUTTONDOWN:
		oldMousePos.x = currentMousePos.x = LOWORD (lParam);
		oldMousePos.y = currentMousePos.y = HIWORD (lParam);
		if( puMouse ( PU_MIDDLE_BUTTON, PU_DOWN, currentMousePos.x, 
currentMousePos.y ))
		{ }//MessageBox(NULL,"DOWN","down",MB_OK); }
		break;

	case WM_MBUTTONUP:
		currentMousePos.x = LOWORD (lParam);
		currentMousePos.y = HIWORD (lParam);
		if( puMouse ( PU_MIDDLE_BUTTON, PU_UP, currentMousePos.x, 
currentMousePos.y ))
		{}// MessageBox(NULL,"UP","UP",MB_OK); }
		break;

	case WM_RBUTTONDOWN:
		oldMousePos.x = currentMousePos.x = LOWORD (lParam);
		oldMousePos.y = currentMousePos.y = HIWORD (lParam);
		if( puMouse ( PU_RIGHT_BUTTON, PU_DOWN, currentMousePos.x, 
currentMousePos.y ))
		{ }//MessageBox(NULL,"DOWN","down",MB_OK); }
		break;

	case WM_RBUTTONUP:
		currentMousePos.x = LOWORD (lParam);
		currentMousePos.y = HIWORD (lParam);
		if( puMouse ( PU_RIGHT_BUTTON, PU_UP, currentMousePos.x, 
currentMousePos.y ))
		{}// MessageBox(NULL,"UP","UP",MB_OK); }
		break;

The button box appears not to have a callback defined.

	- John

-----Original Message-----
From:	pos...@ca...
Sent:	Friday, February 29, 2008 8:54 AM
To:	PLIB Users
Subject:	Re: [Plib-users] R: Problem with a PUI-Win32-Native


> I'm not a PUI user so I don't know if this could be useful, yet in your 
code
> I reported below:
>
> 	case WM_LBUTTONDOWN:
> 		oldMousePos.x = currentMousePos.x = LOWORD (lParam);
> 		oldMousePos.y = currentMousePos.y = HIWORD (lParam);
> 		if( puMouse ( 1, PU_DOWN, currentMousePos.x,
> currentMousePos.y ))
> 	==>>	//{ }//MessageBox(NULL,"DOWN","down",MB_OK); }
> 		isMouseActive = true;
>
> Looking at the pointed line, are you sure you want to set isMouseActive =
> true when the call to puMouse returns 1? This is what actually happens 
since
> the subject line is commented out. Which is different, I see, from the
> similar code line for the button up case.
>
> Paolo
>

Thanks. You are right. The line was twice commented. However this boolean
controled only the activation of the later drawn triangle manipulator.
I discarded the calls to the gl drawings and manipulation in the following 
code
(below), keeping only PUI renderings. The problem remains : the PUI display
correcly, yet no callbacks.

I'm wondering about this warning in the documentation :

"[...] #define PU_USE_NATIVE before you include pu.h - and PUI will try to
figure out what it needs to know using native commands such as those in the
wgl/glX/agl library - in the absence of a windowing library. This may 
result in
"some problems" if you want to do "certain operations" for which PUI needs 
to
query the windowing library. Use of PU_USE_NATIVE is not recommended in 
systems
that allow you to resize the window or open multiple windows."

Re: [Plib-users] R: Problem with a PUI-Win32-Native

[<pos...@ca...>]

> I'm not a PUI user so I don't know if this could be useful, yet in your code
> I reported below:
>
> 	case WM_LBUTTONDOWN:
> 		oldMousePos.x = currentMousePos.x = LOWORD (lParam);
> 		oldMousePos.y = currentMousePos.y = HIWORD (lParam);
> 		if( puMouse ( 1, PU_DOWN, currentMousePos.x,
> currentMousePos.y ))
> 	==>>	//{ }//MessageBox(NULL,"DOWN","down",MB_OK); }
> 		isMouseActive = true;
>
> Looking at the pointed line, are you sure you want to set isMouseActive =
> true when the call to puMouse returns 1? This is what actually happens since
> the subject line is commented out. Which is different, I see, from the
> similar code line for the button up case.
>
> Paolo
>

Thanks. You are right. The line was twice commented. However this boolean
controled only the activation of the later drawn triangle manipulator.
I discarded the calls to the gl drawings and manipulation in the following code
(below), keeping only PUI renderings. The problem remains : the PUI display
correcly, yet no callbacks.

I'm wondering about this warning in the documentation :

"[...] #define PU_USE_NATIVE before you include pu.h - and PUI will try to
figure out what it needs to know using native commands such as those in the
wgl/glX/agl library - in the absence of a windowing library. This may result in
"some problems" if you want to do "certain operations" for which PUI needs to
query the windowing library. Use of PU_USE_NATIVE is not recommended in systems
that allow you to resize the window or open multiple windows."


/* a problem with a pui win32 native application */
#pragma comment ( lib, "fnt.lib" )
#pragma comment ( lib, "pui.lib" )
#pragma comment ( lib, "sg.lib" )
#pragma comment ( lib, "ul.lib" )

#define PU_USE_NATIVE
#include <plib/pu.h>
#include<windows.h>
#include<gl/gl.h>
#include<gl/glu.h>

void Render();
bool InitializeGL();

HDC g_HDC;

int gWidth = 0;
int gHeight = 0;

void button_cb	(puObject *) {MessageBox(NULL,"ok","ok",MB_OK);}
void foo_cb		(puObject *) {MessageBox(NULL,"foo","foo",MB_OK);}
void bar_cb		(puObject *) {MessageBox(NULL,"bar","bar",MB_OK);}
void exit_cb	(puObject *) {exit(0);}

char      *file_submenu   [] = { "Exit","foo","bar", NULL } ;
puCallback file_submenu_cb[] = { exit_cb, foo_cb, bar_cb, NULL } ;
char * PUIlabels[5] = { "Label1", "Label2", "This is Label3", "Four", NULL } ;

puMenuBar * menu;
puOneShot *b;
puButtonBox * checkList;

void SetupPixelFormat(HDC hDC)
{
	int nPixelFormat;

	static PIXELFORMATDESCRIPTOR pfd = {
		sizeof(PIXELFORMATDESCRIPTOR),   // size of structure.
			1,                               // always 1.
			PFD_DRAW_TO_WINDOW |             // support window
			PFD_SUPPORT_OPENGL |             // support OpenGl
			PFD_DOUBLEBUFFER,                // support double buffering
			PFD_TYPE_RGBA,                   // support RGBA
			16,                              // bit color mode
			0, 0, 0, 0, 0, 0,                // ignore color bits
			0,                               // no alpha buffer
			0,                               // ignore shift bit
			0,                               // no accumulation buffer
			0, 0, 0, 0,                      // ignore accumulation bits.
			16,                              // number of depth buffer bits.
			0,                               // number of stencil buffer bits.
			0,                               // 0 means no auxiliary buffer
			PFD_MAIN_PLANE,                  // The main drawing plane
			0,                               // this is reserved
			0, 0, 0 };                       // layer masks ignored.

		// this chooses the best pixel format and returns index.
		nPixelFormat = ChoosePixelFormat(hDC, &pfd);

		// This set pixel format to device context.
		SetPixelFormat(hDC, nPixelFormat, &pfd);
}


LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
	static HGLRC hRC;                      // Rendering context.
	static HDC hDC;                        // Device context.
	int width, height;                     // The window width and height.
	static POINT oldMousePos;              // Last mouse position.
	static POINT currentMousePos;          // Current mouse position.
	static bool isMouseActive;             // Is the left mouse button down.

	switch(message)
	{
	case WM_CREATE:                  // Windows creation.
		hDC = GetDC(hwnd);            // This gets the device context for our window.
		g_HDC = hDC;                  // Assigns the global device context to this
one.
		SetupPixelFormat(hDC);        // Call the pixel format function.

		hRC = wglCreateContext(hDC);  // Creates the rendering context.
		wglMakeCurrent(hDC, hRC);     // Makes the rendering context.
		return 0;
		break;

	case WM_CLOSE:                   // Close message.
	case WM_DESTROY:
		wglMakeCurrent(hDC, NULL);
		wglDeleteContext(hRC);        // Deletes the rendering context.

		PostQuitMessage(0);           // Says close the program.
		return 0;
		break;

	case WM_SIZE:                    // re-size message.
		height = HIWORD(lParam);      // This gets the height of the window.
		width = LOWORD(lParam);       // This gets the width of the window.

		if(height == 0)               // we don't want it to be possible for a
		{                          // height of 0.  If it is 0 me make it 1.
			height = 1;
		}

		gHeight = height;
		gWidth = width;
		puSetWindowSize ( width, height ) ;
		glViewport(0, 0, width, height);// resets the viewport to new dimensions.
		glMatrixMode(GL_PROJECTION);    // Sets the projection matrix.
		glLoadIdentity();               // Reset the modelview matrix.

		// calculate the aspect ratio of the window.
		gluPerspective(45.0f, (GLfloat)width/(GLfloat)height, 0.1f, 1000.0f);

		glMatrixMode(GL_MODELVIEW);
		glLoadIdentity();

		return 0;
		break;

	case WM_KEYDOWN:
		switch(wParam)
		{
			case VK_ESCAPE:
				PostQuitMessage(0);
				break;
		}
		break;

	case WM_LBUTTONDOWN:
		oldMousePos.x = currentMousePos.x = LOWORD (lParam);
		oldMousePos.y = currentMousePos.y = HIWORD (lParam);
		if( puMouse ( 1, PU_DOWN, currentMousePos.x, currentMousePos.y ))
		{ }//MessageBox(NULL,"DOWN","down",MB_OK); }
		break;

	case WM_LBUTTONUP:
		currentMousePos.x = LOWORD (lParam);
		currentMousePos.y = HIWORD (lParam);
		if( puMouse ( 1, PU_UP, currentMousePos.x, currentMousePos.y ))
		{}// MessageBox(NULL,"UP","UP",MB_OK); }
		break;

	case WM_MOUSEMOVE:
		currentMousePos.x = LOWORD (lParam);
		currentMousePos.y = HIWORD (lParam);
		oldMousePos.x = currentMousePos.x;
		oldMousePos.y = currentMousePos.y;
		puMouse(currentMousePos.x,currentMousePos.y);
		break;

	default: break;
	}

	// What this does is pass all of the unhandled messages to DefWindowProc
	return (DefWindowProc(hwnd, message, wParam, lParam));
}

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int nShowCmd)
{
	MSG msg;                                        // A message variable.
	WNDCLASSEX windowClass;                         // Your Window class.
	HWND hwnd;                                      // The Window handle.
	bool isFinished;                                // True then exit.

	windowClass.cbSize = sizeof(WNDCLASSEX);        // size of the WNDCLASSEX
structure.
	windowClass.style = CS_HREDRAW | CS_VREDRAW;    // style of the window.
	windowClass.lpfnWndProc = WndProc;              // Address to the windows
procedure.
	windowClass.cbClsExtra = 0;                     // Extra class information.
	windowClass.cbWndExtra = 0;                     // Extra window information.
	windowClass.hInstance = hInstance;              // Handle of application
Instance.
	windowClass.hIcon = LoadIcon(NULL, IDI_APPLICATION);// Handle of application
Icon.
	windowClass.hCursor = LoadCursor(NULL, IDC_ARROW);// mouse cursor
	windowClass.hbrBackground = NULL;               // background color.
	windowClass.lpszMenuName = NULL;                // name of the main menu.
	windowClass.lpszClassName = "puitest";// window class name.
	windowClass.hIconSm = LoadIcon(NULL, IDI_APPLICATION);// icon when minimized.

	if(!RegisterClassEx(&windowClass)) return 0;

	// Create the window.
	hwnd = CreateWindowEx(NULL,// The extended window style.
		"puitest",// window Class name.
		"a problem",// window name.
		WS_OVERLAPPEDWINDOW | WS_VISIBLE |// The window style.
		WS_SYSMENU | WS_CLIPCHILDREN |// window style.
		WS_CLIPSIBLINGS,// window style.
		100, 100,// window x, y coordinate.
		640, 480,// window width and height.
		NULL,// handle to parent window.
		NULL,// menu.
		hInstance,// handle to app instance.
		NULL);   // pointer to window creation data.

	if(!hwnd) return 0;

	ShowWindow(hwnd, SW_SHOW);
	UpdateWindow(hwnd);

	isFinished = false;

	if(!InitializeGL()) isFinished = true;

	while(!isFinished)
	{
		if(PeekMessage(&msg, NULL, NULL, NULL, PM_REMOVE))
		{
			if(msg.message == WM_QUIT)
			{
				isFinished = true;
			}
			TranslateMessage(&msg);
			DispatchMessage(&msg);
		}
		else Render();
	}
	return (int)msg.wParam;
}


bool InitializeGL()
{
	puInit ();
	menu	= new puMenuBar(-1);
	menu->add_submenu ( "File", file_submenu, file_submenu_cb ) ;
	menu->close();
	b		= new puOneShot ( 0, 0, "say hello") ;
	b -> setCallback ( button_cb ) ;

	checkList	= new puButtonBox ( 50, 50, 200, 200, PUIlabels, 0 ) ;

	glClearColor(0.6f, 0.6f, 0.8f, 0.0f);  // Clear the screen to black.
	glShadeModel(GL_SMOOTH);
	glEnable(GL_DEPTH_TEST);
	return true;
}


void Render()
{
	glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
	glLoadIdentity();

	puDisplay ();

	SwapBuffers(g_HDC);
}

[Plib-users] R: Problem with a PUI-Win32-Native

[Paolo L. <p.l...@ci...>]

I'm not a PUI user so I don't know if this could be useful, yet in your code
I reported below:

	case WM_LBUTTONDOWN:
		oldMousePos.x = currentMousePos.x = LOWORD (lParam);
		oldMousePos.y = currentMousePos.y = HIWORD (lParam);
		if( puMouse ( 1, PU_DOWN, currentMousePos.x,
currentMousePos.y ))
	==>>	//{ }//MessageBox(NULL,"DOWN","down",MB_OK); }
		isMouseActive = true;
		break;

	case WM_LBUTTONUP:
		currentMousePos.x = LOWORD (lParam);
		currentMousePos.y = HIWORD (lParam);
		if( puMouse ( 1, PU_UP, currentMousePos.x, currentMousePos.y
))
		{}// MessageBox(NULL,"UP","UP",MB_OK); }
		isMouseActive = false;
		break;

Looking at the pointed line, are you sure you want to set isMouseActive =
true when the call to puMouse returns 1? This is what actually happens since
the subject line is commented out. Which is different, I see, from the
similar code line for the button up case.

Paolo


> -----Messaggio originale-----
> Da: pli...@li... 
> [mailto:pli...@li...] Per conto 
> di pos...@ca...
> Inviato: venerdì 29 febbraio 2008 0.58
> A: pli...@li...
> Oggetto: [Plib-users] Problem with a PUI-Win32-Native
> 
> Hi all,
> 
> I integrated plib into my GLUT-based application. It works 
> GREAT. I'm one more happy user in my sandbox.
> 
> Now, problem arises when integrating inside a WIN32 
> application, whose windows does (and will, probably) not be 
> wrapped with GLUT.
> 
> The following code below, using basis example, illustrates 
> the problem :
> a device context gets created, some opengl is painted inside, 
> and the gui (a button and a menu) gets called.
> 
> Running the application : the gui shows up.
> when I check if a gui's element is hit by a mouse clic, the 
> puMouse(..) returns correct, identifying wether an element 
> was clicked or not.
> But no objects callbacks occurs and the submenu stays 
> invisible. The menu is hilighted when the mouse points over 
> and the buttonbox can be checked.
> 
> What am I doing wrong ?
> 
> 
> /* PUI - WIN32 - NO GLUT */
> 
> #pragma comment ( lib, "fnt.lib" )
> #pragma comment ( lib, "pui.lib" )
> #pragma comment ( lib, "sg.lib" )
> #pragma comment ( lib, "ul.lib" )
> 
> #define PU_USE_NATIVE
> #include <plib/pu.h>
> #include<windows.h>
> #include<gl/gl.h>
> #include<gl/glu.h>
> 
> void Render();
> bool InitializeGL();
> 
> HDC g_HDC;
> 
> float xRotation = 0.0f;
> float yRotation = 0.0f;
> 
> int gWidth = 0;
> int gHeight = 0;
> 
> 
> void button_cb(puObject *) {MessageBox(NULL,"ok","ok",MB_OK);}
> void foo_cb (puObject *) {MessageBox(NULL,"foo","foo",MB_OK);}
> void bar_cb (puObject *) {MessageBox(NULL,"bar","bar",MB_OK);}
> void exit_cb (puObject *) {exit(0);}
> 
> char      *file_submenu   [] = { "Exit","foo","bar", NULL } ;
> puCallback file_submenu_cb[] = { exit_cb, foo_cb, bar_cb, 
> NULL } ; char * PUIlabels[5] = { "Label1", "Label2", "This is 
> Label3", "Four", NULL } ;
> 
> 
> puMenuBar * menu;
> puOneShot *b;
> puButtonBox * checkList;
> 
> void SetupPixelFormat(HDC hDC)
> {
> 	int nPixelFormat;
> 
> 	static PIXELFORMATDESCRIPTOR pfd = {
> 		sizeof(PIXELFORMATDESCRIPTOR),   // size of structure.
> 			1,                               // always 1.
> 			PFD_DRAW_TO_WINDOW |             // 
> support window
> 			PFD_SUPPORT_OPENGL |             // 
> support OpenGl
> 			PFD_DOUBLEBUFFER,                // 
> support double buffering
> 			PFD_TYPE_RGBA,                   // support RGBA
> 			16,                              // bit 
> color mode
> 			0, 0, 0, 0, 0, 0,                // 
> ignore color bits
> 			0,                               // no 
> alpha buffer
> 			0,                               // 
> ignore shift bit
> 			0,                               // no 
> accumulation buffer
> 			0, 0, 0, 0,                      // 
> ignore accumulation bits.
> 			16,                              // 
> number of depth buffer bits.
> 			0,                               // 
> number of stencil buffer bits.
> 			0,                               // 0 
> means no auxiliary buffer
> 			PFD_MAIN_PLANE,                  // The 
> main drawing plane
> 			0,                               // 
> this is reserved
> 			0, 0, 0 };                       // 
> layer masks ignored.
> 
> 		// this chooses the best pixel format and returns index.
> 		nPixelFormat = ChoosePixelFormat(hDC, &pfd);
> 
> 		// This set pixel format to device context.
> 		SetPixelFormat(hDC, nPixelFormat, &pfd); }
> 
> 
> LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM 
> wParam, LPARAM lParam) {
> 	static HGLRC hRC;                      // Rendering context.
> 	static HDC hDC;                        // Device context.
> 	int width, height;                     // The window 
> width and height.
> 	static POINT oldMousePos;              // Last mouse position.
> 	static POINT currentMousePos;          // Current mouse 
> position.
> 	static bool isMouseActive;             // Is the left 
> mouse button down.
> 
> 	switch(message)
> 	{
> 	case WM_CREATE:                  // Windows creation.
> 		hDC = GetDC(hwnd);            // This gets the 
> device context for our window.
> 		g_HDC = hDC;                  // Assigns the 
> global device context to this
> one.
> 		SetupPixelFormat(hDC);        // Call the pixel 
> format function.
> 
> 		hRC = wglCreateContext(hDC);  // Creates the 
> rendering context.
> 		wglMakeCurrent(hDC, hRC);     // Makes the 
> rendering context.
> 		return 0;
> 		break;
> 
> 	case WM_CLOSE:                   // Close message.
> 	case WM_DESTROY:
> 		wglMakeCurrent(hDC, NULL);
> 		wglDeleteContext(hRC);        // Deletes the 
> rendering context.
> 
> 		PostQuitMessage(0);           // Says close the program.
> 		return 0;
> 		break;
> 
> 	case WM_SIZE:                    // re-size message.
> 		height = HIWORD(lParam);      // This gets the 
> height of the window.
> 		width = LOWORD(lParam);       // This gets the 
> width of the window.
> 
> 		if(height == 0)               // we don't want 
> it to be possible for a
> 		{                          // height of 0.  If 
> it is 0 me make it 1.
> 			height = 1;
> 		}
> 
> 		gHeight = height;
> 		gWidth = width;
> 		puSetWindowSize ( width, height ) ;
> 		glViewport(0, 0, width, height);// resets the 
> viewport to new dimensions.
> 		glMatrixMode(GL_PROJECTION);    // Sets the 
> projection matrix.
> 		glLoadIdentity();               // Reset the 
> modelview matrix.
> 
> 		// calculate the aspect ratio of the window.
> 		gluPerspective(45.0f, 
> (GLfloat)width/(GLfloat)height, 0.1f, 1000.0f);
> 
> 		glMatrixMode(GL_MODELVIEW);
> 		glLoadIdentity();
> 
> 		return 0;
> 		break;
> 
> 	case WM_KEYDOWN:
> 		switch(wParam)
> 		{
> 			case VK_ESCAPE:
> 				PostQuitMessage(0);
> 				break;
> 		}
> 		break;
> 
> 	case WM_LBUTTONDOWN:
> 		oldMousePos.x = currentMousePos.x = LOWORD (lParam);
> 		oldMousePos.y = currentMousePos.y = HIWORD (lParam);
> 		if( puMouse ( 1, PU_DOWN, currentMousePos.x, 
> currentMousePos.y ))
> 		//{ }//MessageBox(NULL,"DOWN","down",MB_OK); }
> 		isMouseActive = true;
> 		break;
> 
> 	case WM_LBUTTONUP:
> 		currentMousePos.x = LOWORD (lParam);
> 		currentMousePos.y = HIWORD (lParam);
> 		if( puMouse ( 1, PU_UP, currentMousePos.x, 
> currentMousePos.y ))
> 		{}// MessageBox(NULL,"UP","UP",MB_OK); }
> 		isMouseActive = false;
> 		break;
> 
> 	case WM_MOUSEMOVE:
> 		currentMousePos.x = LOWORD (lParam);
> 		currentMousePos.y = HIWORD (lParam);
> 		if(isMouseActive)
> 		{
> 			xRotation -= (currentMousePos.x - 
> oldMousePos.x);
> 			yRotation -= (currentMousePos.y - 
> oldMousePos.y);
> 		}
> 		oldMousePos.x = currentMousePos.x;
> 		oldMousePos.y = currentMousePos.y;
> 		puMouse(currentMousePos.x,currentMousePos.y);
> 		break;
> 
> 	default: break;
> 	}
> 
> 	// What this does is pass all of the unhandled messages 
> to DefWindowProc
> 	return (DefWindowProc(hwnd, message, wParam, lParam)); }
> 
> int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE 
> hPrevInstance, LPSTR lpCmdLine, int nShowCmd) {
> 	MSG msg;                                        // A 
> message variable.
> 	WNDCLASSEX windowClass;                         // Your 
> Window class.
> 	HWND hwnd;                                      // The 
> Window handle.
> 	bool isFinished;                                // True 
> then exit.
> 
> 	windowClass.cbSize = sizeof(WNDCLASSEX);        // size 
> of the WNDCLASSEX
> structure.
> 	windowClass.style = CS_HREDRAW | CS_VREDRAW;    // 
> style of the window.
> 	windowClass.lpfnWndProc = WndProc;              // 
> Address to the windows
> procedure.
> 	windowClass.cbClsExtra = 0;                     // 
> Extra class information.
> 	windowClass.cbWndExtra = 0;                     // 
> Extra window information.
> 	windowClass.hInstance = hInstance;              // 
> Handle of application
> Instance.
> 	windowClass.hIcon = LoadIcon(NULL, IDI_APPLICATION);// 
> Handle of application Icon.
> 	windowClass.hCursor = LoadCursor(NULL, IDC_ARROW);// 
> mouse cursor
> 	windowClass.hbrBackground = NULL;               // 
> background color.
> 	windowClass.lpszMenuName = NULL;                // name 
> of the main menu.
> 	windowClass.lpszClassName = "puitest";// window class name.
> 	windowClass.hIconSm = LoadIcon(NULL, 
> IDI_APPLICATION);// icon when minimized.
> 
> 	if(!RegisterClassEx(&windowClass)) return 0;
> 
> 	// Create the window.
> 	hwnd = CreateWindowEx(NULL,// The extended window style.
> 		"puitest",// window Class name.
> 		"a problem",// window name.
> 		WS_OVERLAPPEDWINDOW | WS_VISIBLE |// The window style.
> 		WS_SYSMENU | WS_CLIPCHILDREN |// window style.
> 		WS_CLIPSIBLINGS,// window style.
> 		100, 100,// window x, y coordinate.
> 		640, 480,// window width and height.
> 		NULL,// handle to parent window.
> 		NULL,// menu.
> 		hInstance,// handle to app instance.
> 		NULL);   // pointer to window creation data.
> 
> 	if(!hwnd) return 0;
> 
> 	ShowWindow(hwnd, SW_SHOW);
> 	UpdateWindow(hwnd);
> 
> 	isFinished = false;
> 
> 	if(!InitializeGL()) isFinished = true;
> 
> 	while(!isFinished)
> 	{
> 		if(PeekMessage(&msg, NULL, NULL, NULL, PM_REMOVE))
> 		{
> 			if(msg.message == WM_QUIT)
> 			{
> 				isFinished = true;
> 			}
> 			TranslateMessage(&msg);
> 			DispatchMessage(&msg);
> 		}
> 		else Render();
> 	}
> 	return (int)msg.wParam;
> }
> 
> 
> bool InitializeGL()
> {
> 	puInit ();
> 	menu	= new puMenuBar(-1);
> 	menu->add_submenu ( "File", file_submenu, file_submenu_cb ) ;
> 	menu->close();
> 	b		= new puOneShot ( 0, 0, "say hello") ;
> 	b -> setCallback ( button_cb ) ;
> 
> 	checkList	= new puButtonBox ( 50, 50, 200, 200, 
> PUIlabels, 0 ) ;
> 
> 	glClearColor(0.6f, 0.6f, 0.8f, 0.0f);  // Clear the 
> screen to black.
> 	glShadeModel(GL_SMOOTH);
> 	glEnable(GL_DEPTH_TEST);
> 	return true;
> }
> 
> 
> void Render()
> {
> 	glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
> 	glLoadIdentity();
> 
> 	glTranslatef(0.0f, 0.0f, -5.0f);
> 	glRotatef(-yRotation, 1.0f, 0.0f, 0.0f);
> 	glRotatef(-xRotation, 0.0f, 1.0f, 0.0f);
> 
> 	glBegin(GL_TRIANGLES);
> 	glColor3f(1.0f, 0.0f, 0.0f); glVertex3f(0.0f, 1.0f, 0.0f);
> 	glColor3f(0.0f, 0.0f, 1.0f); glVertex3f(-1.0f, -1.0f, 0.0f);
> 	glColor3f(1.0f, 1.0f, 1.0f); glVertex3f(1.0f, -1.0f, 0.0f);
> 	glEnd();
> 
> 	puDisplay () ;
> 
> 	SwapBuffers(g_HDC);
> }
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft Defy all 
> challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
>