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

[Jim C. Brown]

On Tue, Jun 21, 2005 at 05:45:12PM -0500, address@hidden wrote:
> > GTK libraries are not part of qemu, they are a separate resource that qemu
> > depends on.
> 
> As far as the user is concerned, they are part of qemu.
> 

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.

> 
> > I disagree. I think distributing the GTK library with qemu (even for 
> > windows
> > versions) is a very bad idea. At most, the qemu installer should just 
> > download
> > and run the GTK installer. At most.
> 
> It's a very bad idea to have the installer need to go back on to the net to 
> download something else.
> 
> The user should get the whole thing at once.
> 

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

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
the libraries, and one that has only SDL support.

That's the dumb last resort option. Let's see who can come up with a smarter 
one.

> > set of 6M libs can be shared by many different applications (qemu, xchat, 
> > etc).
> 
> Not under windows, it wont be.
> 
> For us Windows users, qemu will be the only program we use that will need 
> gtk libs.
> 
> Realistically, we don't need GTK.  We've already got a GUI with an api. 
> That's what windows programmers use.  The vast majority of us will never use 
> xchat etc.  Qemu may be the only one they use.
> 

Ok, that is a valid point. I also agree that given what the GTK layer in qemu
actually does, that is too much lot of overkill. (It would be really simple to
just use pure GDK - the majority of the code is GDK.) However, I believe that
the benefit of sharing the same GUI between Windows and Linux outweights this
cost (esp. if what you say is true, that Windows builds are not very well
maintained).

> And it's not a good idea to distribute the libraries seperately.

Agreed.

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

> 
> >> As for the gui... Well, I haven't seen that yet.  What little I see looks
> >> the same boring Windows window that qemu always runs in.  The gtk version
> >> isn't usable yet.
> 
> > The GTK version, on Linux, is perfectly usable. It is no more usable than 
> > the
> > SDL version, but no less.
> 
> But it's not usable on Windows yet.
> 
> As I said, so far, I'm not seeing *any* gui.  Even the keyboard is messed 
> up, so you can't even use the guest OS.
> 

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.

I'm waiting to hear from Fabrice and Sebastian for the GUI they have planned
on top of the GTK layer. It seems that Fabrice is very picky when it comes to
the GUI of choice for qemu.

> 
> > On Windows, you have no fullscreen support. Everything else should be 
> > exactly
> > the same. If it's not, I'll try to fix it.
> 
> I never use full screen, myself.
> 
> I much prefer a window.  Preferably one that's resizable, scroll bars, etc. 
> etc.
> 

This isn't very difficult to do at all, and the code to do this for Linux and
Windows should be identical. I'd like to fix the current bugs first though
(on the off chance that there happens to be a difference on Windows that I don't
know about). Once we fix those bugs, I'll look into making the qemu window
resizable.

> >> It runs, but there are keyboard problems.
> >>
> >
> > What keyboard problems? There shouldn't be any for the GTK version.
> 
> As I said in the other message (which I may have accidently sent directly to 
> you, instead of the list)
> 
> It's not doing the regular US keyboard.  At least it doesn't eappear to be.
> 

It should. But it doesn't. Disturbing.

> I can get symbols, a few letters, but not the whole thing.  And none of it
> is normal.  Press '1' to get 'n' and so on.
> 

Yes, that is quite disgusting.

> However, it doesn't appear that the -k keyboard option works for the windows
> version.
> 
> I tried my builds and the official 0.70 build and they don't accept it
> either.
> 
> I tried -k fr -k de -k en-us and so on, and they don't recognise it.
> 
> (I've never tried the -k option before, but according to the docs, it isn't 
> needed for Windows builds.  So it may not be enabled.)
> 
> So, assuming the problem is that gtk can't recognise I'm using a US
> keyboard, I can't do anything to force it.
> 

Well, no, that isn't it. The keymap files are based on X11 keycodes, so even if
you could use this option it wouldn't work at all.

I know the offending function. This is the culprit:

static uint8_t gtk2_keyevent_to_keycode(const GdkEventKey *ev)
{   
    return ev->hardware_keycode; /* does this work on win32 gtk? */
}

Apparently, that does not work for win32 gtk.

In fact, that is apparently the Windows virtual key code, not the raw scancode.
Hence the funny characters. The good news is that this is an easy fix. In fact,
here is the code that we would need:

static UINT vk2scan(UINT vk)
{
        static HKL layout=GetKeyboardLayout(0);
        return MapVirtualKeyEx(vk,0,layout);
}
static uint8_t gtk2_keyevent_to_keycode(const GdkEventKey *ev)
{   
    return vk2scan(ev->hardware_keycode); /* does this work on win32 gtk? */
}

At least, I think that is what it should look like. Looks like there will be
some minor problems casting as ev->hardware_keycode is an unsigned int of 16
bits, vk2scan requires a UINT (whatever size that is), and the main gtk2()
function here is expected to return an unsigned int of 8 bits. Hmm. Also, I
have no idea which files I'd need to include in order to be able to call
GetKeyboardLayout() or MakVirtualKeyEx(). What I really need is a Win32
programmer to proofread this, make sure I got it right.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.