April 2016 - Wine-Devel - list.winehq.org

Re: kernel32: add GetVolumeInformationByHandleW stub (try 2)

by Austin English

On Wed, Apr 27, 2016 at 12:25 AM, Alex Henrie <alexhenrie24(a)gmail.com> wrote: > Two things, both nitpicks: > > 1. I wrap lines to 120 characters. Most other developers wrap to 80 or > 100. A line with 181 characters seems excessive. > > 2. Your prototype in winbase.h uses DWORD * and WCHAR * whereas the > surrounding prototypes use LPDWORD and LPWSTR. > > -Alex Thanks Alex. -- -Austin

April 27, 2016

Re: [1/5] wininet: Fix async check in HTTPREQ_ReadFileEx. (resend)

by Sebastian Lackner

On 26.04.2016 23:37, Sebastian Lackner wrote: > From: Michael Müller <michael(a)fds-team.de> > > Signed-off-by: Michael Müller <michael(a)fds-team.de> > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > dlls/wininet/http.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) I do not see anything obviously wrong with this patch, but it seems to cause at least one regression (maybe unhandled IRF_SYNC?). I would vote for defering patch 1-4 until the issue has been investigated. Patch 5 can be applied independently and only affects the tests, so it should be fine.

April 27, 2016

Re: The future of the native theming support

by Alexandre Julliard

Ivan Akulinchev <ivan.akulinchev(a)gmail.com> writes: >> Improvements to the existing comctl32 and uxtheme to properly support >> Windows themes would be most welcome, and would be a prerequisite for > other changes anyway. More test cases would also be very helpful. > > The best way to test uxtheme.dll is to create an own theme. However > Windows has a protection against third-party themes. It’s easy to break, > but isn’t allowed by EULA. Do we need Wine-only tests? I expect that it would be possible to test already quite a bit by using the standard Windows themes. > Again, the only thing I want to change is a library, corresponding for > providing of some images. This images can NOT break anything. The reason > why I don't use the existing implementation is because the algorithm of > generating this images is not trivial and it's very hard to implement it > using the existing (MSSTYLES) file format. If it's only the images, I agree that it's less likely to break things, but it's not a very good user experience either, since the controls look native but behave like Windows controls. That doesn't mean it couldn't be added as an option, but we should first make sure that we can support MSSTYLES themes properly, and ideally provide some decent-looking default theme with Wine. -- Alexandre Julliard julliard(a)winehq.org

April 27, 2016

Re: kernel32: add GetVolumeInformationByHandleW stub (try 2)

by Alex Henrie

Two things, both nitpicks: 1. I wrap lines to 120 characters. Most other developers wrap to 80 or 100. A line with 181 characters seems excessive. 2. Your prototype in winbase.h uses DWORD * and WCHAR * whereas the surrounding prototypes use LPDWORD and LPWSTR. -Alex

April 27, 2016

Re: [PATCH 4/7] winex11.drv: elimininate the unnecessary XDND critical section

by Alexandre Julliard

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > Everything happens on the UI thread, so there's no point in > doing any synchronization. What UI thread? Aren't the messages handled by the standard per-thread message loop? -- Alexandre Julliard julliard(a)winehq.org

April 27, 2016

Re: kernel32: add GetVolumeInformationByHandleW stub (try 2)

by Austin English

On Wed, Apr 6, 2016 at 5:34 PM, Austin English <austinenglish(a)gmail.com> wrote: > -- > -Austin Could I get some feedback on this patch please? -- -Austin

April 27, 2016

Re: The future of the native theming support

by Joel Holdsworth

> I saw some screenshots by the Wine Staging team [7, 8] and it was > terrible. By the way, someone asked me why does the existing > implementation suck. Just look at the screenshots [7] and [8] again. > This is the limit of what can be done by replacing the uxtheme.dll > implementation. If you want more, comctl32 should be fixed. This is my experience running Adwaita: https://airwebreathe.org.uk/lib/exe/fetch.php?media=space:20160426-wine-gtk… . - Clipped tab edges - Clipped check boxes - Clipped slider handle It looks a bit better if I boost the DPI so that the font size matches the rest of the desktop. But the clipping issues don't go away. Joel

April 26, 2016

Re: The future of the native theming support

by Ivan Akulinchev

> I recommend having a conversation with the author of those > wine-staging patches As far as I know, the feature you have seen in Wine Staging is based on my old Proof-of-Concept implementation of this idea [1, 2], and this conversation with myself would be a little bit weird. I have tested it with some popular themes and it looks fine for me [3, 4, 5, 6]. But then I saw some screenshots by the Wine Staging team [7, 8] and it was terrible. By the way, someone asked me why does the existing implementation suck. Just look at the screenshots [7] and [8] again. This is the limit of what can be done by replacing the uxtheme.dll implementation. If you want more, comctl32 should be fixed. So, my solution wasn’t perfect, I agree. But to fix it, I’ll have to do a lot of changes inside the existing Wine code. And that’s the problem. [1] https://github.com/akulinchev/uxthemegtk [2] https://wine-staging.com/news/2015-08-09-release-1.7.49.html [3] https://github.com/akulinchev/uxthemegtk/raw/master/dist/winecfg-clearlooks… [4] https://github.com/akulinchev/uxthemegtk/raw/master/dist/winecfg2-clearlook… [5] https://github.com/akulinchev/uxthemegtk/raw/master/dist/winecfg-ambiance.p… [6] https://github.com/akulinchev/uxthemegtk/raw/master/dist/winecfg2-ambiance.… [7] https://wine-staging.com/images/gtk3_winecfg.png [8] https://wine-staging.com/images/gtk3_file.png On 26.04.2016 17:35, Joel Holdsworth wrote: > >> There also were some questions about integrating new themes to the >> existing system. If it matters, I found a way to make it transparently >> for the end users. A new "GTK+" or even "Mac" theme can live together >> with old MSSTYLES themes without need of switching any "theme drivers" >> as it was said in my GSoC proposal. > > wine-staging has an optional feature to do this with Gtk [1]. The > results are so-so. > > The issue is that typically uxtheme and an external toolkit have very > different ways of describing layout and therefore the there is no 1:1 > mapping between any arbitrary Gtk theme and uxtheme. The result is that > certain themes look much more glitchy than others - but it will look > extremely crappy if the integration is less than pixel perfect, which is > going to be extremely hard without lots of fragile heuristics, or manual > artistic tweaks. > > I recommend having a conversation with the author of those wine-staging > patches, so you can find out how things are going with that. He's got > some things working, but still lots of glitches. These glitches may be > fixable - but I'm fearful that some problems may come down to a design > conflict between windows and Gtk+. > > If you want to spend time on this, I personally would love to see it > come to fruition - but be warned, it's a risky project. > > In some ways this is analogous to the wine icon set. Ideally it would be > nice to pick up icons from the host /usr/share/icons directory. The > problem being that in windows, icons are baked into the executable > binary. In principle applications could be tricked about the binary > resources at runtime, but in practice this is getting into very > unpleasant territory where we're in severe danger of causing breakage. > > So when I updated the icons [2], I chose the Tango icon theme because it > represented a modern-looking compromise between the icon styles of most > desktop environments. > > Andrew Eikum's suggestion is rather similar, but for the ux theme. To me > that sounds a lot easier to do. > > Joel > > [1] > https://github.com/wine-compholio/wine-staging/tree/master/patches/uxtheme-… > > [2] https://airwebreathe.org.uk/doku.php?id=wine_icons > > >

April 26, 2016

Re: The future of the native theming support

by Ivan Akulinchev

> Improvements to the existing comctl32 and uxtheme to properly support > Windows themes would be most welcome, and would be a prerequisite for other changes anyway. More test cases would also be very helpful. The best way to test uxtheme.dll is to create an own theme. However Windows has a protection against third-party themes. It’s easy to break, but isn’t allowed by EULA. Do we need Wine-only tests? > Whether we want to load a native toolkit to replace common controls is > debatable, and that part is not going to get upstream without some > very convincing arguments. But I don't want to *replace* common controls with a native toolkit. I suggest another solution. There is already a way for styling this controls. For example, there is a function DrawThemeBackground [1]. GTK provides a similar function named gtk_render_background [2]. The only thing we need to do, is to convert the arguments of the first function to the arguments of the second one. In this case, DrawThemeBackground works with a GDI device context, and gtk_render_background uses as Cairo surface. This thing was already done. Then I figured out, the communication between Common Controls and Visual Styles API is very poor. According to MSDN, it's not a design problem, rather an implementation. This way I want to improve this "communication" and to make the existing UxTheme implementation friends with GTK. Again, the only thing I want to change is a library, corresponding for providing of some images. This images can NOT break anything. The reason why I don't use the existing implementation is because the algorithm of generating this images is not trivial and it's very hard to implement it using the existing (MSSTYLES) file format. > A tool to generate Windows themes from the native ones would probably > give most of the benefits, without the compatibility issues of a > native toolkit. Many themes are shipped in different implementations. This way we can make our msstyles implementations for the most common themes and change winecfg to look for the available themes in Z:\usr\share\themes\*\mssttyles as well. However we can’t do it automatically. The basic idea of Windows themes is too split all controls in 9 areas and combine it for the requested size. First of all, we don’t know where to crop. Then, many GTK themes have a complex background. If you try to stretch it, the result will be terrible. So I’m against this idea. See also the last paragraph of the previous point. For example, you want to create a button. The code corresponding for the signals handling and so on still lives in comctl32.dll. It also calls uxtheme.dll to draw a representation of this button in some area. But now uxtheme.dll draws this representation according to a bitmap from a .msstyles file and I want to get this bitmap directly from GTK. Just a bitmap, with the same size and the same purpose. And nothing more. I fail to see how can this bitmap break something in an application. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/bb773289%28v=vs.85… [2] https://developer.gnome.org/gtk3/stable/GtkStyleContext.html#gtk-render-bac… On 26.04.2016 15:58, Alexandre Julliard wrote: > Ivan Akulinchev <ivan.akulinchev(a)gmail.com> writes: > >> So my GSoC proposal wasn't accepted this year. Probably it was my >> mistake by applying it too late, but this mail is not about this. >> >> Since a big research was already done, it would be fine to implement >> this feature anyway. The problem is that I still don't know what such >> people as Alexandre Julliard think about it. I got some positive >> feedback from normal users and even some Wine developers. However they >> don't make decisions about the Wine future and I don't want to spend >> my time if this feature will never get into upstream. > > Improvements to the existing comctl32 and uxtheme to properly support > Windows themes would be most welcome, and would be a prerequisite for > other changes anyway. More test cases would also be very helpful. > > Whether we want to load a native toolkit to replace common controls is > debatable, and that part is not going to get upstream without some very > convincing arguments. > > A tool to generate Windows themes from the native ones would probably > give most of the benefits, without the compatibility issues of a native > toolkit. >

April 26, 2016

Re: The future of the native theming support

by Ivan Akulinchev

> I don't think anyone is ideologically opposed to the idea, but the > problem is it's very hard to get right in such a way that won't break > applications. Honestly I didn't see a popular GTK theme without tons of comments like "Oh my God! They killed XXX!". This way, if a GTK theme can break a native GTK application, a conflict with Windows applications is very likely. However this "break" doesn't mean a SEGFAULT crash, rather an unpleasant sight. You shouldn’t use this feature if you don't like it. On 25.04.2016 17:59, Andrew Eikum wrote: > On Mon, Apr 25, 2016 at 10:23:43AM +0200, Ivan Akulinchev wrote: >> As far as I know there already were some attempts to do something in >> this direction. But interesting patches I found in wine-patches were >> left without any response and Wine still looks like a monster from >> 90s. At the same time I see a lot of patches affecting the DirectX >> API. Is it the official position of the Wine maintainers to keep >> Wine as an OpenGL wrapper? Of course there are a lot of users who >> just want to play their Windows games on the Unix-like systems, but >> the need of working with normal desktop applications is still very >> high. >> > > I don't think anyone is ideologically opposed to the idea, but the > problem is it's very hard to get right in such a way that won't break > applications. I think a more likely option would be to bring it up to > look like a modern Windows UI, or just any generic "modern" UI, even > if it doesn't match the native toolkit. But even that would be a > massive and difficult undertaking. > > Andrew >

April 26, 2016