From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dkshv-0005pv-65 for qemu-devel@nongnu.org; Tue, 21 Jun 2005 20:03:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Dkshr-0005oA-5P for qemu-devel@nongnu.org; Tue, 21 Jun 2005 20:03:04 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dkshq-0005kS-D8 for qemu-devel@nongnu.org; Tue, 21 Jun 2005 20:03:02 -0400 Received: from [128.8.10.164] (helo=po2.wam.umd.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DksgB-0000iJ-6W for qemu-devel@nongnu.org; Tue, 21 Jun 2005 20:01:19 -0400 Date: Tue, 21 Jun 2005 19:58:14 -0400 From: "Jim C. Brown" Subject: Re: [Qemu-devel] quick gtk2.c update Message-ID: <20050621235814.GA6661@jbrown.mylinuxbox.org> References: <214616558.20050621222242@ena.si> <001701c576a6$f12c53f0$334d21d1@organiza3bfb0e> <20050621222420.GA5775@jbrown.mylinuxbox.org> <002601c576b2$e6c825e0$334d21d1@organiza3bfb0e> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002601c576b2$e6c825e0$334d21d1@organiza3bfb0e> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: jeebs@yango.us Cc: qemu-devel@nongnu.org On Tue, Jun 21, 2005 at 05:45:12PM -0500, jeebs@yango.us 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.