plib-devel Mailing List for PLIB (Page 23)
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
(80) |
Mar
(128) |
Apr
(111) |
May
(157) |
Jun
(70) |
Jul
(116) |
Aug
(465) |
Sep
(574) |
Oct
(325) |
Nov
(163) |
Dec
(182) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(167) |
Feb
(191) |
Mar
(319) |
Apr
(118) |
May
(252) |
Jun
(427) |
Jul
(187) |
Aug
(96) |
Sep
(219) |
Oct
(161) |
Nov
(109) |
Dec
(210) |
| 2002 |
Jan
(97) |
Feb
(80) |
Mar
(143) |
Apr
(234) |
May
(72) |
Jun
(246) |
Jul
(155) |
Aug
(280) |
Sep
(418) |
Oct
(81) |
Nov
(72) |
Dec
(88) |
| 2003 |
Jan
(59) |
Feb
(63) |
Mar
(33) |
Apr
(27) |
May
(87) |
Jun
(50) |
Jul
(97) |
Aug
(45) |
Sep
(35) |
Oct
(67) |
Nov
(78) |
Dec
(13) |
| 2004 |
Jan
(167) |
Feb
(144) |
Mar
(172) |
Apr
(93) |
May
(43) |
Jun
(7) |
Jul
(27) |
Aug
(36) |
Sep
(48) |
Oct
(54) |
Nov
(5) |
Dec
(44) |
| 2005 |
Jan
(53) |
Feb
(36) |
Mar
(13) |
Apr
(3) |
May
(19) |
Jun
|
Jul
(49) |
Aug
(39) |
Sep
(8) |
Oct
(8) |
Nov
(51) |
Dec
(23) |
| 2006 |
Jan
(26) |
Feb
(5) |
Mar
(26) |
Apr
(26) |
May
(52) |
Jun
(36) |
Jul
(8) |
Aug
(12) |
Sep
(6) |
Oct
(75) |
Nov
(34) |
Dec
(25) |
| 2007 |
Jan
(46) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(7) |
Jul
(2) |
Aug
|
Sep
(40) |
Oct
(9) |
Nov
(3) |
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
(26) |
Apr
|
May
|
Jun
(2) |
Jul
(4) |
Aug
(6) |
Sep
|
Oct
|
Nov
(5) |
Dec
(2) |
| 2009 |
Jan
(63) |
Feb
(4) |
Mar
(12) |
Apr
|
May
(5) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(14) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
(2) |
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
| 2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Melchior F. <mf...@us...> - 2006-03-30 18:27:25
|
* Fay John F Dr CTR USAF AFSEO/SK -- Thursday 30 March 2006 20:10: > Unfortunately I am CVS-challenged Ahh. OK, that explains it. :-) > Can one of you please send me a current PLIB and test case that > shows what the bug is? I'll send in a minute to the sender address from your message. m. |
|
From: Fay J. F Dr C. U. AFSEO/SK <joh...@eg...> - 2006-03-30 18:12:26
|
Folks, First let me apologize for putting in a buggy commit and not doing anything about it. Unfortunately I am CVS-challenged (my friendly Air Force computer security folks won't let me in or out of SourceForge CVS--even pCVSc stopped working a week or two ago) and I have very few options right now. Can one of you please send me a current PLIB and test case that shows what the bug is? John F. Fay Technical Fellow, Jacobs/Sverdrup TEAS Group 850-729-6330 joh...@eg... -----Original Message----- From: pli...@li... [mailto:pli...@li...] On Behalf Of Melchior FRANZ Sent: Thursday, March 30, 2006 11:06 AM To: pli...@li... Subject: [Plib-devel] Re: [BUG] puComboBox broken since recent puInputBase commit? * Bram Stolk -- Thursday 30 March 2006 18:49: > I don't understand the code, but: [...] I get the impression that the one who broke that only two weeks ago, and should really know best what he broke is completely uninterested in fixing it. I've already wasted some time searching for the cause, and now you waste yours. That's not how it should be. What about just reverting the buggy commit? :-} m. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ plib-devel mailing list pli...@li... https://lists.sourceforge.net/lists/listinfo/plib-devel |
|
From: Melchior F. <mf...@us...> - 2006-03-30 17:05:45
|
* Bram Stolk -- Thursday 30 March 2006 18:49: > I don't understand the code, but: [...] I get the impression that the one who broke that only two weeks ago, and should really know best what he broke is completely uninterested in fixing it. I've already wasted some time searching for the cause, and now you waste yours. That's not how it should be. What about just reverting the buggy commit? :-} m. |
|
From: Bram S. <br...@sa...> - 2006-03-30 16:49:22
|
Melchior FRANZ wrote: > * Bram Stolk -- Thursday 30 March 2006 18:19: > >>But it did strike me that the puComboBox is labelled as 'obsolete', >>and puaXXXX stuff should be used. > > > Whoops, indeed. Sorry. But anyway: just replace puComboBox with > puaComboBox. Doesn't work any better. Same bug. I don't understand the code, but: void puComboBox::setCurrentItem ( const char *item_ptr ) needs an extra line: input -> setValue ( item_ptr ) ; This seems to work, although it does not refresh the graphics. And a puPostRefresh does not help. bram |
|
From: Melchior F. <mf...@us...> - 2006-03-30 16:28:07
|
* Bram Stolk -- Thursday 30 March 2006 18:19: > But it did strike me that the puComboBox is labelled as 'obsolete', > and puaXXXX stuff should be used. Whoops, indeed. Sorry. But anyway: just replace puComboBox with puaComboBox. Doesn't work any better. Same bug. m. |
|
From: Bram S. <br...@sa...> - 2006-03-30 16:19:24
|
Melchior FRANZ wrote: > Attached. It's derived from simple.cxx. With a plib from before the > puInputBase changes (about two or three weeks back), the input field > is updated if you select an entry from the popup. With HEAD it isn't. > > Hmm... that code remains to be a bit obscure to me. But it did strike me that the puComboBox is labelled as 'obsolete', and puaXXXX stuff should be used. Diffing cvs revisions is difficult now: cvs seems to be down. SF CVS service is very shakey. svn service is a little better. Bram |
|
From: Melchior F. <mf...@us...> - 2006-03-28 16:52:33
|
* Bram Stolk -- Tuesday 28 March 2006 18:19:
> Melchior FRANZ wrote:
> > It looks like the recent puInput{,Base} commit broke comboboxes?
> > Can someone check (and fix :-)? Selecting a puPopupMenu entry
> > doesn't update the puInput any more.
> Do you have a test sample?
Attached. It's derived from simple.cxx. With a plib from before the
puInputBase changes (about two or three weeks back), the input field
is updated if you select an entry from the popup. With HEAD it isn't.
> I never understood "widget_list" from examples/src/pui
> If I start that, it opens a gazzillion windows, none of which
> are responsive.
I've well understood that it's meant to be as useless as it is. I really
wonder why there's no application that demonstrates all available widgets.
m.
|
|
From: Fay J. F Dr C. U. AFSEO/SK <joh...@eg...> - 2006-03-28 16:25:26
|
The "wdiget_list" demo was designed to provide a sample of every PUI widget
so that I could get a screenshot for the documentation. They were never
meant to be responsive. I should probably include that in a comment in the
program.
John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-729-6330
joh...@eg...
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Bram Stolk
Sent: Tuesday, March 28, 2006 10:19 AM
To: pli...@li...
Subject: Re: [Plib-devel] [BUG] puComboBox broken since recent puInputBase
commit?
Melchior FRANZ wrote:
> It looks like the recent puInput{,Base} commit broke comboboxes?
> Can someone check (and fix :-)? Selecting a puPopupMenu entry doesn't
> update the puInput any more. (The breakage is not caused by the puAux
> changes, including the virtual getters.)
Do you have a test sample?
I never understood "widget_list" from examples/src/pui If I start that, it
opens a gazzillion windows, none of which are responsive. Is that the same
for others?
thx
bram
|
|
From: Bram S. <br...@sa...> - 2006-03-28 16:18:53
|
Melchior FRANZ wrote:
> It looks like the recent puInput{,Base} commit broke comboboxes?
> Can someone check (and fix :-)? Selecting a puPopupMenu entry
> doesn't update the puInput any more. (The breakage is not caused
> by the puAux changes, including the virtual getters.)
Do you have a test sample?
I never understood "widget_list" from examples/src/pui
If I start that, it opens a gazzillion windows, none of which
are responsive. Is that the same for others?
thx
bram
>
> m.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
--
Bram Stolk, VR Engineer SARA, Amsterdam. tel +31 20 592 3000
"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit
operating system originally coded for a 4-bit microprocessor by a 2-bit
company that can't stand 1 bit of competition."
|
|
From: Jan R. <slo...@gm...> - 2006-03-27 18:02:28
|
Am Mon, 27 Mar 2006 07:55:47 -0600 schrieb Fay John F Dr CTR USAF AFSEO/SK <joh...@eg...>: > I am all in favor of finally removing the deprecated widgets. > Perhaps after that (and any new changes that people have waiting in the > wings?) we should make a new release of PLIB. There hasn't been one for a > couple of years. That would be great. I'd really like to use the new scrollable list widget in CRRCsim. Like in FG we currently maintain our own scrollable list code in our CVS. But before, could maybe someone apply the patch I submitted to this list on 2005-12-18 (fixes loading of .x files in SSG)? I've attached it for your convenience. List of all changes: 1.) When loading an .x file, all materials will be stored in a globalMaterialList, but the materials are never added to the LoaderWriterMesh. I've added a fix to ssgLoadX.cxx that adds the created SimpleStates to the mesh. 2.) Second bugfix is for the mesh handler itself. There's a global variable currentDiffuse that holds the most recent diffuse colour found by the ASCII parser. Now when composing the final SSG branch, all leafs not containing a colour array will be set to this variable's value. This is, in fact, the colour that was defined last in whatever file we were parsing. But this is wrong, the right diffuse colour is located in the SimpleState that is used to draw the leaf. Therefore we have to create the colour array with that value. To understand the effect of this bug, here's what I experienced while bug-hunting: I used a .x airplane model which contained 5 materials. All materials but the last one were opaque, only the last (used to draw the propeller disc) was 80% translucent. This caused the whole model to look 80% translucent because the model did not contain any per-vertex or per-face colour values, only the colours defined by the materials (and the GL_COLOR_MATERIAL mode). 3.) I've encountered a lot of .x files that feature a texture coordinate array which is formatted ... u1;v1; u2;v2; ... instead of ... u1;v1;, u2;v2;, ... The current parser won't work without the commas. My fix removes the comma-check and makes the parser simply search for the next float value. I've tested all fixes with my own application and with the pview example. Thanks in advance! Jan R. -- Jan Reucker email: jan dot reucker at web dot de web: http://www.reucker-online.de |
|
From: Mathias <Mat...@gm...> - 2006-03-27 17:32:53
|
On Monday 27 March 2006 10:10, Bram Stolk wrote: > applied Thanks Mathias =2D-=20 Mathias Fr=F6hlich, email: Mat...@gm... |
|
From: Fay J. F Dr C. U. AFSEO/SK <joh...@eg...> - 2006-03-27 13:58:24
|
Folks, My CFD application uses the puAux bislider-with-ends and the slider-with-input widgets in several places. Unfortunately Google isn't likely to tell you much about it. I am all in favor of finally removing the deprecated widgets. Perhaps after that (and any new changes that people have waiting in the wings?) we should make a new release of PLIB. There hasn't been one for a couple of years. Possibly we should make the "puObject" functions virtual and deprecate the workarounds? John F. Fay Technical Fellow, Jacobs/Sverdrup TEAS Group 850-729-6330 joh...@eg... -----Original Message----- From: pli...@li... [mailto:pli...@li...] On Behalf Of Bram Stolk Sent: Friday, March 24, 2006 6:04 PM To: pli...@li... Subject: Re: [Plib-devel] [BUG] & non-virtual methods (that should be virtual) Melchior FRANZ wrote: > Thanks Bram for committing. And here are two less exciting problems: > > (A) PUCLASS definitions in puAux.h: > > #define PUCLASS_FILESELECTOR 0x00040000 /* Because FilePicker is obsolete */ > #define PUCLASS_BISLIDER 0x00080000 > [...] > #define PUCLASS_SPINBOX 0x02000000 > #define PUCLASS_SCROLLBAR 0x04000000 > > Until here this is redundant. It's just copied from pu.h and may cause > compiler warnings, as pu.h is also included on top of puAux.h. > I'd remove that or comment it out if it's desirable to keep for > documentation purposes. But this is less of a cosmetic problem: > > #define PUCLASS_BISLIDERWITHENDS 0x02000000 // -> 0x08000000 > #define PUCLASS_SLIDERWITHINPUT 0x04000000 // -> 0x10000000 > > Huh? Look above in the redundant part! These two numbers are already > used! Should be changed to the numbers in the comments, no? Looks like mistake. But I guess it goes unnoticed, because nobody seems to use these special sliders. E.g., they are not used in ./examples, and google shows little reference too them. > > #define PUCLASS_COMPASS 0x08000000 // -> 0x20000000 > #define PUCLASS_CHOOSER 0x10000000 // -> 0x40000000 > #define PUCLASS_LIST 0x20000000 // -> 0x80000000 > > Yes, now we've filled up all bits. But shouldn't classes finally be > removed after having been tagged "depreciated" for *many* years? > This would make some room again. :-) > I guess so. > > (B) puaList::getListStringValue() and puaList::getListIntegerValue () > > These two methods shouldn't have to be there! They are, because > puObject::getStringValue() and puObject::getIntegerValue() etc. are > for some reason not made virtual in pu.h. So we couldn't redefine them > in a derived class and still access them via ((puObject *)foo)->getStringValue(). > But how else would we access the value of a child in a composite > widget, other than by redefining the getters and returning this child value? > These extra getters break the interface cleanliness. I suggest to fix > that in pu.h, and remove this abnormality. (I can send a patch to make > clearer what I suggest. :-) > Your suggestion sounds right, but the funcs already made their way into flightgear source, according to google. So maybe make getXxxValue() virtual, override, and keep the workaround with a warning mesg? Also: I want to get rid of those destructors that should have been virtual,but are not: psl.h:59: warning: 'class pslNumber' has virtual functions but non-virtual destructor psl.h:133: warning: 'class pslVariable' has virtual functions but non-virtual destructor psl.h:253: warning: 'class pslValue' has virtual functions but non-virtual destructor psl.h:59: warning: 'class pslNumber' has virtual functions but non-virtual destructor psl.h:133: warning: 'class pslVariable' has virtual functions but non-virtual destructor psl.h:253: warning: 'class pslValue' has virtual functions but non-virtual destructor psl.h:59: warning: 'class pslNumber' has virtual functions but non-virtual destructor psl.h:133: warning: 'class pslVariable' has virtual functions but non-virtual destructor psl.h:253: warning: 'class pslValue' has virtual functions but non-virtual destructor I'll fix the virtual thing in cvs, Bram > m. > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language that extends applications into web and mobile media. Attend > the live webcast and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=1216 > 42 _______________________________________________ > plib-devel mailing list > pli...@li... > https://lists.sourceforge.net/lists/listinfo/plib-devel ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ plib-devel mailing list pli...@li... https://lists.sourceforge.net/lists/listinfo/plib-devel |
|
From: Bram S. <br...@sa...> - 2006-03-27 08:10:30
|
Mathias Fröhlich wrote: > Hi All, > > This attached little patch is required to make plib compile with gcc-4.1 on > fedora core 5. > Please apply ... applied > |
|
From: Melchior F. <mf...@us...> - 2006-03-26 17:21:54
|
It looks like the recent puInput{,Base} commit broke comboboxes?
Can someone check (and fix :-)? Selecting a puPopupMenu entry
doesn't update the puInput any more. (The breakage is not caused
by the puAux changes, including the virtual getters.)
m.
|
|
From: Mathias <Mat...@gm...> - 2006-03-26 12:46:12
|
Hi All,
This attached little patch is required to make plib compile with gcc-4.1 on=
=20
fedora core 5.
Please apply ...
Thanks
Mathias
=2D-=20
Mathias Fr=C3=B6hlich, email: Mat...@gm...
|
|
From: Melchior F. <mf...@us...> - 2006-03-25 00:18:20
|
* Bram Stolk -- Saturday 25 March 2006 01:04: > Melchior FRANZ wrote: > But I guess it goes unnoticed, because nobody seems to use > these special sliders. E.g., they are not used in ./examples, > and google shows little reference too them. True. When there's no way to see how they look and what they do, then many people don't bother to try them out. The puaList class can't have been used much either. It caused a linking error. Or was it just because it was so broken. :-) > Your suggestion sounds right, but the funcs already made their way > into flightgear source, according to google. That's not a problem. I am FlightGear's (inofficial) GUI maintainer, and it's our own puList class that became puaList. We are still using our own copy, but I'd like to switch to puaList after the next release. We don't rely on those ugly getList*Value() methods. You can rip them out and make the getters virtual. > So maybe make getXxxValue() > virtual, override, and keep the workaround with a warning mesg? No, just remove them! But the getters need to be made virtual in pu.h! > I want to get rid of those destructors that should have been > virtual,but are not: Don't sound familiar. No side effects on FlightGear. m. |
|
From: Bram S. <br...@sa...> - 2006-03-25 00:01:41
|
Melchior FRANZ wrote: > Thanks Bram for committing. And here are two less exciting problems: > > (A) PUCLASS definitions in puAux.h: > > #define PUCLASS_FILESELECTOR 0x00040000 /* Because FilePicker is obsolete */ > #define PUCLASS_BISLIDER 0x00080000 > [...] > #define PUCLASS_SPINBOX 0x02000000 > #define PUCLASS_SCROLLBAR 0x04000000 > > Until here this is redundant. It's just copied from pu.h and may > cause compiler warnings, as pu.h is also included on top of puAux.h. > I'd remove that or comment it out if it's desirable to keep for > documentation purposes. But this is less of a cosmetic problem: > > #define PUCLASS_BISLIDERWITHENDS 0x02000000 // -> 0x08000000 > #define PUCLASS_SLIDERWITHINPUT 0x04000000 // -> 0x10000000 > > Huh? Look above in the redundant part! These two numbers are already > used! Should be changed to the numbers in the comments, no? Looks like mistake. But I guess it goes unnoticed, because nobody seems to use these special sliders. E.g., they are not used in ./examples, and google shows little reference too them. > > #define PUCLASS_COMPASS 0x08000000 // -> 0x20000000 > #define PUCLASS_CHOOSER 0x10000000 // -> 0x40000000 > #define PUCLASS_LIST 0x20000000 // -> 0x80000000 > > Yes, now we've filled up all bits. But shouldn't classes finally > be removed after having been tagged "depreciated" for *many* years? > This would make some room again. :-) > I guess so. > > (B) puaList::getListStringValue() and puaList::getListIntegerValue () > > These two methods shouldn't have to be there! They are, because > puObject::getStringValue() and puObject::getIntegerValue() etc. are for > some reason not made virtual in pu.h. So we couldn't redefine them in > a derived class and still access them via ((puObject *)foo)->getStringValue(). > But how else would we access the value of a child in a composite widget, > other than by redefining the getters and returning this child value? > These extra getters break the interface cleanliness. I suggest to fix > that in pu.h, and remove this abnormality. (I can send a patch to make > clearer what I suggest. :-) > Your suggestion sounds right, but the funcs already made their way into flightgear source, according to google. So maybe make getXxxValue() virtual, override, and keep the workaround with a warning mesg? Also: I want to get rid of those destructors that should have been virtual,but are not: psl.h:59: warning: 'class pslNumber' has virtual functions but non-virtual destructor psl.h:133: warning: 'class pslVariable' has virtual functions but non-virtual destructor psl.h:253: warning: 'class pslValue' has virtual functions but non-virtual destructor psl.h:59: warning: 'class pslNumber' has virtual functions but non-virtual destructor psl.h:133: warning: 'class pslVariable' has virtual functions but non-virtual destructor psl.h:253: warning: 'class pslValue' has virtual functions but non-virtual destructor psl.h:59: warning: 'class pslNumber' has virtual functions but non-virtual destructor psl.h:133: warning: 'class pslVariable' has virtual functions but non-virtual destructor psl.h:253: warning: 'class pslValue' has virtual functions but non-virtual destructor I'll fix the virtual thing in cvs, Bram > m. > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > plib-devel mailing list > pli...@li... > https://lists.sourceforge.net/lists/listinfo/plib-devel |
|
From: Melchior F. <mf...@us...> - 2006-03-24 22:46:59
|
Thanks Bram for committing. And here are two less exciting problems: (A) PUCLASS definitions in puAux.h: #define PUCLASS_FILESELECTOR 0x00040000 /* Because FilePicker is obsolete */ #define PUCLASS_BISLIDER 0x00080000 [...] #define PUCLASS_SPINBOX 0x02000000 #define PUCLASS_SCROLLBAR 0x04000000 Until here this is redundant. It's just copied from pu.h and may cause compiler warnings, as pu.h is also included on top of puAux.h. I'd remove that or comment it out if it's desirable to keep for documentation purposes. But this is less of a cosmetic problem: #define PUCLASS_BISLIDERWITHENDS 0x02000000 // -> 0x08000000 #define PUCLASS_SLIDERWITHINPUT 0x04000000 // -> 0x10000000 Huh? Look above in the redundant part! These two numbers are already used! Should be changed to the numbers in the comments, no? #define PUCLASS_COMPASS 0x08000000 // -> 0x20000000 #define PUCLASS_CHOOSER 0x10000000 // -> 0x40000000 #define PUCLASS_LIST 0x20000000 // -> 0x80000000 Yes, now we've filled up all bits. But shouldn't classes finally be removed after having been tagged "depreciated" for *many* years? This would make some room again. :-) (B) puaList::getListStringValue() and puaList::getListIntegerValue () These two methods shouldn't have to be there! They are, because puObject::getStringValue() and puObject::getIntegerValue() etc. are for some reason not made virtual in pu.h. So we couldn't redefine them in a derived class and still access them via ((puObject *)foo)->getStringValue(). But how else would we access the value of a child in a composite widget, other than by redefining the getters and returning this child value? These extra getters break the interface cleanliness. I suggest to fix that in pu.h, and remove this abnormality. (I can send a patch to make clearer what I suggest. :-) m. |
|
From: Bram S. <br...@sa...> - 2006-03-24 22:04:29
|
Melchior FRANZ wrote: > Could someone please review the attached patch and consider to commit Tested, and committed to cvs bram |
|
From: Melchior F. <mf...@us...> - 2006-03-24 18:12:45
|
Could someone please review the attached patch and consider to commit it? It fixes several problems with puaList. Here's a screenshot of the current behavior on the left, and the fixed one on the right side http://members.aon.at/mfranz/puaList.jpg [20 kB] (1) The size setting is completely wrong. This is because puObject::setSize() can't handle composite widgets: we can't just resize the outmost widget, we also have to reposition/resize the children! (2) the slider width isn't set, and puSlider() uses a value derived of the font, while buttons & scrollbar are set to a fixed (and rather clunky) width. (3) The color settings aren't propagated to the puListBox child, hence we get a really hard to read black font where we should have a white one. (4) The widget does only call the callback function on exit, which makes it barely usable. No actions can be fired on list selection. This patch: - adds a puaList::setSize() function that repositions all child widgets - adds puaList::setColour{,Scheme} that sets the puListBox colors - lets puListBox actions fire puaList callbacks - sets the slider size correctly, and to a sane size - makes the slider size settable via optional argument (like in puaLargeInput) - fixes a bug that returned a pointer to invalid memory in getListStringValue(), which caused crashes - removes an undefined method from the puaList class that breaks linking The last point will be topic of another message, together with another bug. :-) m. |
|
From: Joerg H. <jo...@lu...> - 2006-03-22 22:08:15
|
Hi all,
I posted this question to plib-users a few weeks ago, but didn't receive
any replies. Since I think this is a potential bug in plib, I hope that
someone here can help me.
As background: I recently ported part of an application from SDL to
plib, but I have some problems related to keyboard handling: it appears
that sometimes key events get lost, or are buffered - I guess those
issues are related (it's not the well known dead key problem of the
keyboard):
1) Immediately after starting my plib test program, I press 'up',
and after a few seconds (without releasing arrow up) pressing
'left'. Often (though not always) there will be no 'left'
event recognised by pw.
Once I release the left key, and press it again, everything works
fine (just for the record: I don't press more than these two keys,
so I don't think that this is related to dead keys when pressing
four keys).
I printed the events inside pwX11, and:
- sometimes no key event at all gets delivered for the first
time I press and release 'left'
- sometimes I only get a "key release" event, without any previous
"key press" event for the 'left' key.
2) I noticed as well that some of the menus are very slow to react.
After some searching I again printed the events inside the event
loop of pwX11.
While my application updates the frames roughly every 0.03 seconds,
sometimes events get not delivered at once, but are delayed, and
after some time suddenly all events get delivered in the same call to
the event handler, e.g. I press and release 'down', 'down',
'up'. I get the event:
press 'down'
The nothing for 'some time', while I release
the key, press 'down' again, release 'down', press 'up'.
Then suddenly there are three events reported in the event loop at
the same time.
Now, I was convinced that this was an error in my application, but after
some tests I noticed that the original tuxkart sometimes (though not as
common as my test program) has the same problem '1' : the kart does not
turn left (or right) the first time I press left while accelerating
(tuxkart version: 0.40).
My system:
centrino (intel, 1.5GHZ), with Linux suse 10.0, plib-1.8.4-6; Xfree
6.8.2, kernel: 2.6.13-15.
I tested the latest plib cvs version as well - same problem.
I had the same issues on an Intel 64 bit desktop (with similar suse 10.0
64 bit installation), but on an AMD 64 bit dual core (same suse
installation) I don't see this problem.
Any ideas what might be responsible for this? And how to avoid it?
Any help and hints would be appreciated!
Best regards,
Joerg
--
----------------------------------------------------------------
Joerg Henrichs
Luding Administration
e-mail: jo...@lu...
URL: http://luding.org
|
|
From: Melchior F. <mf...@us...> - 2006-02-24 12:04:18
|
* Melchior FRANZ -- Friday 24 February 2006 13:00: > * Melchior FRANZ -- Tuesday 06 December 2005 13:58: > > The attached patch makes disabled entries 'plain' and frameless. > > Could someone please review and apply this? Gahh ... sorry. I was convinced that it hasn't been applied yet, and didn't bother to check. Silly me. Thanks for applying, then. :-) m. |
|
From: Melchior F. <mf...@us...> - 2006-02-24 12:01:22
|
* Melchior FRANZ -- Tuesday 06 December 2005 13:58: > The attached patch makes disabled entries 'plain' and frameless. Could someone please review and apply this? m. |
|
From: <coz...@gm...> - 2006-02-09 04:26:03
|
Hello, I'm not really an expert on the issue, but I would advice you to try the PLIB in cvs, and see if your CH Fighterstick USB works fine with it. If it doesn't I guess someone with some hardware similar to yours might be able t= o write a patch. 2006/2/7, =C1kos Mar=F3y <da...@ty...>: > Hi, > > I just got a CH Fighterstick USB, and wanted to take it for a spin with > FlightGear, which uses plib. I started to check on the joystick with > js_demo that comes with FlightGear. > > To my surprise, js_demo does not recognize the yoke movements of the > FighterStick - even though it sees the button presses. Also, if I have > an additional CH Pro Pedal connected, that is recognized properly. > > I talked to the FlightGear people, and they told me to contact the plib > crew regarding this issue. so here I am. > > [...] -Coz |
|
From: <da...@ty...> - 2006-02-07 18:08:07
|
Hi,
I just got a CH Fighterstick USB, and wanted to take it for a spin with
FlightGear, which uses plib. I started to check on the joystick with
js_demo that comes with FlightGear.
To my surprise, js_demo does not recognize the yoke movements of the
FighterStick - even though it sees the button presses. Also, if I have
an additional CH Pro Pedal connected, that is recognized properly.
I talked to the FlightGear people, and they told me to contact the plib
crew regarding this issue. so here I am.
I'm running Gentoo Linux, kernel 2.6.13, I have plib 1.8.4 installed.
Some additional info:
$ /usr/sbin/lsusb
Bus 004 Device 002: ID 049f:0086 Compaq Computer Corp.
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 005: ID 068e:00f3 CH Products, Inc.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
$ js_demo
Joystick test program.
~~~~~~~~~~~~~~~~~~~~~~
Joystick 0: "CH PRODUCTS CH FIGHTERSTICK USB "
Joystick 1 not detected
Joystick 2 not detected
Joystick 3 not detected
Joystick 4 not detected
Joystick 5 not detected
Joystick 6 not detected
Joystick 7 not detected
+--------------------JS.0----------------------+
| Btns Ax:0 Ax:1 Ax:2 Ax:3 Ax:4 |
+----------------------------------------------+
| 0000 +0.0 +0.0 +0.0 +0.0 +0.0 . . . |
with the primary fire button pressed, it says:
| 0001 +0.0 +0.0 +0.0 +0.0 +0.0 . . . |
if I have the pedal plugged in as well:
$ /usr/sbin/lsusb
Bus 004 Device 002: ID 049f:0086 Compaq Computer Corp.
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 006: ID 068e:0501 CH Products, Inc. CH Pro Pedals
Bus 002 Device 005: ID 068e:00f3 CH Products, Inc.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
$ js_demo
Joystick test program.
~~~~~~~~~~~~~~~~~~~~~~
Joystick 0: "CH PRODUCTS CH FIGHTERSTICK USB "
Joystick 1: "CH Products CH Pro Pedals USB Rudder Pedals "
Joystick 2 not detected
Joystick 3 not detected
Joystick 4 not detected
Joystick 5 not detected
Joystick 6 not detected
Joystick 7 not detected
+--------------------JS.0----------------------+--------------------JS.1----------------------+
| Btns Ax:0 Ax:1 Ax:2 Ax:3 Ax:4 | Btns Ax:0 Ax:1 Ax:2
|
+----------------------------------------------+----------------------------------------------+
| 0000 +0.0 +0.0 +0.0 +0.0 +0.0 . . . | 0000 -0.4 -1.0 -0.2 .
. . . . |
what could be wrong?
Akos
|
34 messages has been excluded from this view by a project administrator.
