GIIgeteventmask
GIIgetselectfdset
GIIhandler
GIIclose
I understand what most of them do. However, I am not sure of the
purpose of GIIhandler.
Do all of them need to be implemented? I would imagine the first four
are a must.
Any other advice. comments are welcome.
John
such as shift, control, and alt.
I quickly looked at the linux keyboard stuff, but I don't have a lot
of the linux headers.
Thanks,
John Fortin
Does anyone have any programs available to test a keyboard input target.
I have most of the MSWindows keyboard target running, and I need to test
it.
I mostly need to test whether the US keyboard mapping is working
properly.
Thanks,
John Fortin
Marcus Sundberg wrote:
James Simmons [EMAIL PROTECTED] writes:
I had a interesting discussion on the possiblility of having a Direct X
on linux with John Carmack. Well it appears Mircosoft will sue anyone that
tries that. So I talked to him about Mesa-GGI and how Direct X support
I'm torn here. The current version I am using does not need to acquire
the direct buffer. However, it uses features available only on win
95/98/W2K. It will not work on NT4, as NT4 only supports directx v3.
You must install a Service Pack (4 or newer) for NT4. Then you have
support
Here the url from the microsoft site.
http://www.microsoft.com/directx/overview/hardware/dx4nt.asp
I suppose it is possible the programs don't actually use the apis above directx3
John
Christoph Egger wrote:
On Tue, 14 Dec 1999, John Fortin wrote:
I'm torn here. The current
Please Enough I get enough off topic stuff as it is...
John
"W.H.Scholten" wrote:
Tim Coleman wrote:
On Mon, Dec 27, 1999 at 08:14:40PM +, W.H.Scholten wrote:
Joseph Carter wrote:
*WHACK* 21st century starts in 2001.
No it doesn't and here's why:
where the modifiers for the keys are handled. How
does XGGI know when the modifiers are set?
Do I need to send the actual shift, control, alt keys themselves??
Currently I don't send these keystrokes. I use them only to set the
modifiers field.
Thanks,
John Fortin
Would there be any objection to overriding the compiled in configuration
file directory with an environment variable. This would allow
installation in a directory structure other than the build structure.
Example: I configure and build to /e/local/user ( actually
e:/usr/local on Win98 ).
Marcus Sundberg wrote:
Andreas Beck [EMAIL PROTECTED] writes:
How about if we #ifdef around that code. Windows will be the only OS
which can use an environment variable. The others would still be hard
coded.
Could be done, but I don't really like special solutions ...
If at all possible, it'd be nice if a user that hasn't got write
access to C: or to the system part of the registry can install
libggi (possibly by putting a config file in the same folder as libggi
or something).
If I go with a registry solution, which seems likely, I doubt I'll
Actually the whole point would be to have the registry entry in
the system section so random users can't tamper with it. However,
installing LibGGI as a user must also be supported, so I'd suggest
we have it in the user section for now. Then if we find a reason to
do something more secure we
Is anoncvs.us.ggi-project.org down ?? I tried to get to it Friday night
and Saturday Morning with no success.
John
Thanks Marcus!!
John
Marcus Sundberg wrote:
Andreas Beck [EMAIL PROTECTED] writes:
Since mansync can not be build for win32, could we add a switch to
configure to disable it.
Things like this should be detected by configure automatically - see below.
Yep, should be fixed now.
this?
Thanks,
John Fortin
ducking bullets
All right, you are right. I must have been having a bad day... Thanks
for the feedback though :)
/ducking bullets
John
Marcus Sundberg wrote:
John Fortin [EMAIL PROTECTED] writes:
As alot of you probably know, I've been working on a Win32 port of GGI.
A good portion
.
Thanks,
John Fortin
Marcus Sundberg wrote:
Andreas Beck [EMAIL PROTECTED] writes:
Is there a way to have it determine the correct extension, or add a
command-line to configure to change this?
Sure. It is already prepared in the configure.in script. The DLLEXT variable
has to be set according to the
"Jon M. Taylor" wrote:
libggi.conf.in has the variable DLLEXT, which is supposed to be
replaced with "so" or "DLL" or something during the make process. This is
not happening, and the @DLLEXT@ is remaining in the final libggi.conf. I
just blew away my whole degas/ tree and tried
I will test it tomorrow.
I'll test it too, tonight.
Thanks Marcus!
John
Well, I tested it. The libggi.conf is properly created, except for one
thing. It always selects .so as the extension. Since I am building
with mingw, it should have .dll. I also tested with cygwin, and it
With a new cvs extraction and build I get the following:
Making all in gg
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I..
-DBUILDING_LI
BGG -I../include -I../include -I/usr/local/include
-I/usr/local/include -g -
O2 -D_REENTRANT
Marcus Sundberg wrote:
John Fortin [EMAIL PROTECTED] writes:
It gives i386-mingw32 for ${target}
configure --host=i386-mingw32 --build=i386-mingw32 --target=i386-mingw32
--without-x \
--enable-directx --prefix=e:/usr/local --with-gii=/usr/local \
--with-extra-libs=/usr/local
Andreas Beck wrote:
configure --host=i386-mingw32 --build=i386-mingw32 --target=i386-mingw32
...
With the above command I get the following...
checking host system type... i386-pc-mingw32
checking build system type... i386-pc-mingw32
Why isn't ${target} converted to
was incredibly SLOW and painful to
use.
They are adding hardware and support so it will probably improve, but SF is
suffering growing pains.
Just my $.02 worth.
John Fortin
that it is
cross-platform/Generic. That is why I was interested in it. However,
if the decision is really cross-platform/Generic meaning only linux/KGI,
then I'm not.
John Fortin
to decide if I want to provide libs for MSVC++ and gcc. I know
that your goal is to run under Wine, but I want to see it used for Windows
on Windows.
I believe I finally have time to work on this again, so Jon, if you have
source, could you send it to me...
Regards,
John Fortin
[EMAIL PROTECTED]
Can we add the base GGI/GII source to Sourceforge. I'm willing to do it...
I have a Sourceforge ID: fortinj
John Fortin
- Original Message -
From: "Andreas Beck" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, March 13, 2001 3:10 PM
Subject: Re: Sourceforge
ill become a
footnote.
John
- Original Message -
From: "Brian S. Julin" [EMAIL PROTECTED]
To: "John Fortin" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, March 13, 2001 5:53 PM
Subject: Re: Sourceforge
On Tue, 13 Mar 2001, John Fortin wrote:
Can
Christoph,
I looked on SF for libGGI and could not find it. Could you send me
the
appropriate link..
http://sourceforge.net/projects/ggi/
CU,
That's odd. When I searched for GGI on SF, it was not found.
John
When John Fortin could merge and commit his DirectX-tree into CVS,
then we should be able to archieve much more users. And more users
are more testers... :)
I didn't realize you were waiting on me... I've been tied up at work lately
so
GGI has taken a back seat...
I'll try this weekend
Are we going to wait for DirectX updates before announcing
the release candidate? BTW, can anyone offer me some pointers
to instructions on how I would go about building/testing
cygwin and the DirectX target? I do have a Win98 box handy these days.
You need the Cygwin development
Are we going to wait for DirectX updates before announcing
the release candidate?
Depends on the timeframe - I'd say if it's below two weeks extra time, I'd
rather wait. Gives much broader audience.
I've checked in updated DirectX target files to match my working system,
with the
Huh ? We do require perl ? Where ?
automake requires perl...
John
Great, for the most part...
I'll have to download the DX8 headers and give them a try...
John
- Original Message -
From: Brian S. Julin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, June 30, 2001 4:32 PM
Subject: DirectX cygwin build
OK, here are the results of trying
2) For some reason I had to cd to libgg and make install before
building the rest of libgii
I believe this is a problem for all platforms. libgii doesn't look in
its own directories for libgg. Unless it's installed it won't find it.
I've never had this problem building libGII under
Right. What is currently on the showstopper list ?
If DirectX doesn't build smoothly, so what. Basically for DirectX support
to
reach users, we have to distribute foolproof click-on-that-setup.exe style
binaries anyway, so no problem if that is the only one.
I suggest that we release now
changed on this :)
John Fortin
- Original Message -
From: Brian S. Julin [EMAIL PROTECTED]
To: Christoph Egger [EMAIL PROTECTED]
Cc: GGI ML [EMAIL PROTECTED]
Sent: Thursday, July 19, 2001 9:45 AM
Subject: Re: TODO list for final release
On Thu, 19 Jul 2001, Christoph Egger wrote:
The DirectX input target
- Original Message -
From: Christoph Egger [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, October 30, 2001 9:12 AM
Subject: Re: Building GGI Project on Windows.
Hi John!
Great to know you're back!
I did the original port to Win32 using CygWin (www.cygwin.com). I have
39 matches
Mail list logo