gtk look progress and pthreads.

[James Gregory]

Hi all,

I posted something similar to mono-devel, so sorry if any of you are
seeing this twice.

I've spent some time working on getting wine to have the option to look
like a gtk app. At present I'm just trying to get wine to use the same
colours as the current GTK theme. I made great progress on this last
night: modified configure.ac et al to allow building against gtk, added
an item to the enum for the various "looks", added the option so setting
"WineLook" does the right thing for this new look.

I added another array of colour settings to syscolor.c, and modified the
condition that loads in that array to recognise the new colours (which
are currently all set to red), and call a function to do a gtk_init()
(for those who are wondering, I'm currently using a dummy argc and argv
in the call. I'll do something about this later) and then start setting
that array to the *actual* colours of the gtk theme (I chose red to make
it easy to find bugs -- colours that weren't set would be obvious)

Now, this was all going great up until the gtk_init() call. I'm now in
the position where running I'm wine and seeing this sort of thing:

$ LD_LIBRARY_PATH=/home/james/lib /home/james/bin/notepad 
Loading required GL library /usr/X11R6/lib/libGL.so.1.2
wine: Unhandled exception, starting debugger...
FIXME:pthread_cond_init

(repeated n times)

Now, I'm assuming from the FIXME: that this is an unimplemented piece of
wine. Is this saying that gtk can't run with the existing wine threading
implementation due to this (and possibly) other functions being
buggy/nonexistent?

So, the point: what should I do? is this something which will be fixed
by someone who knows threading better than I (which is to say almost
anyone :))? Does someone know of a workaround that I can use? Is this
doomed ==> should I throw in the towel?

Thanks,

James.

[Dan Kegel]

James Gregory wrote:
> Now, this was all going great up until the gtk_init() call. I'm now in
> the position where running I'm wine and seeing this sort of thing:
>
> $ LD_LIBRARY_PATH=/home/james/lib /home/james/bin/notepad 
> Loading required GL library /usr/X11R6/lib/libGL.so.1.2
> wine: Unhandled exception, starting debugger...
> FIXME:pthread_cond_init

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

[James Gregory]

On Mon, 2003-02-24 at 02:20, Dan Kegel wrote:
> James Gregory wrote:
> > Now, this was all going great up until the gtk_init() call. I'm now in
> > the position where running I'm wine and seeing this sort of thing:
> >
> > $ LD_LIBRARY_PATH=/home/james/lib /home/james/bin/notepad 
> > Loading required GL library /usr/X11R6/lib/libGL.so.1.2
> > wine: Unhandled exception, starting debugger...
> > FIXME:pthread_cond_init
>
> 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.

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.

Thanks,

James.

[Dan Kegel]

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

- Dan

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

[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:
> - 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.
> - 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/programmersgu...
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:
> - 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.
> - 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.
> - 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...
> - 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
[e-mail] (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

[Mike Hearn]

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

I think apps have to be explicitly linked against the new common
controls lib in XP - some apps need to be reworked to use the new
theming APIs directly, hence the fact that some apps use the old look
and some use the new.
> Sure, but it's a really big job, probably bigger than you want
> to tackle.

To James: Agreed. Look through the archives for jan and feb to see what
the problem is. Basically it requires extremely in depth knowledge of
Wine threads and the new glibc threading - a bit elite for most ;)

[Keith Matthews]

On Sun, 23 Feb 2003 10:20:10 -0800
Dan Kegel  wrote:
> 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.

Depends how it is done. What worries me is the statement 'more
integrated with Linux' - wine runs (or should do) on BSDs as well where
there are already problems. Any work that made things worse is
undesirable.

There are also a growing number of people getting upset about the
resource requirements of the window managers and wanting to go back to
fvwm and the like. There was a thread recently on uk.comp.os.linux by
someone who was not happy with the performance of Gnome or KDE on a
PIII-500.

There are also some strange things being done by packagers - the other
day I had to make a minimum install of SuSE and it tried to insist on
the large Cyrus-SASL libraries being loaded just because I had cron
installed. I get worried  about just what these people will do every
time I see someone wanting to tie to anyhting more than a minimum set of
libraries.

[Dan Kegel]

Keith Matthews wrote:
> Dan Kegel  wrote:
> > Integration is a good goal!  ...
>
> Depends how it is done. What worries me is the statement 'more
> integrated with Linux' - wine runs (or should do) on BSDs as well where
> there are already problems. Any work that made things worse is
> undesirable.

IMHO integration should be pursued via standards like
those at http://www.freedesktop.org, not by linking in
huge, not-quite-portable desktop libraries.  I want
Wine, KDE, Gnome, and other desktop environments
to use common data formats for things like icons
and menus, and thereby give users freedom from being locked
into any one desktop package (or operating system).

(That said, I have nothing against a kernel module for
wineserver, if it has significant benefits.  We can
always use the userspace implementation as a fallback,
and the module should be small enough that we could
maintain it for both Linux and BSD.  Come to think
of it, maybe we could use the PEACE project's win32
kernel stuff on BSD instead of writing a new one.)
> There are also a growing number of people getting upset about the
> resource requirements of the window managers and wanting to go back to
> fvwm and the like. There was a thread recently on uk.comp.os.linux by
> someone who was not happy with the performance of Gnome or KDE on a
> PIII-500.

I'm with you there.  I run very primitive window managers on
several of my machines because I can't stand the overhead
of KDE and Gnome.

[Mike Hearn]

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

Sure. There are quite a few other things that you could do that'd
improve integration for everybody though first - for instance, the
system tray code was broken by the recent switch to an XEmbed protocol.
The system tray is a fairly commonly used feature by Win32 apps, and it
doesn't work :(

Other things would be, as you say, using the freedesktop MIME spec (when
it gets written, i don't think it's done yet, but you could always help
with that too :)

Fonts are a good idea too.

Stuff like colours, themes etc would be very hard to do unless the app
was aware of the XP theming APIs. Many Win32 apps draw their own custom
controls, but in such a way that it fits in seamlessly with the win9x
look. XP exposes some APIs so that people using custom controls can make
things fit in nicely still. Even then, it'd still use XP style artwork
etc, which is why I think these features are nice to have but wouldn't
work very well "out of the box", you'd need to put in the legwork to
make it HIG compliant etc.
> 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.

I don't personally think bloat is a problem, 95% of users will have GTK
mapped into memory already. Complicating the code is a bigger deal.
> Rough plan:
> - 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.

Agreed, it'd be nice to get this customisable. I'd do it by directly
reading the gtkrc however.... assuming you can do this still. Like I
said, if you need to use a theming engine it's best to actually work
with the Win32 port of GTK.
> - 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.

Yeah, that's cool.
> -- evaluate position here, maybe proceed as follows:
> - 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.

Ah, you'll run into issues with that. Actually using native toolkit
widgets has been tried twice, and failed both times. The first was in
the early days of Wine, when instead of actually implementing the
controls they were mapped to Tk. Didn't work well. The second time was
with Mono and System.Windows.Forms, when they tried to map it to GTK.
Didn't work. The devil is in the details.

Adapting the button code to perhaps use the GTK theming engine is
certainly possible, if you use the gtk windows port (because then it'd
all be piped through the gdi)
> - 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.

Hrm, why? GDK simply maps to X anyway, and that'd be probably
impossible, Wine needs direct control of X to do some things.
> - 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...

This is doable for sure, but would be hard to do well all the time, as
apps often customise dialog boxes by adding custom controls etc. Also,
for instance for the file dialog, you need to restrict the user to what
Wine allows the app to see. That'd be pretty hard to do well.
> - 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.

As I said earlier, probably very hard to do in a way that doesn't feel
"half way" which imo is even worse than not at all - non HIG gnome2 apps
really feel bad to me these days :)
> - 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).

Nooooooo, part of the appeal of GConf is that it *isn't* the Windows
registry. It's design isn't designed for registry style mass dumping of
info, and its own creator says "don't try and store binary, don't even
assume you can write to it - it is for personal preferences only".
> 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 think those features would be better to be put onto the Wine registry
itself.
> 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.

Well this stuff should be standardised at freedesktop.org, then picked
up by Wine in the core. All these integration things need to be specced
out really, rather than being gnome specific.
> 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.

I've been doing a lot of work with app packaging on Linux lately, see
autopackage.org to find out what i've been getting up to. It's a nice
idea, and would have some advantages. Again, it'd be hard to do well.

Having said that, I think this would be rather difficult, RPM and
InstallShield style installers are too different. For instance,
InstallShield allows lots of user interaction, customization of
components etc. As of yet, no Linux system allows for this. I hope soon
we will be building one that does :)
> 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.

Well normally it'd be in your fake windows directory, but there is no
standard place for this, I guess you'd have to read the wine config
file. It might be worth putting something in the FHS about that.
> 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?

Indirectly, this is kind of a good example of the challenges faced.
Basically, Wine is two things:

1) An implementation of parts of the Win32 APIs. For instance, it
contains a replacement for the common controls library, and in theory it
can be dropped into a Windows with no problems.

2) A mapping layer between some of the APIs that simply cannot be
reimplemented and their native Linux equivalents.

For instance, Wine can't really drive the hardware directly like Windows
does, so the window management APIs are mapped to X. Direct3D is mapped
to OpenGL.

The main problem with these kind of mappings is that it's very hard to
get them exactly right. Window management bugs have plagued Wine for
years, and for instance Dungeon Seige directly blits the mouse cursor
into the rendering backbuffer, something that Direct3D allows for but
OpenGL simply does not.

And then we have threads. The friction between Wine threading and glibc
pthreads has been the cause of a lot of concern here on wine-devel
lately. Basically Wine has had its own threading implementation for
quite some time now instead of using pthreads, and recent changes in
glibc have b0rked it. So, Wine has to be ported to pthreads for it to
work properly in future. That'll solve a big problem for people who use
pthreads and want to link in with Wine, but it introduces others.

The higher level you perform the mapping, in other words, the harder it
becomes. Files are files, on UNIX and Windows, and so Wine uses the unix
filing system rather than using its own FAT partition in a file for
instance, but subtle differences can cause issues (locking, case
sensitivity etc). It's for that reason that Wine prefers to implement
things as "sealed" implementations where possible, ie implementing its
own widget library rather than using GTK.

Hopefully I'm making myself clear... basically I think some of your
ideas are great and should definately be done, but not always in the way
you're suggesting. Trying to make Windows apps use GTK won't work, the
contention between GTK and Windows common controls is too high, but
maybe letting the Wine common controls lib read colour and font prefs
from the system will work.

thanks -mike

[Mike Hearn]

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

Are there any details about what exactly you can and cannot link into
Wine? Is this due to GTK using pthreads, but Wine using its own (ie the
same problem that hit Mono?).

BTW, I've also considered how you might go about making Wine apps feel
"integrated" - I don't think using GTK directly is the right way though,
nor using the WineLook setting.

Oh, one thing you might want to try is using the Win32 port of GTK -
that way you can use the theming engines (which only use gtk -> gdi).

In particular I think it'd only be useful for WineLib apps, trying to
"retheme" an application is pretty hard if it wasn't designed to look
right in the native setting. So for instance it might be using GTK
controls, but it won't use the pretty jimmac/tigert artwork, it'd use
sucky Windows 98 style icons. In general, it'd just look wierder than
with the Windows theme.

Maybe an extended window style or something.....

One possible implementation is to rearchitect wine to use the
uxtheme.dll theming system that Windows XP uses. Well, it's just a
random thought, but internally that might be easier than filling the
control dlls with lots of GTK theme reading code.