plib-devel

RE: [Plib-devel] Is PUI skinable/themeable?

[Fay J. F C. AAC/W. <joh...@eg...>]

Oliver,

	The PUI widgets can be modified extensively, to the point that you
can define your own rendering callback actually to draw them.  But besides
that, you can set the legend font, the label font, the rendering style, the
colors, the border thickness, and probably some more that I can't remember
right now.

	Can you tell me more about "SVG based GUI objects?"

John F. Fay
joh...@eg...
850-729-6330 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Oliver C.
Sent: Sunday, October 17, 2004 10:46 PM
To: pli...@li...
Subject: [Plib-devel] Is PUI skinable/themeable?

Hello,

i have some question about PUI.


I would like to use PUI for a game, but the
standard widget dialogs, that can be watched with the example tools in the 
plib directory are too ugly for a game but a nice looking gui is a must for
a 
modern game.
So the question is, is PUI skinable/themeable?

If the answer is no, can this feature be added to PUI?

If you decide to add such feature i want to mention,
that it would also be very great to be able to use also SVG based
vector graphics for the GUI objects instead of just only simple bitmaps 
like it is common at todays other GUI librarys.
Because PUI is allready using OpenGL having support for
SVG based GUI objects would be IMHO a great win win situation for PUI
and Plib, no other game library has such a feature.
The big advantage about using SVG for a themable GUI is, 
that the file size for a complete theme would be very small compared to
a theme which is using bitmaps and because SVG is a vector format it 
could be rendered by OpenGL with hardware acceleration and would allways
look 
good at every screen size.
So what do you think about a themeable/skinable PUI library that would use
SVG 
as a  theme format?


Then i have another last question because their were some
changes in Plib to remove some of the glut dependency in the past.
Does PUI still need the glut library or can it be used without glut?


Best Regards,
 Oliver C.



















-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] Status of Plib 2.0?

[Oliver C. <kre...@gm...>]

Hello,


I read in the mailinglist archive the following about Plib 2.0:

http://sourceforge.net/mailarchive/message.php?msg_id=1463559

> Other things I"d like to see in 2.0 are:
>  
>    1) Replace SL with OpenAL - write a "compatibility layer" to make
>       existing SL applications run on top of OpenAL.  I"d like to
>       wean people off SL and onto OpenAL so we don"t have to support
>       it anymore.
>  
>    2) Arrange that the SL music player work as an OpenAL audio source.
>  
>    3) Hack into the SL music player to allow other MOD-like sound files to
>       be played.
>  
>    4) Integrate sound nodes into the SSG scene graph to make full use
>       of OpenAL"s 3D audio capabilities.

What is the status of these 4 planned features?

Best Regards,
 Oliver C.

[Plib-devel] Is PUI skinable/themeable?

[Oliver C. <kre...@gm...>]

Hello,

i have some question about PUI.


I would like to use PUI for a game, but the
standard widget dialogs, that can be watched with the example tools in the 
plib directory are too ugly for a game but a nice looking gui is a must for a 
modern game.
So the question is, is PUI skinable/themeable?

If the answer is no, can this feature be added to PUI?

If you decide to add such feature i want to mention,
that it would also be very great to be able to use also SVG based
vector graphics for the GUI objects instead of just only simple bitmaps 
like it is common at todays other GUI librarys.
Because PUI is allready using OpenGL having support for
SVG based GUI objects would be IMHO a great win win situation for PUI
and Plib, no other game library has such a feature.
The big advantage about using SVG for a themable GUI is, 
that the file size for a complete theme would be very small compared to
a theme which is using bitmaps and because SVG is a vector format it 
could be rendered by OpenGL with hardware acceleration and would allways look 
good at every screen size.
So what do you think about a themeable/skinable PUI library that would use SVG 
as a  theme format?


Then i have another last question because their were some
changes in Plib to remove some of the glut dependency in the past.
Does PUI still need the glut library or can it be used without glut?


Best Regards,
 Oliver C.

[Plib-devel] Tabs and trailing blanks

[Fay J. F C. AAC/W. <joh...@eg...>]

Gentlemen,

	It seems that I am unable to communicate with Wolfram Kuss
directly--something about his server not being able to resolve my address.
I sent the modified files to Steve Baker last night but I don't know if he
is planning to do anything with them.

	Does anybody object to having the tabs converted to blanks and
having trailing blank spaces taken out?  If nobody objects, is anybody
willing to put the files into CVS for me?  While we're putting files into
CVS, I think Frederic Bouvier also has a patch--which should be a higher
priority than mine.

John F. Fay
joh...@eg...
850-729-6330 

Re: [Plib-devel] Windows joystick problem

[Frederic B. <fre...@fr...>]

Frederic Bouvier a =E9crit :

> Hi,
>
> the last change to jsWindows.cxx by /smokydiamond/ here :
> http://cvs.sourceforge.net/viewcvs.py/plib/plib/src/js/jsWindows.cxx?r1=
=3D1.4&r2=3D1.5=20
>
>
> is giving me an error when running FlightGear. I am getting tons of
> messages like this :
>
> PLIB_JS: Wrong num_axes. Joystick input is now invalid
>
> indicating that the program goes line 251. This is a default case of a
> switch on the number of axis and 16, which is the value of num_axes
> initialized with _JS_MAX_AXES line 129, is not listed as a valid case.
>
> Could someone restore line 129 with its previous wording :
>
> num_axes =3D _JS_MAX_AXES_WIN
>
> or include 'case 16:' ( or 'case _JS_MAX_AXES:' ) in the switch beginin=
g
> line 204

Could someone apply the patch below to CVS in order to restore windows=20
joystick functionality.
Thank you very much.

-Fred

cvs -z4 -q diff -u jsWindows.cxx (in directory=20
I:\FlightGear\cvs\plib\src\js\)
Index: jsWindows.cxx
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/plib/plib/src/js/jsWindows.cxx,v
retrieving revision 1.5
diff -u -r1.5 jsWindows.cxx
--- jsWindows.cxx    21 Sep 2004 11:45:55 -0000    1.5
+++ jsWindows.cxx    7 Oct 2004 21:47:48 -0000
@@ -126,7 +126,7 @@
     // X,Y,Z,R,U,V,POV - not necessarily the first n of these.
     if ( os->jsCaps.wCaps & JOYCAPS_HASPOV )
     {
-      num_axes =3D _JS_MAX_AXES ;
+      num_axes =3D _JS_MAX_AXES_WIN ;
       min [ 7 ] =3D -1.0 ; max [ 7 ] =3D 1.0 ;  // POV Y
       min [ 6 ] =3D -1.0 ; max [ 6 ] =3D 1.0 ;  // POV X
     }

Re: [Plib-devel] defered display lists

[Erik H. <er...@eh...>]

I've been busy with the latest release of FlightGear, but here is an 
updated patch.

It would be nice if the proposed patches get included in plib a some 
point since most of the binary releases of FlightGear are now build 
using a patched version of the latest CVS version of plib.

Erik

BTW. This patch isn't really necessary for FlightGear anymore, but it 
might be helpful for other projects as well.

[Plib-devel] White Space in PLIB

[Fay J. F C. AAC/W. <joh...@eg...>]

Gentlemen,

	Due to a case of illness and fatigue (I was sick and tired of having
tabs expand my lines of code across the page) I have gone through the PLIB
sources and made two sets of changes:

	- I converted all the tab characters into blank spaces.  While I
tried very hard to preserve the proper indentation, I may have messed it up
in some of the files.  If you find that your code has suddenly lost its
proper indentation, please accept my apologies.  If it is too much for you
to fix yourself, please tell me the file name(s) and I will fix it.
	- I removed all the blank spaces at the ends of lines.  Please don't
put any more in.

I have sent the changed sources to Wolfram Kuss to put into CVS for me
(thank you in advance, Wolfram).

	If anybody objects to these changes please speak up.

John F. Fay
joh...@eg...
850-729-6330 

Re: [Plib-devel] defered display lists

[Erik H. <er...@eh...>]

Erik Hofman wrote:
> Steve Baker wrote:
> 
>> Erik Hofman wrote:
>>
>>> Are there any objections to adding a defered display list method (by 
>>> creating a new function call useDList() that creates the display list 
>>> for that particular leaf node the first time when the 
>>> ssgVtxTable::draw method is called?
>>
>>
>>
>> I can't think of any obvious problems.
> 
> 
> Ok, here is the patch.

Oops, I noticed a problem with this one:


>  #ifdef _SSG_USE_DLIST
> +  if ( generate_dlist )
> +  {
> +    makeDList () ;
> +    generate_dlist = 0 ;

These two lines have to be inverted.


>  #ifdef _SSG_USE_DLIST
> +  if ( generate_dlist )
> +  {
> +    makeDList () ;
> +    generate_dlist = 0 ;

Just like these.


Erik

Re: [Plib-devel] defered display lists

[Erik H. <er...@eh...>]

Steve Baker wrote:
> Erik Hofman wrote:
> 
>> Are there any objections to adding a defered display list method (by 
>> creating a new function call useDList() that creates the display list 
>> for that particular leaf node the first time when the 
>> ssgVtxTable::draw method is called?
> 
> 
> I can't think of any obvious problems.

Ok, here is the patch.

Erik

Re: [Plib-devel] [PATCH] crease for ac3d files and speedup

[Mathias <Mat...@gm...>]

Hi,

Sorry for the long delay I was not online that weekend ...

On Samstag 09 Oktober 2004 16:37, Steve Baker wrote:
> Does this patch take care not to merge things if (for example) there is
> a comment or object name attached to one or other of the nodes (or to a
> node that is the parent of one leaf node and not the other)?
>
> Some applications use the comment or model name to tell them to turn
> that node in the scene graph into an LOD or an animation node.
Yep.

All this stuff is done per ac3d-object. So different objects are never merg=
ed=20
together.
Stripping away unused transforms and such things are left to the old=20
ssgFlatten and childs code.
One part of the patch in a slight modification in the strip function to=20
prevent branches with names to be stripped away.
This could happen before and it happend occasionally with a still unpublish=
ed=20
flightgear model I have on my private disk. Now fixed ...

I did that patch with flightgear in mind. Flightgear uses the object names =
for=20
animations. Looking at all that happy people who tried that patch with the=
=20
improved framerates together with flightgear during that weekend, I think=20
this is ok :)

   Greetings

          Mathias

=2D-=20
Mathias Fr=F6hlich, email: Mat...@gm...

Re: [Plib-devel] differed display lists

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

Erik Hofman wrote:

> Are there any objections to adding a differed display list method (by 
> creating a new function call useDList() that creates the display list 
> for that particular leaf node the first time when the ssgVtxTable::draw 
> method is called?

I can't think of any obvious problems.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] differed display lists

[Erik H. <er...@eh...>]

Hi,

For FlightGear we are hitting to a problem where ssgLeaf nodes are 
initialized in one thread and rendered in another. Normally this 
wouldn't be a problem, but when using display lists (by calling 
makeDList()) you will be executing OpenGL calls in two different threads 
now.

Are there any objections to adding a differed display list method (by 
creating a new function call useDList() that creates the display list 
for that particular leaf node the first time when the ssgVtxTable::draw 
method is called?

Erik

Re: [Plib-devel] [PATCH] crease for ac3d files and speedup

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

Mathias Fr=F6hlich wrote:

>>This needs to be tracked down - recaclulating bounding spheres
>>needlessly will *cripple* performance.
>=20
> Yep.
>=20
> Better support for that crease thing and the speedup gain from that cha=
nge is=20
> it worth anyway.

Does this patch take care not to merge things if (for example) there is
a comment or object name attached to one or other of the nodes (or to a
node that is the parent of one leaf node and not the other)?

Some applications use the comment or model name to tell them to turn
that node in the scene graph into an LOD or an animation node.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++=

-----END GEEK CODE BLOCK-----

[Plib-devel] Re: [Flightgear-devel] [PATCH] crease for ac3d files and speedup

[Mathias <Mat...@gm...>]

Hi,

During digging for that adf.ac stuff I have done some minor adjustmens to t=
hat=20
patch.
Things like not storing texture coordinate arrays when there is no texture=
=20
attached to that object and such.

The updated patch is attached.

Wolfram, this is the current one :)

    Greetings and Thanks

           Mathias

=2D-=20
Mathias Fr=C3=B6hlich, email: Mat...@gm...

Re: [Plib-devel] [PATCH] crease for ac3d files and speedup

[Mathias <Mat...@gm...>]

On Freitag 08 Oktober 2004 21:08, Steve Baker wrote:
> Mathias Fr=F6hlich wrote:
> > But not for functions only operating on ssg*'s datastructures like
> > ssgVtxTable::getNumColours(), ssgBranch::recalcBSphere(),
>
> If recalcBSphere is being called in an otherwise static scene, there
> is something very seriously wrong - either with the application or
> with SSG.
Very true.
But, one for one ...
:)

> The fact that:
> > ssgEntity::dirtyBSphere(),
>
> ...is also in your top ten list says there is certainly some kind of
> a bug.  The only time the bsphere should be dirtied is for the
> (presumably rare) moving models and things that move vertices
> around outside of SSG.   Since moving models are usually put into
> the tree very near the top in most applications, those are very
> unlikely to cause much CPU time consumption.
>
> This needs to be tracked down - recaclulating bounding spheres
> needlessly will *cripple* performance.
Yep.

Better support for that crease thing and the speedup gain from that change =
is=20
it worth anyway.

   Greetings

           Mathias

=2D-=20
Mathias Fr=F6hlich, email: Mat...@gm...

Re: [Plib-devel] [PATCH] crease for ac3d files and speedup

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

Mathias Fr=F6hlich wrote:

> But not for functions only operating on ssg*'s datastructures like=20
> ssgVtxTable::getNumColours(), ssgBranch::recalcBSphere(),

If recalcBSphere is being called in an otherwise static scene, there
is something very seriously wrong - either with the application or
with SSG.

The system is only supposed to recalc the bounding sphere if it's
been 'dirtied' by changing a low level vertex or moving a Transform
node.

The fact that:

> ssgEntity::dirtyBSphere(),

=2E..is also in your top ten list says there is certainly some kind of
a bug.  The only time the bsphere should be dirtied is for the
(presumably rare) moving models and things that move vertices
around outside of SSG.   Since moving models are usually put into
the tree very near the top in most applications, those are very
unlikely to cause much CPU time consumption.

This needs to be tracked down - recaclulating bounding spheres
needlessly will *cripple* performance.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++=

-----END GEEK CODE BLOCK-----

Re: [Plib-devel] [PATCH] crease for ac3d files and speedup

[Mathias <Mat...@gm...>]

On Freitag 08 Oktober 2004 15:43, Steve Baker wrote:
> Mathias Fr=F6hlich wrote:
> > During the past days I have done some profiling on flightgear. One final
> > outcome of that work was, that most time is spent in ssg routines (yes,
> > ssg not OpenGL!!).
>
> That's because you have a graphics card that executes almost 100% of Open=
GL
> functions off on separate hardware.  When you eliminate OpenGL, what other
> functions could possibly consume much time?   It has to be SSG - so that
> comes as no suprise at all.
Yep, this is right for functions like ssgLeaf::draw_geometry or ssgLeaf::dr=
aw.=20
I had expected to see them on the top of the profile list.

But not for functions only operating on ssg*'s datastructures like=20
ssgVtxTable::getNumColours(), ssgBranch::recalcBSphere(),=20
ssgEntity::dirtyBSphere(), ssgVtxTable::getNumTexCoords(),=20
ssgVtxTable::getNumVertices() and ssgVtxTable::getNumNormals(). Which are a=
ll=20
in the top ten of that profile run.
They account that much because of the amount of leaf nodes with only few=20
vertices in each node.

   Greetings

            Mathais

=2D-=20
Mathias Fr=F6hlich, email: Mat...@gm...

Re: [Plib-devel] [PATCH] crease for ac3d files and speedup

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

Mathias wrote:

>
>Hi all,
>
>During the past days I have done some profiling on flightgear. One final=
=20
>outcome of that work was, that most time is spent in ssg routines (yes, =
ssg=20
>not OpenGL!!). The problems are the huge amount of small leaf nodes we =
get=20
>from the ac file loader.=20

Yes. Actually some loaders like the MDL loader are even worse, if you
save out a normal CFS1 model directly after reading it from MDL into
an ascii format it can well be a GB (not a MB) in size! My fix is
simply to call the function to merge all hierachy nodes and to then
save as ssg. File size is then normally under a MB. The main reason is
simply that there are about 1000 times more nodes than needed.

Of course this HUGE overhead slows down rendering a lot.

>As a /sideeffect/ it was now easy to implement the crease tag for ac3d =
files.
>Ac3d models look now the same as in ac3d.

Great!

>Is sombody there with cvs write access to plib? Can somebody apply this =
patch,=20
>please?

If noone else does it, remind me again in a week.

>     Greetings
>
>            Mathias

Bye bye,
Wolfram.

Re: [Plib-devel] [PATCH] crease for ac3d files and speedup

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

Mathias Fr=F6hlich wrote:
> Hi all,
>=20
> During the past days I have done some profiling on flightgear. One fina=
l=20
> outcome of that work was, that most time is spent in ssg routines (yes,=
 ssg=20
> not OpenGL!!).

That's because you have a graphics card that executes almost 100% of Open=
GL
functions off on separate hardware.  When you eliminate OpenGL, what othe=
r
functions could possibly consume much time?   It has to be SSG - so that
comes as no suprise at all.

> The problems are the huge amount of small leaf nodes we get=20
> from the ac file loader. That vertex optimization pass makes this a bit=
=20
> better but there was still room for improovement.

Yep.  It's a perennial problem for flight simulators.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++=

-----END GEEK CODE BLOCK-----

[Plib-devel] Windows joystick problem

[Frederic B. <fre...@fr...>]

Hi,

the last change to jsWindows.cxx by /smokydiamond/ here :
http://cvs.sourceforge.net/viewcvs.py/plib/plib/src/js/jsWindows.cxx?r1=1.4&r2=1.5

is giving me an error when running FlightGear. I am getting tons of
messages like this :

PLIB_JS: Wrong num_axes. Joystick input is now invalid

indicating that the program goes line 251. This is a default case of a
switch on the number of axis and 16, which is the value of num_axes
initialized with _JS_MAX_AXES line 129, is not listed as a valid case.

Could someone restore line 129 with its previous wording :

num_axes = _JS_MAX_AXES_WIN

or include 'case 16:' ( or 'case _JS_MAX_AXES:' ) in the switch begining
line 204

Thanks,
-Fred

[Plib-devel] [PATCH] crease for ac3d files and speedup

[Mathias <Mat...@gm...>]

Hi all,

During the past days I have done some profiling on flightgear. One final=20
outcome of that work was, that most time is spent in ssg routines (yes, ssg=
=20
not OpenGL!!). The problems are the huge amount of small leaf nodes we get=
=20
from the ac file loader. That vertex optimization pass makes this a bit=20
better but there was still room for improovement.

I have now changed the ac3d file loader to first collect all surface elemen=
ts=20
of a leaf object and then split them to a minimum number of leaf nodes=20
according to material and colour properties.

=46or my local setup (radeon 9100, athlon XP 2400+) this gave me a framerat=
e=20
speedup up to 40% (16 fps -> 26fps, for the c172 rendered in a window to no=
t=20
hit the ancient radeons fill rate limit). I would guess that the average=20
speedup is about 25%-30%.

As a /sideeffect/ it was now easy to implement the crease tag for ac3d file=
s.
Ac3d models look now the same as in ac3d.

Attached is a patch to todays plib anoncvs.

Is sombody there with cvs write access to plib? Can somebody apply this pat=
ch,=20
please?

     Greetings

            Mathias

=2D-=20
Mathias Fr=C3=B6hlich, email: Mat...@gm...

[Plib-devel] ASC loader committed

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

I implemented and committed an ASC loader, the writer already existed.
The reason I wrote it is that both 3D Exploration and 3DS Max, using a
plugin are not able to read nodes from an ASC files, if the node only
contains vertices or lines.

While writing it, I improved the loader/writer support code somewhat.

Bye bye,
Wolfram.

RE: [Plib-devel] PUI Mouse Button Problems

[Fay J. F C. AAC/W. <joh...@eg...>]

OK, I am running into a visibility problem.  My popup menu is being hidden
the moment I release the mouse button and I have traced it to
"puPopupMenu.cxx" line 158, which has (implicitly) my name on it.  I think
we have a contradiction here between the needs of the plain popup menu and
the drop-down submenus of the menu bar and the vertical menu.  I have been
able to fix the problem in my application by calling "reveal" at every
iteration but I really shouldn't have to do that.  I think the function
needs some maintenance.

John F. Fay
joh...@eg...
850-729-6330 

 

  _____  

From: pli...@li...
[mailto:pli...@li...] On Behalf Of Fay John F
Contr AAC/WMG
Sent: Tuesday, October 05, 2004 4:08 PM
To: pli...@li...
Subject: RE: [Plib-devel] PUI Mouse Button Problems



The mask is a good idea, but it is going to involve a bit of surgery.  At
the moment the left button defined constant is 0, the middle button is 1,
and the right button is 2.  I would have to change those to 1, 2, and 4, and
make sure nothing breaks.

It doesn't look like it would be too big a deal, though, at least no in PUI
itself.  All the applications would have to be recompiled, though.

Do I hear sounds of a new release floating on the breeze? 

John F. Fay 
joh...@eg... 
850-729-6330 
-----Original Message----- 
From: pli...@li...
[mailto:pli...@li...
<mailto:pli...@li...> ] On Behalf Of Steve Baker 
Sent: Tuesday, October 05, 2004 2:22 PM 
To: pli...@li... 
Subject: Re: [Plib-devel] PUI Mouse Button Problems 

Fay John F Contr AAC/WMG wrote: 
> Is it okay for me to add a feature to PUI to allow the 
> application to set which mouse button it wants the widget callback to be 
> invoked on? 

I think so.  How about having a mask that lets you list all of the 
buttons the widget can be invoked with so you can allow EITHER the 
left OR the right (or the middle...) ? 

---------------------------- Steve Baker ------------------------- 
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...> 
HomePage : http://www.sjbaker.org <http://www.sjbaker.org>  
Projects : http://plib.sf.net <http://plib.sf.net>     http://tuxaqfh.sf.net
<http://tuxaqfh.sf.net>  
            http://tuxkart.sf.net <http://tuxkart.sf.net>
http://prettypoly.sf.net <http://prettypoly.sf.net>  
-----BEGIN GEEK CODE BLOCK----- 
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- 
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ 
-----END GEEK CODE BLOCK----- 



------------------------------------------------------- 
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal 
Use IT products in your business? Tell us what you think of them. Give us 
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more 
http://productguide.itmanagersjournal.com/guidepromo.tmpl
<http://productguide.itmanagersjournal.com/guidepromo.tmpl>  
_______________________________________________ 
plib-devel mailing list 
pli...@li... 
https://lists.sourceforge.net/lists/listinfo/plib-devel
<https://lists.sourceforge.net/lists/listinfo/plib-devel>  

RE: [Plib-devel] PUI Mouse Button Problems

[Fay J. F C. AAC/W. <joh...@eg...>]

The mask is a good idea, but it is going to involve a bit of surgery.  At
the moment the left button defined constant is 0, the middle button is 1,
and the right button is 2.  I would have to change those to 1, 2, and 4, and
make sure nothing breaks.

It doesn't look like it would be too big a deal, though, at least no in PUI
itself.  All the applications would have to be recompiled, though.

Do I hear sounds of a new release floating on the breeze?

John F. Fay
joh...@eg...
850-729-6330 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Steve Baker
Sent: Tuesday, October 05, 2004 2:22 PM
To: pli...@li...
Subject: Re: [Plib-devel] PUI Mouse Button Problems

Fay John F Contr AAC/WMG wrote:
> Is it okay for me to add a feature to PUI to allow the 
> application to set which mouse button it wants the widget callback to be 
> invoked on?

I think so.  How about having a mask that lets you list all of the
buttons the widget can be invoked with so you can allow EITHER the
left OR the right (or the middle...) ?

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] PUI Mouse Button Problems

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

Fay John F Contr AAC/WMG wrote:
> Gentlemen,
> 
>         I am trying to implement a PUI popup menu that is activated by 
> pressing the right mouse button.  It comes up very nicely.  Then when I 
> drag the mouse onto one of the buttons and release the mouse button, it 
> disappears and my callback is not called.  I have traced the problem to 
> the fact that "puButton.cxx" on line 213 checks whether the left mouse 
> button is the one being pressed, and I am having the right mouse button 
> pressed.  Is it okay for me to add a feature to PUI to allow the 
> application to set which mouse button it wants the widget callback to be 
> invoked on?

I think so.  How about having a mask that lets you list all of the
buttons the widget can be invoked with so you can allow EITHER the
left OR the right (or the middle...) ?

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----