freeglut-developer

OK, and Takeshi flagged another error of mine in this change. Perhapse the
two are related? Unfortunately I don't have the original patch at my
fingertips so I can't do the comparison right away.
John F. Fay
850-729-6330
john.fay@...
-----Original Message-----
From: freeglut-cvs-admin@...
[mailto:freeglut-cvs-admin@...] On Behalf Of Sven Panne
Sent: Sunday, April 24, 2005 4:50 PM
To: freeglut-cvs@...
Subject: Re: [Freeglut-cvs] CVS Update: freeglut (branch: trunk)
John F.Fay wrote:
> CVSROOT: /cvsroot/freeglut
> Module name: freeglut
> Repository: freeglut/freeglut/src/
> Changes by: fayjf@...(none) 05/04/22
13:29:55
>
> Log message:
> Yuri D\'Elia\'s changes to the game mode window
>
> Modified files:
> freeglut/freeglut/src/:
> freeglut_gamemode.c
>
> Revision Changes Path
> 1.29 +12 -12 freeglut/freeglut/src/freeglut_gamemode.c
Hmmm, I'm not sure what the effect of this change should actually be, but
game mode is still not working (x86 Linux SuSE 9.2, KDE 3.3.2): The
resolution changes, but there are still window decorations visible and the
virtual screen is slightly bigger than the physical screen (probably by the
amount of the decorations), so one can scroll over the virtual screen when
the mouse hits the physical screen's borders. In a nutshell: To me the
behavious hasn't improved. :-( I tried to get fullscreen/game mode working a
few months ago, but was frustrated by the differing behaviours of all the
window managers... :-( Doing this portably still seems to be a black art
with X11.
Cheers,
S.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid reviews
on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Freeglut-cvs mailing list
Freeglut-cvs@...
https://lists.sourceforge.net/lists/listinfo/freeglut-cvs

Fay John F Contr AAC/WMG wrote:
> In hot pursuit of another bug, I find this change from four
> months ago in which a simple call to "vfprintf" was changed into a macro
> "VFPRINTF" and a check added to "autoconf" for the existence of
> "vfprintf". Unfortunately, this has broken the Windows side which has
> "vfprintf" but does not define "HAVE_VFPRINTF". I propose to add
> something that will define "VFPRINTF" as "vfprintf" for Windows and let
> the rest be strictly non-Windows.
I am not sure how freeglut is supposed to be built on WinDoze. If it is
via the usual automake/autoconf/libtool route (i.e. "configure && make install"),
then this might be a buglet in the configure magic. To fix that, I would need
a log of the configuration phase plus the generated config.h and config.log.
If it is built differently, then it is probably an omission in a VS project
file or something like that. I can't fix the latter, because I only test on
Linux currently.
Cheers,
S.

Gentlemen,
I have just put Takeshi Nishimura's menu fixes into CVS (thank you,
Takeshi for the fixes, and thank you, JC Jones, for the pCVSc upgrades).
I'm not doing very well this morning and I solicit your collective help in
making sure that I have put the fixes in properly. Please take a little
time to get the latest CVS version and check out the menus (and other
things!) before JC cuts Release Candidate 2 tomorrow.
If there are any game mode fixes, now would be a good time to get
them in.
John F. Fay
john.fay@...
850-729-6330
-----Original Message-----
From: freeglut-cvs-admin@...
[mailto:freeglut-cvs-admin@...] On Behalf Of John F.Fay
Sent: Thursday, May 12, 2005 8:01 AM
To: freeglut-cvs@...
Subject: [Freeglut-cvs] CVS Update: freeglut (branch: trunk)
CVSROOT: /cvsroot/freeglut
Module name: freeglut
Repository: freeglut/freeglut/src/
Changes by: fayjf@...(none) 05/05/12
06:00:50
Log message:
Takeshi Nishimura\'s menu changes--menus should now work properly. Use
the GLUT \"GLUTmech\" and \"walker\" demos to test them.
Modified files:
freeglut/freeglut/src/:
freeglut_internal.h freeglut_main.c freeglut_menu.c
Revision Changes Path
1.69 +3 -0 freeglut/freeglut/src/freeglut_internal.h
1.128 +22 -6 freeglut/freeglut/src/freeglut_main.c
1.41 +71 -44 freeglut/freeglut/src/freeglut_menu.c
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Freeglut-cvs mailing list
Freeglut-cvs@...
https://lists.sourceforge.net/lists/listinfo/freeglut-cvs

Sven,
This is an excellent idea and a positive change, but unless the
Windows GCC problem was preventing a release I don't think it is the right
thing to do right now. Now we must either remove the change or issue
another release candidate so people can test it. At the moment I am trying
to get something out the door that is better than "freeglut" 2.2.0. Unless
the Windows GCC problem was quite severe or somebody has found another
show-stopping bug that I haven't heard about, I would ask you please to back
out the changes until we have released 2.4.0. At that point by all means
put them in.
To let you know a couple of other things that are going on, over the
weekend I modified the "demos" workspace under Windows to make two copies of
each demo program, one using the DLL and the other using the static library.
At the moment all the demos use the static library. I also added text to
the "README.Win32" describing how to use "freeglut" if you couldn't or
didn't want to install it. But these changes, positive as they are, are not
going to be in 2.4.0.
I also found that in the CallbackMaker demo, the joystick info is
not updated in the windows until the user moves the mouse or presses a key.
The shapes demo terminates if the user specifies fewer than zero levels in
the Sierpinski sponge. The fixes for these problems are also not going to
be in 2.4.0.
John F. Fay
john.fay@...
850-729-6330
-----Original Message-----
From: freeglut-cvs-admin@...
[mailto:freeglut-cvs-admin@...] On Behalf Of Sven Panne
Sent: Sunday, May 22, 2005 4:46 AM
To: freeglut-cvs@...
Subject: [Freeglut-cvs] CVS Update: freeglut (branch: trunk)
CVSROOT: /cvsroot/freeglut
Module name: freeglut
Repository: freeglut/freeglut/src/
Changes by: spanne@...(none) 05/05/22
02:45:53
Log message:
Guarantee consistency of names/addresses in glutGetProcAddress by
using a macro. In addition, this avoids any non-constant initializer
issues which might be raised when using WinDoze GCCs. The additional
code overhead is negligible, at least for x86 (a few instructions per
name).
Modified files:
freeglut/freeglut/:
ChangeLog
freeglut/freeglut/src/:
freeglut_ext.c
Revision Changes Path
1.75 +5 -0 freeglut/freeglut/ChangeLog
1.16 +152 -150 freeglut/freeglut/src/freeglut_ext.c
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Freeglut-cvs mailing list
Freeglut-cvs@...
https://lists.sourceforge.net/lists/listinfo/freeglut-cvs

Fay John F Contr AAC/WMG wrote:
> This is an excellent idea and a positive change, but unless the
> Windows GCC problem was preventing a release I don't think it is the
> right thing to do right now. Now we must either remove the change or
> issue another release candidate so people can test it. [...]
We can leave it in, because I think we will need another release candidate
anyway: Game mode under X11 is still broken, but I think I have a fix which
I will commit now... :-]
Cheers,
S.

Sven,
Please don't be in a hurry to kill the menu context. Windows
doesn't support more than a specific number of rendering contexts, and
letting each menu have its own context was killing my application. It was a
very subtle bug, too.
John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
john.fay@...
850-729-6330
-----Original Message-----
From: freeglut-cvs-admin@...
[mailto:freeglut-cvs-admin@...] On Behalf Of Sven Panne
Sent: Tuesday, July 05, 2005 6:32 AM
To: freeglut-cvs@...
Subject: [Freeglut-cvs] CVS Update: freeglut (branch: trunk)
CVSROOT: /cvsroot/freeglut
Module name: freeglut
Repository: freeglut/freeglut/src/
Changes by: spanne@...(none) 05/07/05
04:31:58
Log message:
Tiny change to make grep's life easier: Rename the fields of the menu
context. Not really worth a ChangeLog entry...
IMHO it looks like we could kill the whole MenuContext stuff, it is of no
use currently and some things look strange, like e.g. having a context per
menu. The latter is not OK when a menu is attached to multiple windows.
Modified files:
freeglut/freeglut/src/:
freeglut_internal.h freeglut_window.c
Revision Changes Path
1.75 +2 -2 freeglut/freeglut/src/freeglut_internal.h
1.73 +4 -4 freeglut/freeglut/src/freeglut_window.c
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Freeglut-cvs mailing list
Freeglut-cvs@...
https://lists.sourceforge.net/lists/listinfo/freeglut-cvs

Am Dienstag, 5. Juli 2005 16:50 schrieb Fay John F Contr AAC/WMG:
> Please don't be in a hurry to kill the menu context. Windows
> doesn't support more than a specific number of rendering contexts, and
> letting each menu have its own context was killing my application. It was
> a very subtle bug, too.
Rest assured, I won't kill it right now, mainly because I find the whole menu
code a bit confusing so I can't see akk the consequences... :-( What e.g. I
don't understand currently is: Do we *want* to have multiple menus visible in
different windows at the same time? (I guess: No.) Do we *have* to support
having a single menu attached to different windows? (I guess: Yes).
I'm currently just doing a bit of valgrind-ing, cleaning up a few things...
Cheers,
S.

Sven Panne wrote:
> Rest assured, I won't kill it right now, mainly because I find the whole menu
> code a bit confusing so I can't see akk the consequences... :-( What e.g. I
> don't understand currently is: Do we *want* to have multiple menus visible in
> different windows at the same time? (I guess: No.) Do we *have* to support
> having a single menu attached to different windows? (I guess: Yes).
In both cases, I recommend loading up GLUT-classic and seeing what it does
and does not allow. It's not about what we want. We're shooting for GLUT
compatibility here.
-----------------------------------------------------------------------
The second law of Frisbee throwing states: "Never precede any maneuver
by a comment more predictive than "Watch this!"...it turns out that
this also applies to writing Fragment Shaders.
-----------------------------------------------------------------------
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@... http://www.link.com
Home: sjbaker1@... http://www.sjbaker.org

On Wed, Jul 06, 2005 at 09:48:19AM +0200, Sven Panne wrote:
> Am Dienstag, 5. Juli 2005 16:50 schrieb Fay John F Contr AAC/WMG:
> > Please don't be in a hurry to kill the menu context. Windows
> > doesn't support more than a specific number of rendering contexts, and
> > letting each menu have its own context was killing my application. It =
was
> > a very subtle bug, too.
>=20
> Rest assured, I won't kill it right now, mainly because I find the whole =
menu=20
> code a bit confusing so I can't see akk the consequences... :-( What e.g.=
I=20
> don't understand currently is: Do we *want* to have multiple menus visibl=
e in=20
> different windows at the same time? (I guess: No.) Do we *have* to suppor=
t=20
> having a single menu attached to different windows? (I guess: Yes).
The latter definitely works in old GLUT in at least my current X
environment. This has been explicitly documented somewhere, though
perhaps not in the freeglut project.
For the former, I think that that's more to your discretion. In
old GLUT on my current X environment, it is impossible to have
more than one menu up at a time. When I suggested changing the
menu logic in the past, I recall being told that the freeglut
behavior currently is a match for GLUT on WIN32, so...you can
do it either way and claim backwards compatibility.
--=20
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/

Richard Rauch wrote:
> For the former, I think that that's more to your discretion. In
> old GLUT on my current X environment, it is impossible to have
> more than one menu up at a time. When I suggested changing the
> menu logic in the past, I recall being told that the freeglut
> behavior currently is a match for GLUT on WIN32, so...you can
> do it either way and claim backwards compatibility.
Given a free choice, it makes sense to only allow one menu to be up
at a time so that applications behave the same under both OS's.
-----------------------------------------------------------------------
The second law of Frisbee throwing states: "Never precede any maneuver
by a comment more predictive than "Watch this!"...it turns out that
this also applies to writing Fragment Shaders.
-----------------------------------------------------------------------
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@... http://www.link.com
Home: sjbaker1@... http://www.sjbaker.org

On Wed, Jul 06, 2005 at 07:39:58AM -0500, Stephen J Baker wrote:
> Richard Rauch wrote:
>
> >For the former, I think that that's more to your discretion. In
> >old GLUT on my current X environment, it is impossible to have
> >more than one menu up at a time. When I suggested changing the
> >menu logic in the past, I recall being told that the freeglut
> >behavior currently is a match for GLUT on WIN32, so...you can
> >do it either way and claim backwards compatibility.
>
> Given a free choice, it makes sense to only allow one menu to be up
> at a time so that applications behave the same under both OS's.
Perhaps I wasn't writing very clearly.
freeglut menus behave self-consistently on both systems.
I'm not sure how closely that that single behavior matches GLUT on
WIN32; it is quite distant from GLUT on X. If you "fixed" the
freeglut menus to behave as old GLUT did on X ("fix" for *ALL*
target platforms), I think that the freeglut menu logic would be
simpler and less buggy. And would remain as self-consistent across
systems.
But, whatever. Though I was not suggesting splitting the freeglut
menu logic via #ifdef's, it is in any case not my concern. I'm
just offering commentary as someone who's been through most of the
freeglut code at least once (most of it several times, actually)
and who's spent a little while thinking about the menu problems.
--
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/

Sven,
I looked at your change and I see where you fixed a bug of mine--I
had left out an "else" in front of the second "if". And your logic is
definitely nicer.
I do have a request, though, regarding coding style: it is a
personal quirk of mine, but I feel very strongly that curly braces belong on
a line by themselves. It helps me follow the indentation. Would you be so
kind as to reformat the change you put in please?
John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
john.fay@...
850-729-6330
-----Original Message-----
From: freeglut-cvs-admin@...
[mailto:freeglut-cvs-admin@...] On Behalf Of Sven Panne
Sent: Thursday, July 14, 2005 4:39 AM
To: freeglut-cvs@...
Subject: [Freeglut-cvs] CVS Update: freeglut (branch: trunk)
CVSROOT: /cvsroot/freeglut
Module name: freeglut
Repository: freeglut/freeglut/src/
Changes by: spanne@...(none) 05/07/14
02:39:27
Log message:
Fixed the GLUT_CURSOR_INHERIT logic once again...
Note that this commit is untested, but at least it looks better than
before. We really a need a cursor test program.
Modified files:
freeglut/freeglut/:
ChangeLog
freeglut/freeglut/src/:
freeglut_cursor.c
Revision Changes Path
1.103 +2 -0 freeglut/freeglut/ChangeLog
1.32 +5 -5 freeglut/freeglut/src/freeglut_cursor.c
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Freeglut-cvs mailing list
Freeglut-cvs@...
https://lists.sourceforge.net/lists/listinfo/freeglut-cvs

Am Donnerstag, 14. Juli 2005 15:25 schrieb Fay John F Contr AAC/WMG:
> I looked at your change and I see where you fixed a bug of mine--I
> had left out an "else" in front of the second "if". And your logic is
> definitely nicer.
>
> I do have a request, though, regarding coding style: it is a
> personal quirk of mine, but I feel very strongly that curly braces belong
> on a line by themselves. It helps me follow the indentation. Would you be
> so kind as to reformat the change you put in please?
Well, that's the style that *I* strongly prefer, so the answer is: "No"... ;-)
More seriously: I don't think that we have a common style in the sources and
the only way to guarantee it is to do indentation automatically. Perhaps we
can agree on some common style by specifying the arguments to GNU indent?
Probably one of the 3 common styles (GNU/K&R/BSD) plus a few additional flags
perhaps? I stopped arguing about the "better" indentation long ago (apart
from the bad habit of being too minimalistic about braces), but nevertheless
I think it is important to have a consistent style for a project...
Cheers,
S.

On Thu, Jul 14, 2005 at 08:08:38PM +0200, Sven Panne wrote:
> Am Donnerstag, 14. Juli 2005 15:25 schrieb Fay John F Contr AAC/WMG:
> > I looked at your change and I see where you fixed a bug of mine--I
> > had left out an "else" in front of the second "if". And your logic is
> > definitely nicer.
> >
> > I do have a request, though, regarding coding style: it is a
> > personal quirk of mine, but I feel very strongly that curly braces belo=
ng
> > on a line by themselves. It helps me follow the indentation. Would yo=
u be
> > so kind as to reformat the change you put in please?
>=20
> Well, that's the style that *I* strongly prefer, so the answer is: "No"..=
. ;-)=20
> More seriously: I don't think that we have a common style in the sources =
and=20
Actually, the style is very close to uniform (or was when I last worked on
it). Certainly compared to when I started, when indentation was wildy
different...I don't think you could go more than 5 or 10 lines without
seeing a sudden change in indentation.
I worked some months on the codebase to normalize around what looked like
the most common conventions. When I was done, it looked a lot like
the style of some fairly pristine code from Pawel (freeglut's original
author). I think that braces on lines by themselves is part of Pawel's
style.
When I've checked over changes that have appeared since I last worked on
the code, I've noticed a divergence to each author's personal preferences.
> the only way to guarantee it is to do indentation automatically. Perhaps =
we=20
> can agree on some common style by specifying the arguments to GNU indent?=
=20
Some of your developers are using WIN32 and may not easily be able to use
GNU indent, or may forget. Also, the programs aren't guaranteed to always
work reliably; once in a while, I've seen indenters with bugs cause sick
formatting...(^&
I think that thigns like BSD indent or GNU indent are best for mass
conversions of code, not for routine application.
> Probably one of the 3 common styles (GNU/K&R/BSD) plus a few additional f=
lags=20
> perhaps? I stopped arguing about the "better" indentation long ago (apart=
=20
> from the bad habit of being too minimalistic about braces), but neverthel=
ess=20
"Bad" and "too", here, are no more objective than the "right" size
of an indent, etc.
Other than consistency, the only thing I can say objectively is that TABs
are bad in code unless you *know* that everyone reading the code has the
same tab-size (not a practical assumption at all here).
> I think it is important to have a consistent style for a project...
Consistency is the only other absolute.
It's a pity that the code has diverged from that consistency, a little,
but it's not too bad right now.
--=20
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/

Am Mittwoch, 12. Oktober 2005 15:10 schrieb Fay John F Contr AAC/WMG:
> Pardon me, but I thought the "INSTALL" file gave human-readable
> instructions on how to install the libraries. Are the instructions
> repeated somewhere else?
Well, "human-readable" does not imply that it is written by hand (at least not
in our project): Our INSTALL file was an old version of the standard GNU
installation guide from autotools. autogen.sh automagically copies an
up-to-date version of that file into our tree, so it will be in any
distribution. It makes sense for several reasons: Automatically generated
files should never be under version control. Furthermore, the instructions
should fit to the autotools versions used to generate the distribution. This
was not the case before. And a final note: People intending to build things
right from SF's CVS are really supposed to know the GNU INSTALL file by
heart, so there is no need to keep it.
Cheers,
S.

unsubscribe
-----Original Message-----
From: freeglut-developer-admin@...
[mailto:freeglut-developer-admin@...]On Behalf Of Sven
Panne
Sent: 14 October 2005 15:10
To: freeglut-developer@...
Subject: Re: [Freeglut-developer] FW: [Freeglut-cvs] CVS Update:
freeglut (branch: trunk)
Am Mittwoch, 12. Oktober 2005 15:10 schrieb Fay John F Contr AAC/WMG:
> Pardon me, but I thought the "INSTALL" file gave human-readable
> instructions on how to install the libraries. Are the instructions
> repeated somewhere else?
Well, "human-readable" does not imply that it is written by hand (at =
least not=20
in our project): Our INSTALL file was an old version of the standard GNU =
installation guide from autotools. autogen.sh automagically copies an=20
up-to-date version of that file into our tree, so it will be in any=20
distribution. It makes sense for several reasons: Automatically =
generated=20
files should never be under version control. Furthermore, the =
instructions=20
should fit to the autotools versions used to generate the distribution. =
This=20
was not the case before. And a final note: People intending to build =
things=20
right from SF's CVS are really supposed to know the GNU INSTALL file by=20
heart, so there is no need to keep it.
Cheers,
S.
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, =
discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Freeglut-developer mailing list
Freeglut-developer@...
https://lists.sourceforge.net/lists/listinfo/freeglut-developer

felicity hankey wrote:
> unsubscribe
Felicity:
Repeatedly sending the word 'unsubscribe' to this mailing list
will *NEVER* get you unsubscribed.
You absolutely, utterly **MUST** visit the web site below to
unsubscribe. If you fail to do so, I will simply block posts
from you from appearing on the list (to avoid all of these bogus
'unsubscribe' messages from clutting the list) - and you will
continue to get unwanted posts from us.
So *please* stop doing this - and visit this web page:
> https://lists.sourceforge.net/lists/listinfo/freeglut-developer
-----------------------------------------------------------------------
The second law of Frisbee throwing states: "Never precede any maneuver
by a comment more predictive than "Watch this!"...it turns out that
this also applies to writing Fragment Shaders.
-----------------------------------------------------------------------
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@... http://www.link.com
Home: sjbaker1@... http://www.sjbaker.org