Re: [Qemu-devel] quick gtk2.c update

[jeebs]

"Jim C. Brown"

> I must disagree here. If a user already has xchat 2 installed, and that 
> person
> wants to try to use qemu with the GTK interface, they already have the 
> libraries
> that they need.
>
> Including a set of GTK libraries just for qemu would not only be redundant 
> in
> this case, it could potentially cause breakage to occur.

That's why you are supposed to put them in the directory of the app.

It keeps from cluttering up the rest of the OS, possibly causing confusion, 
breakage, etc. with more than one version installed in various places (quite 
possible under windows) or having a damaged, broken one installed in the 
first place Windows looks.

> They should only get this library if they don't already have a copy 
> installed.

Which will be practically every qemu user.

> Of course there is a simple answer to this. Provide 3 qemu binaries for 
> Windows:
> one that includes GTK support as well as the GTK libraries (so the 
> installer can
> put them into the Common Files folder), one that includes GTK support but 
> not

Putting more stuff into the common files folders is just going to be 
'clutter'.

Things will never get used by any other application.  Eventually the user 
will even entirely forget they are there.

It just ends up being clutter.

>> Or put them in the Windows system directory.  Too much junk gets put 
>> there
>> already due to years and years of poor programming, careless authors,
>> indifferent programmers, and Microsoft's encouragement.
>
> I think the idea of using C:\Programing Files\Common Files\GTK 2.0 is a 
> good
> solution for that.

In theory.  That's kind of what the directory is for.

But that also assumes a few other things...

Like those files actually might possibly ever get used by some other app. 
Not too likely for a Windows user.

Second, by putting them in a common location, you open the possibility that 
they'll get replaced with newer versions.  Which may not work right, if at 
all.

That GTK website specifically mentions that certain versions are broken for 
Windows.

By bundling the libraries with qemu, and keeping them in the qemu directory, 
you can guarantee that the user has versions that work right and are 
compatible with qemu.  No -mms-whatever struct issue or anything else.


However, none of that's really relevant, since at this point the gtk stuff 
doesn't even work under windows, so there's no point in distributing 
anything.

> There is no GUI yet. I could easily make a crappy one in, say, 20 minutes.
> It'd work fine, but it may not be a lot of fun to use. For that matter, it
> may not be that useful.

Well, maybe not 'gui', but something that tells the user they are indeed 
running the GTK version and not the SDL version.


>> It's not doing the regular US keyboard.  At least it doesn't eappear to 
>> be.
>
> It should. But it doesn't. Disturbing.

[shrug]

All I can do is try to run it and report...

I don't know qemu, gtk, or general mingw development to be able to say more.

> GetKeyboardLayout() or MakVirtualKeyEx(). What I really need is a Win32
> programmer to proofread this, make sure I got it right.

That would help....

They could help you debug this stuff.

All I can do is try to compile it and run it.

Not very helpful.  Depending on how soon I can get to the patches you post, 
the test cycle may takes days for each event.