I'd like to point out that DESKTOP_SESSION=KDE isn't a robust way to detect oxygen-gtk. I use it in XFCE, for example, too. If not checking the theme name, it'd be better to refrain from refusing to use gtk3 on KDE, as the user may have set up a simpler to emulate GTK theme.
On Sat, Mar 26, 2016 at 10:34 PM, Ivan Akulinchev ivan.akulinchev@gmail.com wrote:
I wrote a brief roadmap:
- Improve uxtheme handles. Currently they are just void pointers to the internal structures. All other libraries do it using a handle table [1, 2, 3].
- Move all MSSTYLES-related code to winemsstyles.drv. At this step such uxtheme functions as DrawThemeBackground will be stubbed.
- Add support for uxtheme drivers. At the startup the registry key HKCU\Software\Wine\Drivers\Theme will be read. This is a comma- separated list such as "gtk3,qt5,mac,msstyles". In the loop all drivers will be tried until the working one found. Note the suggested order. If winegtk3.drv see the DESKTOP_SESSION environment variable is set to KDE, it should return FALSE from the entry point, so wineqt5.drv will be tried. This is a bug founded by Ruslan Kabatsayev last year [4]. If nothing found, the last one (winemsstyles.drv) should be used.
- Work on the activation context. This is a complex step I need to describe separately...
- Implement Buffered Paint API [5].
- Add double buffering support to comctl32 (I hate flipping!!!)
- Add support for animated transitions like Windows Vista does.
- Fix other problems in comctl32 that I hate...
- Move the existing code from uxthemegtk [6] to winegtk3.drv.
- Improve winegt3.drv until the deadline ;-)
[1] https://github.com/wine-mirror/wine/blob/master/dlls/gdi32/gdiobj.c [2] https://github.com/wine-mirror/wine/blob/master/dlls/winhttp/handle.c [3] https://github.com/wine-mirror/wine/blob/master/server/handle.c [4] https://www.winehq.org/pipermail/wine-devel/2015-July/108232.html [5] https://msdn.microsoft.com/en-us/library/windows/desktop/bb773257%28v=vs.85%... [6] https://github.com/akulinchev/uxthemegtk