Re: Theming for Wine via the registry
On Sat, 2005-03-12 at 22:36 +, Mike Hearn wrote: On Sat, 2005-03-12 at 22:15 +, Oliver Stieber wrote: The only problem I can see would be drawing the widgets, I haven't looked deeply enough into QT or GTK to know if it's more on the 'impossible' side of difficult or not. Wrapping the event loop and passing events should be relatively easy. You have feature mismatches, eg GtkTextBuffer cannot do some things the richedit control can, Win32 menus can't do some things that GTK can etc etc. Also getting the message/paint sync especially for subclassed windows would be impossible. Basically we have to do our own widgets, we can't actually map win32 widgets to some other toolkit. I've actually tried getting Wine to use GTK widgets. I made some progress but hit some issues that I wasn't sure I had a solution to. It is true that the controls in Wine and GTK have different semantics, however matching semantics probably shouldn't be the first goal you try to achieve. To begin with, you just want to get GTK to draw the widgets and let Wine feed GTK's rendering engine with enough information to do what it needs to. That is, Wine would still intercept all the mouse clicks, keypress events etc and use that to update the state of the GTK analogue of each of your widgets. If it turns out you can get that going, then it's probably worth thinking about other modifications to Wine's behaviour, probably based on some configuration file. Reversing the order of buttons for example. It's also worth remembering that there are a bunch of controls that will work just the same. Checkboxes for example. Now, when I did this, I asked the gtk widgets to draw themselves directly onto the X windows that Wine used. That won't work. There was something going on in the way GTK handled X events that left my widgets half rendered. What would probably work is to use the windows port of GDK to do the actual drawing. That way, X messages would still be dealt with by wine and this drawing code would just be another thread managed by wine like any other. There are some other hurdles to overcome in doing this, but I think that approach would get you somewhere. I started prototyping what I'm suggesting to you and found that there was a missing wine feature that stopped glib from working. I'll try to have a look some time this week and see if that's still the case. On the question of mapping colours though (which is where this thread started): I had some code in my local tree which would query GTK for the colours it was using for various widgets and set the equivalent registry entry for Wine. It was relatively straightforward and I can probably dig it up if anyone's interested. It really did look quite weird for some themes though. GTK gives you a lot of control over the colours used on widgets. The basic colour mechanism in Windows doesn't give you the same level of control. To get it to look right, you'd really need to use GTK widgets. Keep us informed on this. I'll offer any feedback I can from my experience in doing this. If there's anyone here really familiar with the windows GTK port, maybe we could combine resources to get this working. James. -- James Gregory [EMAIL PROTECTED]
bug in redhat 9 RPMs
Hi all, apologies if this isn't the right place to post. I installed the RedHat 9 RPMs from sourceforge (followed the link from winehq.org - downloads) and discovered that the permissions on /usr/lib/wine and /usr/share/wine (the directories, not their contents) were 700, which prevented normal users from using Wine. I changed the permissions so it's not a problem for this particular install, but it's probably not expected behaviour. Unfortunately I don't have any real way of checking if it's a system specific problem, or an issue with the RPMs themselves. I'm happy to supply any info needed to debug it. Thanks, James. -- James Gregory [EMAIL PROTECTED]
Re: i810 audio fixes 1/2
On Thu, 2004-04-22 at 20:12 +0100, Mike Hearn wrote: On Thu, 2004-04-22 at 14:38 -0400, Paul Davis wrote: JACK runs on OS X (and is proving very popular there). It is written in strict ANSI C and attempts to be strictly POSIX compatible. There is an OSS-API driver enabling it to be used on Solaris (at least). Bingo :) OK, so I originally thought that alsa dmix was the best way to get decent desktop mixing and such, maybe it still is (I'm a real newbie to this stuff), but it sounds like there are at least two good solutions in the pipeline. Perhaps GNOME and KDE could be persuaded to move to JACK after all. The main problem is that I'm not sure what GStreamers support is like, and KDE can't/won't drop arts until kde 4 rolls around. Gstreamer talks to JACK ok. If you run gstreamer-properties you can tell GNOME that JACK should be the default audio output for gstreamer apps. The problem is that most GNOME apps aren't gstreamer aware atm. Jeff Waugh (GNOME release manager) has spoken about this stuff before. As I understand it (and correct me if I'm wrong here), a move away from esd would require an API change and that's not going to happen until GNOME 3.0 at the earliest. Another option potentially worth considering is using SDL. I'm not too familiar with it, but it does provide an audio abstraction layer. Being written for games and so forth, it's likely they've designed it to be relatively low-latency. Alas that's all I know about it. Figured it was worth mentioning though. I had a look at Wine's audio code a while ago with a view to prototyping this. Unfortunately I couldn't figure out enough about how it works to be able to do it. I'd be interested in having another attempt if someone could give me some pointers on getting started. James. -- James Gregory [EMAIL PROTECTED]
Re: Native NetBSD audio driver
On Thu, 2004-02-26 at 08:59, Alexandre Julliard wrote: Robert Reif [EMAIL PROTECTED] writes: I think it might be worthwhile considering restructuring the audio drivers into hardware independent wave, direct sound, midi and mixer sections and a hardware dependent low level implementation for oss, alsa, ... Yes we should definitely do something like that. This sound driver business is becoming a huge mess. Is there a reason not to use something like libao here? http://www.xiph.org/ao/ It lists NetBSD amongst the systems it supports. I suspect this will only solve part of the problem, since it appears to only do PCM audio output, but this has got to be a problem that has been solved before. How complicated is the audio code? Would it be difficult for me to add a libao driver? James.
Re: uxtheme.dll
On Wed, 2003-10-01 at 12:21, Kevin Koltzau wrote: I'm aware of the scope of the project. The general design of uxtheme lends itself well to being done incrementally, eg. controls could be modified as support for the particular control is implemented, etc. Also part of the API are a few functions (IsThemeActive IsAppThemed) which will allow themes to be disabled in the beginning for theme aware applications until sufficient support has been built or if themes are disabled via config/registry. Some time ago I started hacking in support for GTK themes. When I first suggested this project to the list there was suggestions that doing it with uxtheme.dll was the way to go. I agreed, but didn't have winxp to play with, so I kept tinkering on this project with the intent of learning a bit more about how wine works (which meant learning a lot about how GDI and X works, though I didn't realise that I'd need to know that stuff when I started on the project). I actually managed to get some results which were starting to look promising (though there's no way I'd submit that code as a patch). Screenshots here (the checkbox being the only important part): http://james.id.au/wine/wine-ss1.png http://james.id.au/wine/wine-ss2.png http://james.id.au/wine/wine-ss3.png Anyway, the reason I'm posting is not to suggest that this code be used (nor the approach I took), but to mention that if theming code is to be written that I think it's really important to have a way to pass off rendering of controls etc to a .so that can be dlopened and called with dlsym. IIRC the existing system uses a function lookup table, so there shouldn't be much that needs to change for this to occur -- only the initialisation of this function table and probably some hooks so that these .sos can detect whether or not they'll work with the current configuration (as an example the way I was doing gtk theming won't work with anything that isn't x11drv. I don't like breaking encapsulation like this, but it sounds like it's practical in this case). I don't know if I can be of any help, but I'm interested in trying -- please keep me posted. James. On Tuesday 30 September 2003 02:21 am, Roderick Colenbrander wrote: I hope you know what you will begin with. (For the ones that don't know uxtheme.dll is the dll that takes care of all theming on WinXP and it is the dll that dlls like comctl32 and all others use for theming) Some time ago I checked out uxtheme.dll a bit and it seems that it needs changes all over Wine. As I understand it WinXP ships with two sets of comctl32.dll and friends. One is the old version and one is a new uxtheme aware version. The uxtheme aware version contains lots of changes and uses uxtheme for theming. To use uxtheme you need to add uxtheme support to the dlls that need it which looks like a huge job. Perhaps this is something post Wine-1.0? Roderick Colenbrander
