Thread: RE: [Plib-devel] PUI questions
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
|
From: Dave M. <Dav...@dy...> - 2000-07-31 17:47:50
|
John wrote: > I am working on a CFD grid generation program that makes very > heavy use of > PUI. I've had to add several new widgets, multiple-window > capability, and > active-widget callbacks, so I call it "PUI-incremented" > privately. The > program has some 45 windows, averaging one or two dozen > widgets each. I > have just started upgrading it to PUI 1.3.0 (note my previous > posting on > this list about adding multiple-window capabilities). > As for using multiple glut windows, I have mixed feelings. I'm developing for an embedded system that doesn't have support for multiple glut windows. By "multiple interfaces linked together" i mean when you click on a button it takes you to a *new* interface by deleting the *old* interface and creating a new one in the same window. > I haven't used rendering callbacks. My "puLargeInput" is > basically a slider > with a list box (and I use it for file listing and selection), but it > doesn't work quite right and should probably be implemented > differently from > the way I have done it. I'm not sure what you mean by > "multiple interfaces > linked together" but if you mean multiple windows I can > certainly help you. > And I don't know what a python is, aside from a particularly > large snake. > information about python can be found here -- www.python.org. using scripting to drive your interface system is becoming pretty common. i know that PUI is considered fairly static and stable but would anyone mind some refinement of PUI to occur. 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? --Dave |
|
From: Steve B. <sjb...@ai...> - 2000-07-31 23:56:42
|
> 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
|
|
From: John F. F. <joh...@eg...> - 2000-08-01 13:49:40
|
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...
|
|
From: Sam S. <sa...@sp...> - 2000-08-01 16:03:11
|
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 |
|
From: Steve B. <sjb...@ai...> - 2000-08-02 01:48:44
|
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
|
|
From: Dave M. <dp...@ef...> - 2000-08-02 02:17:24
|
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...
|
|
From: Dave M. <dp...@ef...> - 2000-08-02 02:22:14
|
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
|
|
From: Steve B. <sjb...@ai...> - 2000-08-02 07:38:12
|
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
|
|
From: Wolfram K. <w_...@rz...> - 2000-08-02 09:29:02
|
Steve wrote:
> ppeDeleteMeLater ( this ) ;
^^^
LOL.
I see you are dialed into PPE, aren't you ;-) ?
Bye bye,
Wolfram.
|
|
From: Steve B. <sjb...@ai...> - 2000-08-03 01:04:38
|
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
|
|
From: John F. F. <joh...@eg...> - 2000-08-02 13:20:34
|
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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X