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

[Damien Mascord]

address@hidden wrote:

<snip/>

> 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.

Heya Jeebs,

There are numerous GTK applications that have already been ported to
Windows, and work very well.  gaim and gimp to name a few.  Both these
applications work fine with Windows and are very stable.

<snip/>

> 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.

Then it's a problem that needs to be fixed.  A work around is not always
the best thing to do.

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

Then don't use those versions? :)

> 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.

By continuing to bundling the libraries with qemu, you are ensuring that
things aren't fixed in the upstream.  You aren't improving the general
playing field at all, and are not contributing to general GTK acceptance
on Windows.

If GTK installs over a previous version and breaks the API so that Qemu
doesn't work anymore, then there is an issue with the GTK installer,
and/or Qemu, and that issue to be fixed.

Having every application bundling it's own versions of DLLs, you are
making sure that dll compatibility is never obtained.  If one version of
vbrun300.dll breaks one app, but not another then it's a problem with
the app using non-standard API calls, or is a bug with the new version
of vbrun300.dll.

Windows XP even have manifests which allow applications to use a
particular version of a DLL, and have all those versions installed at once.

> 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.

Hopefully all this attention will cause the problems with the Windows
build to be addressed.  Since the people that contribute to the Windows
build are probably quite busy, it's still productive to continue to
persist with sending bug reports as accurate as possible.  If that
doesn't seem like a great prospect, then learning bits and pieces of C
so that you can contribute to the project would be of great value!
(Especially as a Windows user, you can replicate issues that many of the
other developers would have a hard time to do so).

>>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.
>

That's probably a good idea... maybe have some output to the monitor ?

>>>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.

Even that time frame would be useful to the progression of Qemu on
Windows :)  I applaud that you still take the effort to test!

Cheers,

Damien