On Mon, 2003-02-24 at 02:57, Dan Kegel wrote:
James Gregory wrote:
You're linking against gtk, and that probably brings in all sorts of code that can't safely be linked to in Wine. You'd probably be much happier if you carefully linked in the tiniest possible fragment of gtk needed to achieve your theming goals. (You might even be forced to duplicate a gtk source file or two, which would be a shame, but would at least give you the flexibility you need to avoid this kind of problem.)
ouch. My ultimate goal requires an enormous chunk of gtk code, I'd rather avoid doing this if at all possible.
Mike Hearn replied with some good suggestions. I also encourage you to discuss your goals here on wine-devel a bit more; it's not really clear to me how gtk theming and wine theming should interact. Also, it's not clear to me that the bloat caused by linking in gtk would be acceptable.
Ok, fair enough. Let me start by prefacing this: it won't be perfect, it can't be perfect. I am doing this as a starting point for getting Wine a bit more integrated with Linux. In particular I would like it to integrate more with the GNOME desktop I use (no technical reason to choose GNOME over KDE other than I use GNOME so I'd be able to test the code I write :)). I have only thought through the first few steps; after that I'll be in a better position to see what direction to take next.
re: bloat - I'm currently intending for this to be a compile time option. I don't think it will exacerbate the situation that most linux desktop users are in right now. The existing infrastructure works and should be kept for applications where memory and cycles are at a premium.
Rough plan:
1. Get Wine to use the same colours as current GTK theme. I had thought that this would be a relatively harmless, straight-forward patch that would save me from the shock I get when switching to the desktop I often have running IE. I use Bluecurve, and the dark greys of Windows apps are extremely distracting.
2. Get Wine to use the same fonts and font sizes as the current GTK theme. I have much the same ends in mind as (1) here. Again, this shouldn't really affect usability. It's just for reducing screen-shock.
-- evaluate position here, maybe proceed as follows:
3. use GDK's gdk_window_new_foreign() to get GdkWindows out of the X Windows that Wine is using, pass these to the appropriate GTK functions to render some widgets using GTK. Stuff like buttons etc. Text boxes in particular are a problem. I have not yet figured out precisely what to do with them. It is conceivable that they could be similarly hacked in, but it would be much more complicated. Existing event handlers would need to be patched to make similar calls to GTK in order to use the 5 states of GTK widgets.
4. Maybe add a GDK driver to WINE. Porting the X stuff to GDK should be reasonably straightforward, though I'm not sure that it's necessary. It would simplify code written in (3) though.
5. Possibly replace some (maybe all) of the common dialogs with their GTK counterparts - this starts introducing inconsistencies in button placement etc, which is why this is only a "possibly" and leads on to...
6. The fun bit: depending on how things are at this point I am considering adding some simple heuristics to get things to start feeling more GTK/GNOME like. Tricks like using the tab index and the text on buttons to identify "OK" buttons etc and using the stock GTK-OK button in its place. Likewise using tab-index to dictate button placement (GGAD says button placement should be in the direction you read with most likely selection "first", so for english, the least tab-indexed button should be placed on the left, probably with some other constraints). I would remind you of my disclaimer at the top at this point. :) - I'm not entirely convinced of this myself, so there's no need to try to dissuade me on this point just yet.
* STUFF NOT DIRECTLY RELATED TO GTK, BUT RELATED TO INTEGRATION :
An entirely separate idea I had was to patch Wine to (optionally) use gconf to store registry data in. WINE & gconf seem to me like they were meant for each other, the one obvious hurdle being that gconf doesn't do binary entries - this would need to be implemented with some sort of string to signify that an entry was in fact binary data, followed by a hex-encoding of it or something (or convincing the gconf guys that they really do want binary data in gconf).
This last point opens up possibilties like registries stored in ldap, and access control over particular keys. It makes the notion of a centrally administrated WINE multi-user system a little more attractive (to me anyway).
I also think it would be cool to have some mappings between common windows settings and GNOME settings - stuff like setting IE's home page to be the same as X GNOME browser. Ditto proxy settings etc. This might go into WINE or into another layer entirely. I'm not sure yet.
I'd also like to start looking into ways to get Windows apps into .rpms / .debs. ie code to trace what files and registry entries get touched in a given invocation of wine, and dump this to an .rpm / .deb (either from a log file or on program exit) - this isn't directly related but it's part of the integration thing that got me started on all this. Licensing is the responsibility of the user of course (as it always has been), but it does give enterprises a great way to push out the software that they need on all their desktops, and offers capabilities like using the existing apt-get/urpmi/up2date code to keep WINE software installations up to date in a clean manner. This also implies that I'd like to see a standardised place for installation of WINE software -- I'm not aware if one exists, but I think it would be a good move to start recommending one.
civil feedback?
What sort of things are likely to be broken in linking to gtk? Where do I want to look if I want to try to fix this?
I suppose a good place to start is the source of that FIXME message.
It's probably the same issue Mono had: Wine doesn't use pthreads. We need to fix this, but it's a pretty big job.
by "fix this" - you mean get WINE to be pthreads linkable / use pthreads or something else entirely? Is this something that I can help with?
James.