gtk look progress and pthreads.

[James Gregory]

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.