1 Nov
2008
1 Nov
'08
1:04 p.m.
Hi,
There is a discussion going on over at
https://bugs.launchpad.net/ubuntu/+source/wine/+bug/111061 about
improving Wine's look and feel to better match the system that it is
running on.
The situation is as follows:
== Colour Schemes
Wine supports these by reading the settings from the registry. Winecfg
can load a .theme file containing a colour profile and adapt
accordingly (saving those settings to the registry).
At the moment, if you need to script this (e.g. when installing Wine)
you need to manipulate the registry. It would be helpful if winecfg
(or some other helper utility) supported setting the theme file on the
command line.
In addition to this, if the user changes the theme used on their
system it would not be reflected by Wine.
== Windows Theme Support
Windows theming support is in place to some extent, w.r.t. the XP
theming APIs. There are some user32 controls and the window/dialog
handlers that don't support theming yet and there are some performance
issues that need resolving.
This would be set via the command line used to set the colour scheme
since they can be set via the same .theme file. This is limited in
that you need an XP theme for each native theme available.
== Native Theme Support
The main thing here is that Wine would monitor the native system for
theme changes.
The colours of the native theme would be mapped to the Windows system
colours, saved to the registry and then a WM_SYSCOLORCHANGED message
would be sent to all open top-level windows so they could update to
the new look.
Any metric data would be mapped in a similar way.
As for the theme, an implementation of uxtheme would map the API calls
to the native calls. Here, it may be possible to just send a request
to redraw everything on each active window. If not, a WM_THEMECHANGED
message would need to be sent to all active windows.
The challenge with native theme support is two-fold: (1) it should
work on any system - some have Gtk, some Qt and some Cocoa/Carbon,
while others (like the *BSDs and OpenSolaris) are likely not to have
those engines available; (2) it should not break any Windows
application.
Note that as Vista has a different msstyles theming engine (it is a
DLL), we could have the msstyles DLL expose the uxtheme API and have
uxtheme call msstyles to do the rendering. That way, we could have a
gtk.msstyles, qt3.msstyles, qt4.msstyles and an carbon.msstyles that
would bind to the corresponding theming engine. If the msstyles DLL
does not expose those methods, the uxtheme engine could then fallback
to the current XP theme processing.
For Mac theme support that would possibly require Objective-C code to
be done properly, that theme could be an external package (possibly in
darwine) that would be installed in addition to Wine. The same thing
for the Qt engines, allowing them to directly interface with the C++
Qt APIs.
Thoughts? Ideas?
- Reece
1 Nov
1 Nov
2:02 p.m.
Hi,
There are a bunch of uxtheme / control theming bugs which need to be fixed but lets ignore
those issues for now.
In the end we need to support a bunch of different theme engines GTK, QT, Cocoa and
perhaps later on more. In theory it would be possible to create a different uxtheme
backend for each different toolkit. One major issue is the language which each of these
toolktis is written in. GTK would be fine as it is C but QT and Cocoa require respectively
C++ and Objective C. Alexandre doesn't want such languages in (although he might make
an exception for the winecocoa driver if it is really, really needed).
While using a language different than C is a definitive no, I think Alexandre might allow
the use of other languages in helper programs. The best way would be to write a separate
program (which would have backends for all the needed toolkits) which generates a
.msstyles theme (or if Vista uses a newer and better format, lets directly move to that
format). The main issue would then be on how to sync themes. I guess that would need to be
done at wine startup.
Roderick
Hi,
There is a discussion going on over at
https://bugs.launchpad.net/ubuntu/+source/wine/+bug/111061 about
improving Wine's look and feel to better match the system that it is
running on.
The situation is as follows:
== Colour Schemes
Wine supports these by reading the settings from the registry. Winecfg
can load a .theme file containing a colour profile and adapt
accordingly (saving those settings to the registry).
At the moment, if you need to script this (e.g. when installing Wine)
you need to manipulate the registry. It would be helpful if winecfg
(or some other helper utility) supported setting the theme file on the
command line.
In addition to this, if the user changes the theme used on their
system it would not be reflected by Wine.
== Windows Theme Support
Windows theming support is in place to some extent, w.r.t. the XP
theming APIs. There are some user32 controls and the window/dialog
handlers that don't support theming yet and there are some performance
issues that need resolving.
This would be set via the command line used to set the colour scheme
since they can be set via the same .theme file. This is limited in
that you need an XP theme for each native theme available.
== Native Theme Support
The main thing here is that Wine would monitor the native system for
theme changes.
The colours of the native theme would be mapped to the Windows system
colours, saved to the registry and then a WM_SYSCOLORCHANGED message
would be sent to all open top-level windows so they could update to
the new look.
Any metric data would be mapped in a similar way.
As for the theme, an implementation of uxtheme would map the API calls
to the native calls. Here, it may be possible to just send a request
to redraw everything on each active window. If not, a WM_THEMECHANGED
message would need to be sent to all active windows.
The challenge with native theme support is two-fold: (1) it should
work on any system - some have Gtk, some Qt and some Cocoa/Carbon,
while others (like the *BSDs and OpenSolaris) are likely not to have
those engines available; (2) it should not break any Windows
application.
Note that as Vista has a different msstyles theming engine (it is a
DLL), we could have the msstyles DLL expose the uxtheme API and have
uxtheme call msstyles to do the rendering. That way, we could have a
gtk.msstyles, qt3.msstyles, qt4.msstyles and an carbon.msstyles that
would bind to the corresponding theming engine. If the msstyles DLL
does not expose those methods, the uxtheme engine could then fallback
to the current XP theme processing.
For Mac theme support that would possibly require Objective-C code to
be done properly, that theme could be an external package (possibly in
darwine) that would be installed in addition to Wine. The same thing
for the Qt engines, allowing them to directly interface with the C++
Qt APIs.
Thoughts? Ideas?
- Reece
--
GMX Download-Spiele: Preizsturz! Alle Puzzle-Spiele Deluxe über 60% billiger.
http://games.entertainment.gmx.net/de/entertainment/games/download/puzzle/i…
2:58 p.m.
2008/11/1 Roderick Colenbrander <thunderbird2k(a)gmx.net>et>:
In the end we need to support a bunch of different
theme engines GTK, QT, Cocoa and perhaps later on more. In theory it would be possible to
create a different uxtheme backend for each different toolkit. One major issue is the
language which each of these toolktis is written in. GTK would be fine as it is C but QT
and Cocoa require respectively C++ and Objective C. Alexandre doesn't want such
languages in (although he might make an exception for the winecocoa driver if it is
really, really needed).
I mentioned that in my email. The idea that wine would host the XP
msstyles theme (the fallback behaviour for uxtheme), and a GTK plugin
to support GTK themes. Then other projects can provide a Qt and Cocoa
plugin, so they can be written in the toolkit's language.
While using a language different than C is a
definitive no, I think Alexandre might allow the use of other languages in helper
programs. The best way would be to write a separate program (which would have backends for
all the needed toolkits) which generates a .msstyles theme (or if Vista uses a newer and
better format, lets directly move to that format). The main issue would then be on how to
sync themes. I guess that would need to be done at wine startup.
The problem with the Vista theme is that it is binary and completely
undocumented, making it very difficult to reverse engineer.
Moving forward, we'll probably need to be able to support both XP and
Vista themes (possibly Windows 7 and later as well if the theme format
has changed). I don't know if moving the processing of that into a
separate process would help, though.
When syncing themes, you can have uxtheme.dll loading the correct
engine if enabled (see my "Use the native theme" option idea in my
previous discussion on improving winecfg). Then, if the system theme
changes, the WM_THEMECHANGED message needs to be sent to all top-level
applications so they can refresh themselves to use that new theme. How
that happens and where needs to be figured out.
And yes, the bugs in uxtheme and the various controls need fixing.
- Reece
3:05 p.m.
IMHO WINE developers should first focus on applications, not their look.
I believe most users would like to see Visual Studio running in gray
instead of not running as native.
Dnia 2008-11-01, sob o godzinie 14:58 +0000, Reece Dunn pisze:
2008/11/1 Roderick Colenbrander
<thunderbird2k(a)gmx.net>et>:
In the end we need to support a bunch of
different theme engines GTK, QT, Cocoa and perhaps later on more. In theory it would be
possible to create a different uxtheme backend for each different toolkit. One major issue
is the language which each of these toolktis is written in. GTK would be fine as it is C
but QT and Cocoa require respectively C++ and Objective C. Alexandre doesn't want such
languages in (although he might make an exception for the winecocoa driver if it is
really, really needed).
I mentioned that in my email. The idea that wine would host the XP
msstyles theme (the fallback behaviour for uxtheme), and a GTK plugin
to support GTK themes. Then other projects can provide a Qt and Cocoa
plugin, so they can be written in the toolkit's language.
While using a language different than C is a
definitive no, I think Alexandre might allow the use of other languages in helper
programs. The best way would be to write a separate program (which would have backends for
all the needed toolkits) which generates a .msstyles theme (or if Vista uses a newer and
better format, lets directly move to that format). The main issue would then be on how to
sync themes. I guess that would need to be done at wine startup.
The problem with the Vista theme is that it is binary and completely
undocumented, making it very difficult to reverse engineer.
Moving forward, we'll probably need to be able to support both XP and
Vista themes (possibly Windows 7 and later as well if the theme format
has changed). I don't know if moving the processing of that into a
separate process would help, though.
When syncing themes, you can have uxtheme.dll loading the correct
engine if enabled (see my "Use the native theme" option idea in my
previous discussion on improving winecfg). Then, if the system theme
changes, the WM_THEMECHANGED message needs to be sent to all top-level
applications so they can refresh themselves to use that new theme. How
that happens and where needs to be figured out.
And yes, the bugs in uxtheme and the various controls need fixing.
- Reece
3:16 p.m.
2008/11/1 Tomasz Sałaciński <tsalacinski(a)gmail.com>om>:
IMHO WINE developers should first focus on
applications, not their look.
I believe most users would like to see Visual Studio running in gray
instead of not running as native.
Application functionality is important. Applications should run as
well as they do on Windows (ignoring Vista in that statement!) on Wine
out of the box, without the user having to do anything aside from run
the installer as they do in Windows.
That said, usability and the look and feel of an application are
important. Just compare Firefox 2 running on Linux or Mac with Firefox
3 doing the same.
Also, not all the developers know how things like the kernel,
networking or cryptographic APIs work on Windows.
I am a GUI developer, so I am focusing on what I know the best -- the UI.
- Reece
3:18 p.m.
My whole point is maintenance and distribution. Sure you could create different plugins
for uxtheme but the language limitation won't allow such plugins to enter Wine. They
would need to be maintained outside of Wine which would be bad. It has risks of bitrotting
and second it would be a pain to package it all. I don't think we want such components
maintained outside of Wine.
That all is the reason for having a 'winetheme' app which creates .msstyles themes
and which uses GTK/QT/Cocoa as I think Alexandre could perhaps live with this as we
wouldn't pollute any Wine dlls with 'bad' languages. But as I said this
approach would require syncing themes at Wine startup and theme refreshing wouldn't
work without some evil polling mechanism. Personally I wouldn't find this switching at
runtime important though and I wonder if our dlls support this at all. (That would have to
be fixed then but personally I don't give it a high priority)
Roderick
2008/11/1 Roderick Colenbrander
<thunderbird2k(a)gmx.net>et>:
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
In the end we need to support a bunch of
different theme engines GTK,
QT, Cocoa and perhaps later on more. In theory it
would be possible to create
a different uxtheme backend for each different toolkit. One major issue is
the language which each of these toolktis is written in. GTK would be fine
as it is C but QT and Cocoa require respectively C++ and Objective C.
Alexandre doesn't want such languages in (although he might make an exception
for the winecocoa driver if it is really, really needed).
I mentioned that in my email. The idea that wine would host the XP
msstyles theme (the fallback behaviour for uxtheme), and a GTK plugin
to support GTK themes. Then other projects can provide a Qt and Cocoa
plugin, so they can be written in the toolkit's language.
While using a language different than C is a
definitive no, I think
Alexandre might allow the use of other languages in helper
programs. The best
way would be to write a separate program (which would have backends for all
the needed toolkits) which generates a .msstyles theme (or if Vista uses a
newer and better format, lets directly move to that format). The main issue
would then be on how to sync themes. I guess that would need to be done at
wine startup.
The problem with the Vista theme is that it is binary and completely
undocumented, making it very difficult to reverse engineer.
Moving forward, we'll probably need to be able to support both XP and
Vista themes (possibly Windows 7 and later as well if the theme format
has changed). I don't know if moving the processing of that into a
separate process would help, though.
When syncing themes, you can have uxtheme.dll loading the correct
engine if enabled (see my "Use the native theme" option idea in my
previous discussion on improving winecfg). Then, if the system theme
changes, the WM_THEMECHANGED message needs to be sent to all top-level
applications so they can refresh themselves to use that new theme. How
that happens and where needs to be figured out.
And yes, the bugs in uxtheme and the various controls need fixing.
- Reece
3:33 p.m.
2008/11/1 Roderick Colenbrander <thunderbird2k(a)gmx.net>et>:
My whole point is maintenance and distribution. Sure
you could create different plugins for uxtheme but the language limitation won't allow
such plugins to enter Wine. They would need to be maintained outside of Wine which would
be bad. It has risks of bitrotting and second it would be a pain to package it all. I
don't think we want such components maintained outside of Wine.
Sure. Those are potential problems. You can mitigate that by having an
extensible versioned API. COM (despite its flaws) has mechanisms in
place to support upward and backward compatibility of both sides of
the call (in this case uxtheme and the theme engine binding) and is
thus a potential platform for the API. A flat C API would work as
well, though.
That all is the reason for having a
'winetheme' app which creates .msstyles themes and which uses GTK/QT/Cocoa as I
think Alexandre could perhaps live with this as we wouldn't pollute any Wine dlls with
'bad' languages. But as I said this approach would require syncing themes at Wine
startup and theme refreshing wouldn't work without some evil polling mechanism.
Personally I wouldn't find this switching at runtime important though and I wonder if
our dlls support this at all. (That would have to be fixed then but personally I don't
give it a high priority)
Generating msstyles themes on the fly seems too complicated to me, as
well as being time consuming and potentially resource intensive. Also,
will winetheme be implemented to support all the available theme
engines in the single binary? If so, what about supporting additional
engines (e.g. Enlightenment)? How will it support both the Qt3 and Qt4
APIs? How do you differentiate what are available at build time and
what are available at runtime?
- Reece
3:49 p.m.
A tool which creates a .msstyles theme basically does the same as a uxtheme engine would
do. A uxtheme engine plugin would use gtk/qt/cocoa to load colors, bitmaps and so on in a
representation needed by uxtheme. The winetheme app would do the same but also have a way
to write this data back from uxtheme into a .msstyles theme. I don't know the uxtheme
API but it might already offer functionality for this (I mean creating a .msstyles theme
from source).
The winetheme app would have plugins for gtk, qt and so on. Using winecfg you would need
to set the WineLook to gtk/qt/cocoa and the winetheme app would use the requested backend.
At startup winetheme could also detect which of the plugins are available. Plugins are
compiled at Wine compile time and when a new toolkit comes out (gtk2->gtk3,
qt3->qt4,..) we need to update the plugin or add a new one.
Roderick
2008/11/1 Roderick Colenbrander
<thunderbird2k(a)gmx.net>et>:
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
My whole point is maintenance and distribution.
Sure you could create
different plugins for uxtheme but the language limitation
won't allow such
plugins to enter Wine. They would need to be maintained outside of Wine which
would be bad. It has risks of bitrotting and second it would be a pain to
package it all. I don't think we want such components maintained outside of
Wine.
Sure. Those are potential problems. You can mitigate that by having an
extensible versioned API. COM (despite its flaws) has mechanisms in
place to support upward and backward compatibility of both sides of
the call (in this case uxtheme and the theme engine binding) and is
thus a potential platform for the API. A flat C API would work as
well, though.
That all is the reason for having a
'winetheme' app which creates
.msstyles themes and which uses GTK/QT/Cocoa
as I think Alexandre could perhaps
live with this as we wouldn't pollute any Wine dlls with 'bad' languages.
But as I said this approach would require syncing themes at Wine startup and
theme refreshing wouldn't work without some evil polling mechanism.
Personally I wouldn't find this switching at runtime important though and I wonder
if our dlls support this at all. (That would have to be fixed then but
personally I don't give it a high priority)
Generating msstyles themes on the fly seems too complicated to me, as
well as being time consuming and potentially resource intensive. Also,
will winetheme be implemented to support all the available theme
engines in the single binary? If so, what about supporting additional
engines (e.g. Enlightenment)? How will it support both the Qt3 and Qt4
APIs? How do you differentiate what are available at build time and
what are available at runtime?
- Reece 
5:10 p.m.
On 01.11.2008 16:49, Roderick Colenbrander wrote:
The winetheme app would have plugins
So winetheme would have plugins - that seems to make the whole thing an
additional complication over straight uxtheme plugins, since you have
the application as an extra layer in the middle. And as already said, an
application may complicate things such as reacting to theme changes on
the fly.
-f.r.
6:51 p.m.
On Sat, Nov 1, 2008 at 1:10 PM, Frank Richter <frank.richter(a)gmail.com> wrote:
So winetheme would have plugins - that seems to make
the whole thing an
additional complication over straight uxtheme plugins, since you have
the application as an extra layer in the middle. And as already said, an
application may complicate things such as reacting to theme changes on
the fly.
I've been lurking on this thread for a while and it seems to me the
problem with themes really is one Wine cannot solve. I don't know if
the LSB or FDo specs have a human interface guideline system but it
seems to me there needs to be some sort of theme engine bridge or some
such at a lower level than WIne that the differing toolkits can use to
come close to having a consistent interface even if its not 100% all
of the time. I know there used to be back in the KDE2 days support to
use GTK 1.x themes but this was before the days of FreeDesktop.org.
The right solution it would seem, if we cannot get proper human
interface guidelines for linux, at get a free desktop spec that lays
out a generic theme engine any of these toolkits can plug in to or a
common file format they can all read at least. Perhaps that theme
engine spec should then have a case for output in a format that Wine
can understand or Wine's uxtheme and whatever else could be extended
to read this FDo theme spec. We already do such a similar thing in
shell32 for XDG Folders and the Root unix namespace. Of course this
would not address Aqua/OS case but such a spec if adopted by
KDE/GNOME/Enlightenment/etc would do wonders for us on
BSD/Linux/Solaris/etc.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
8:21 p.m.
2008/11/1 Steven Edwards <sedwards(a)bordeauxgroup.com>om>:
On Sat, Nov 1, 2008 at 1:10 PM, Frank Richter
<frank.richter(a)gmail.com> wrote:
Wine can create an infrastructure to support bindings to different
toolkits. Due to the nature of some of those toolkits, some of the
bindings will have to live outside the Wine tree. So in that respect,
the problem can be something that Wine can solve.
So winetheme would have plugins - that seems to
make the whole thing an
additional complication over straight uxtheme plugins, since you have
the application as an extra layer in the middle. And as already said, an
application may complicate things such as reacting to theme changes on
the fly.
I've been lurking on this thread for a while and it seems to me the
problem with themes really is one Wine cannot solve. I don't know if
the LSB or FDo specs have a human interface guideline system but it
seems to me there needs to be some sort of theme engine bridge or some
such at a lower level than WIne that the differing toolkits can use to
come close to having a consistent interface even if its not 100% all
of the time. I know there used to be back in the KDE2 days support to
use GTK 1.x themes but this was before the days of FreeDesktop.org.
It would be fantastic to have one or more FDo specs for human-computer
interaction and - specifically for this topic - theming, widgets and
rendering those widgets using the selected theme.
In order to do that properly, you will need major buy-in from the Gtk,
Qt and other widget toolkit developers, as well as from Firefox,
OpenOffice, Gimp and other applications that have to have
infrastructures in place to support different toolkits. Done right, it
would mean that applications would only need to write to one back-end
to render the various widgets. They would need to ensure that the
correct bindings for this are on the system, but the bindings could be
external packages to the applications (for Mac, Windows and existing
versions of the Widget libraries) or in the widget libraries
themselves (for Gtk, Qt and others), so that you have a consistent
implementation.
The spec would also need to provide a way of notifying applications
when the theme has changed.
This would have the benefit of applications written using Gtk, Qt or
some other framework looking native on the users system.
The right solution it would seem, if we cannot get
proper human
interface guidelines for linux, at get a free desktop spec that lays
out a generic theme engine any of these toolkits can plug in to or a
common file format they can all read at least. Perhaps that theme
engine spec should then have a case for output in a format that Wine
can understand or Wine's uxtheme and whatever else could be extended
to read this FDo theme spec. We already do such a similar thing in
shell32 for XDG Folders and the Root unix namespace. Of course this
would not address Aqua/OS case but such a spec if adopted by
KDE/GNOME/Enlightenment/etc would do wonders for us on
BSD/Linux/Solaris/etc.
For Aqua/OS you would have an external package that implemented the
FDo spec and mapped it to the correct Carbon calls. Similarly for
Windows.
Also, it would be possible to provide an implementation of the spec
that used an msstyles/theme file. This would mean that the existing
uxtheme handling of the msstyles format will move there and the
uxtheme dll will just make the correct FDo spec calls. That also opens
up to people being able to use XP themes as the theme on their system
if they so choose.
- Reece
2 Nov
2 Nov
2:47 a.m.
On Sat, Nov 1, 2008 at 4:21 PM, Reece Dunn <msclrhd(a)googlemail.com> wrote:
Wine can create an infrastructure to support bindings
to different
toolkits. Due to the nature of some of those toolkits, some of the
bindings will have to live outside the Wine tree. So in that respect,
the problem can be something that Wine can solve.
Maybe I should not have said that wine cannot solve it but that Wine
alone cannot solve this problem without a proper HIG or Theming spec
as part of FDo would be an effort doomed to obsolescence or constant
maintaince. Francois spent a lot of time working on menus for
CodeWeavers as the menu system evolved on Linux over the years and the
ultimate results we see with XDG are the result of evolution and
catchup until a good spec was ultimately written and adopted. Thanks
to this spec, the portland toolset was developed and many new
applications don't have to go through hell just to do simple stuff
like creating and deleting menus in an automated fashion.
It would be fantastic to have one or more FDo specs
for human-computer
interaction and - specifically for this topic - theming, widgets and
rendering those widgets using the selected theme.
In order to do that properly, you will need major buy-in from the Gtk,
Qt and other widget toolkit developers, as well as from Firefox,
OpenOffice, Gimp and other applications that have to have
infrastructures in place to support different toolkits. Done right, it
would mean that applications would only need to write to one back-end
to render the various widgets. They would need to ensure that the
correct bindings for this are on the system, but the bindings could be
external packages to the applications (for Mac, Windows and existing
versions of the Widget libraries) or in the widget libraries
themselves (for Gtk, Qt and others), so that you have a consistent
implementation.
The spec would also need to provide a way of notifying applications
when the theme has changed.
This would have the benefit of applications written using Gtk, Qt or
some other framework looking native on the users system.
It sounds like we have the beginnings of the requirements section for a
proposed specification already =)
For Aqua/OS you would have an external package that
implemented the
FDo spec and mapped it to the correct Carbon calls. Similarly for
Windows.
Also, it would be possible to provide an implementation of the spec
that used an msstyles/theme file. This would mean that the existing
uxtheme handling of the msstyles format will move there and the
uxtheme dll will just make the correct FDo spec calls. That also opens
up to people being able to use XP themes as the theme on their system
if they so choose.
I like this idea. If the msstyles/theme file format is already
documented and not license restricted I don't see any reason why the
spec could not adopt the Microsoft format or something similar to it.
As I stated in my first reply, I know less than nothing about themes
and the current state of Linux Human Interface Guidelines with regards
to theming. If the consensus is that before this theming bridge tool
is developed, that we look in to making it or a library/file format
regarding theming a standard part of FD.o, I am happy to do some
research and help write a draft spec with you.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
1:40 p.m.
On 01.11.2008 21:21, Reece Dunn wrote:
In order to do that properly, you will need major
buy-in from the Gtk,
Qt and other widget toolkit developers,
FWIW, I recall having read some Planet GNOME blog posts where people
expressed, well, a bit of unhappiness with GTK's current theming system.
(Apparently a lot of hacks are needed, some even for specific
applications.) So a buy-in might be possible from them, if you promise
something better than you have now ;)
-f.r.
1 Nov
1 Nov
2:07 p.m.
On 01.11.2008 14:04, Reece Dunn wrote:
Note that as Vista has a different msstyles theming
engine (it is a
DLL),
It's also a DLL on XP. Note that in both cases no code is exported, the
DLLs serve only as a container for the theme data, stored as resources.
we could have the msstyles DLL expose the uxtheme API
and have
uxtheme call msstyles to do the rendering. That way, we could have a
gtk.msstyles, qt3.msstyles, qt4.msstyles and an carbon.msstyles
That sounds like misappropriating the msstyles 'format'. The idea of
"theming engine plugins" is a good one, but then some other mechanism
than abusing the msstyles extension should be used to detect these
plugins. Some ideas: an extension (but a different, unique one), putting
them into a special directory, listing engines in the registry.
Anyhow, this is somewhat bikeshedding ;P
First step would probably be to define a theming plugin API - you say
that the theming plugins would just export the whole uxtheme API.
However, it could be possible that the theming plugin interface can be
simplified compared to that, with uxtheme.dll filling the gaps. (After
all, a simpler interface can mean a simpler plugin implementation...)
-f.r.
3:06 p.m.
2008/11/1 Frank Richter <frank.richter(a)gmail.com>om>:
:). Your point makes more sense.
On 01.11.2008 14:04, Reece Dunn wrote:
we could have
the msstyles DLL expose the uxtheme API and have
uxtheme call msstyles to do the rendering. That way, we could have a
gtk.msstyles, qt3.msstyles, qt4.msstyles and an carbon.msstyles
That sounds like misappropriating the msstyles 'format'. The idea of
"theming engine plugins" is a good one, but then some other mechanism
than abusing the msstyles extension should be used to detect these
plugins. Some ideas: an extension (but a different, unique one), putting
them into a special directory, listing engines in the registry.
Anyhow, this is somewhat bikeshedding ;P First step would probably be to define a theming
plugin API - you say
that the theming plugins would just export the whole uxtheme API.
However, it could be possible that the theming plugin interface can be
simplified compared to that, with uxtheme.dll filling the gaps. (After
all, a simpler interface can mean a simpler plugin implementation...)
That is a good idea.
It would also be a good idea to look at the capabilities of the major
theming engines (Gtk, Qt, Cocoa) and possibly some others like the one
used by Enlightemnent and try to abstract an API that can accommodate
them all in a straightforward way.
Note also that there is the added complication that the interface wine
uses will need to be a native one, so it can interact with the native
cocoa, qt or gtk libraries.
- Reece
3:13 p.m.
On 01.11.2008 16:06, Reece Dunn wrote:
It would also be a good idea to look at the
capabilities of the major
theming engines (Gtk, Qt, Cocoa) and possibly some others like the one
used by Enlightemnent and try to abstract an API that can accommodate
them all in a straightforward way.
Definitely.
Note also that there is the added complication that
the interface wine
uses will need to be a native one, so it can interact with the native
cocoa, qt or gtk libraries.
This is already done in Wine, e.g. look at some of the TWAIN plugins
Wine ships - they're DLLs but access native APIs like gphoto, iirc.
-f.r.
20 Dec
20 Dec
7:05 p.m.
Reece Dunn-2 wrote:
Thoughts? Ideas?
I'm just a user, not a dev, so forgive me if this sounds stupid, but it
seems to me like it would be simpler to just create some sort of layer that
forwards all calls to the Win32 theming API to Qt, and make Wine dependent
on Qt (perhaps as a GSoC project?). Qt bends over backwards to maintain a
native look and feel on all major platforms, including Windows, OS X,
KDE/X11, and GNOME/Xfce/BBQ/X11 (in 4.5), so Wine's codebase wouldn't have
to be overly complicated by hacks to support each platform. This approach
would also have the benefit of rendering the QuartzDriver planned for Wine
1.2 completely unnecessary, if I'm not mistaken. Since Qt is maintained by a
ton of devs unrelated to the Wine project, this would also allow Wine to
ignore changes in this area specific to each platform, whereas with other
approaches I've seen in this thread Wine would have to constantly adapt to
each change and put in the work necessary to port the native theming to a
new platform; of course, Wine would still have to adapt to changes in the Qt
API, but that would be much more predictable and presumably less to deal
with.
--
View this message in context:
http://www.nabble.com/Wine-integration-with-native-%28Gtk%2C-Qt%2C-Cocoa-Ca…
Sent from the Wine - Devel mailing list archive at Nabble.com.
11:12 p.m.
Reece Dunn-2 wrote:
This is technically not possible. We can't use native APIs for drawing.
Roderick
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
http://www.gmx.net/de/go/multimessenger
Thoughts? Ideas?
I'm just a user, not a dev, so forgive me if this sounds stupid, but it
seems to me like it would be simpler to just create some sort of layer
that
forwards all calls to the Win32 theming API to Qt, and make Wine dependent
on Qt (perhaps as a GSoC project?). Qt bends over backwards to maintain a
native look and feel on all major platforms, including Windows, OS X,
KDE/X11, and GNOME/Xfce/BBQ/X11 (in 4.5), so Wine's codebase wouldn't have
to be overly complicated by hacks to support each platform. This approach
would also have the benefit of rendering the QuartzDriver planned for Wine
1.2 completely unnecessary, if I'm not mistaken. Since Qt is maintained by
a
ton of devs unrelated to the Wine project, this would also allow Wine to
ignore changes in this area specific to each platform, whereas with other
approaches I've seen in this thread Wine would have to constantly adapt to
each change and put in the work necessary to port the native theming to a
new platform; of course, Wine would still have to adapt to changes in the
Qt
API, but that would be much more predictable and presumably less to deal
with.
--
View this message in context:
http://www.nabble.com/Wine-integration-with-native-%28Gtk%2C-Qt%2C-Cocoa-Ca…
Sent from the Wine - Devel mailing list archive at Nabble.com.
11:52 p.m.
Roderick Colenbrander wrote:
This is technically not possible. We can't use native APIs for drawing.
Ah, that sucks. Out of curiosity, why is that? As a non-dev, logically it
seems like Wine, which translates Win32 calls for the kernel and X11, would
be able to do the same for Qt, but then again I know next to nothing about
the internals of Wine. Is it that doing so would require a major redesign,
isn't feasible for whatever reason, or just isn't possible at all?
--
View this message in context:
http://www.nabble.com/Wine-integration-with-native-%28Gtk%2C-Qt%2C-Cocoa-Ca…
Sent from the Wine - Devel mailing list archive at Nabble.com.
21 Dec
21 Dec
12:39 a.m.
buu700 wrote:
Roderick Colenbrander wrote:
Windows' standard controls, windows, fonts, etc work completely different
from QT ones. Win32 API exposes a lot of inner-workings of each control. And
lots of applications depend on that. I'm not even talking about how the
pieces fit together.
In short - for most windows apps to work controls have to behave in a very
particular way which dramatically differs from any other toolkit.
And no Wine doesn't just "translates win calls to kernel and X". Wine
re-implements all of the windows' user space on top of X, kernel and other
libraries.
Vitaliy
This is technically not possible. We can't
use native APIs for drawing.
Ah, that sucks. Out of curiosity, why is that? As a non-dev, logically it
seems like Wine, which translates Win32 calls for the kernel and X11, would
be able to do the same for Qt, but then again I know next to nothing about
the internals of Wine. Is it that doing so would require a major redesign,
isn't feasible for whatever reason, or just isn't possible at all?
5630
days inactive
5680
days old
19 comments
7 participants
participants (7)
-
buu700 -
Frank Richter -
Reece Dunn -
Roderick Colenbrander -
Steven Edwards -
Tomasz Sałaciński -
Vitaliy Margolen