gtk look progress and pthreads.

[Dan Kegel]

James Gregory wrote:
> 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.

Integration is a good goal!  It's great that you're thinking about
it.

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

Even if you make it a compile-time option, it's important to
avoid increasing the RAM consumption or startup time
of wine applications.

Come to think of it, we probably should be doing regular measurements
of RAM consumption and startup time of a few typical apps (e.g. Notepad, AbiWord 1.0)
and make sure the trend is *downwards*, not *upwards*.

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

As Mike pointed out, we need to implement XP's native theming APIs
anyway, so that's where you should start.  You can hook in to the
gnome and kde theme config files at that level, and the changes
will naturally affect all apps, just like you want.
Or so I gather; I haven't ever used them.  Here what I just dug up:
MSDN's page on this is
http://msdn.microsoft.com/library/en-us/shellcc/platform/shell/programmersguide/shell_intro.asp
Windows Themes are controlled by ascii files (in .ini format) with suffix .theme.
See http://www.tgtsoft.com/ for a collection of tools that make it
easy for the average user to create .theme files.

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


All of the above sounds like you might be heading off in the
wrong direction a bit.
A GDK driver would be useful, but not for the reasons you give.
Basically, you seem to be a true believer in the gnome API's.
That's great when you're developing apps, but when you're
developing platform software like Wine, you should probably
take a much more conservative tack.  Let's look for ways to
integrate with Gnome and KDE that are based not on linking
in huge gobs of code, but instead are based on common file
formats and protocols!  I encourage you to bring up your ideas
not just on the wine mailing list, but also on
xdg-list at freedesktop.org (see http://www.freedesktop.org/ )
At least one fellow there has thought about this a bit; see
https://listman.redhat.com/pipermail/xdg-list/2001-March/000072.html

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

Sure, but it's a really big job, probably bigger than you want
to tackle.  I'd suggest going the "windows theme" route instead,
and figuring out how to hook that into gnome or kde themes.
(I think Windows implements its themes in comctl32.dll, and
you could stick in magic code there that would read the
gnome or kde theme info.)
Not only would it be easier, but it'd also make us more
compatible with XP, thus killing two birds with one stone.

- Dan


-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045