December 2018 - Wine-Devel - list.winehq.org

Re: [PATCH 1/2] po: Updated French translation.

by Nikolay Sivov

On 12/31/18 2:16 AM, Isira Seneviratne wrote: > #: msi.rc:99 > -#, fuzzy > -#| msgid "Exception in service.\n" > msgid "Deleting services" > -msgstr "Exception durant l'exécution du service.\n" > +msgstr "Exception durant l'exécution du service" That's not a translation, same for many other changes. > #: winemine.rc:80 > msgid "Congratulations!" > -msgstr "Félicitations !" > +msgstr "Félicitations!" Why are you changing this?

Dec. 31, 2018

[PATCH 2/2] po: Updated Sinhala translation.

by Isira Seneviratne

Dec. 30, 2018

[PATCH 1/2] po: Updated French translation.

by Isira Seneviratne

Dec. 30, 2018

Re: [PATCH v2] systray: Hide systray for fullscreen games

by Stefan Dösinger

Am 30.12.18 um 14:57 schrieb Gabriel Ivăncescu: > You probably want to check if there's a full screen window somehow, or > use MonitorFromWindow / GetMonitorInfo / GetWindowRect and compare, but > I don't know if that's a good way to go about this. There's a is_window_rect_fullscreen() in x11drv/x11drv.h that could provide some guidance.

Dec. 30, 2018

Re: [PATCH 2/2] comctl32/listview: Add FIXMEs for LVM_MOVEITEMTOGROUP and LVM_MOVEGROUP messages

by Gabriel Ivăncescu

On 12/30/18 08:02, Nikolay Sivov wrote: > On 12/30/18 6:19 AM, Isira Seneviratne wrote: > >> - /* case LVM_MOVEGROUP: */ >> + case LVM_MOVEGROUP: >> + FIXME("LVM_MOVEGROUP: unimplemented by Microsoft\n"); >> + return FALSE; >> - /* case LVM_MOVEITEMTOGROUP: */ >> + case LVM_MOVEITEMTOGROUP: >> + FIXME("LVM_MOVEITEMTOGROUP: unimplemented by Microsoft\n"); >> + return FALSE; > What's a point of this? > > Maybe it would make sense if tests show that it indeed returns 0 (as if msg is processed).

Dec. 30, 2018

Re: [PATCH v2] systray: Hide systray for fullscreen games

by Gabriel Ivăncescu

On 12/30/18 02:54, Hamish Claxton wrote: > Hi Fabian, > > Yes, this only hides the tray when it should. The code only happens on > the WM_DISPLAYCHANGE event, which occurs on resolution changes. I > wouldn't write any code that would damage any existing features. > > While the resolutions shouldn't differ, actually the SM_CYFULLSCREEN > reports a larger dimension by 11. What happens is beforehand, the > systray was getting drawn no matter what on a resolution update. This > patch checks if the current foreground game is covering the entire > screen, hence covering the area where the systray would normally be > drawn, which is also the entire desktop resolution, and if it is, does > not draw the systray. > > I tested this patch thoroughly and it only enhances existing functionality. > > Thanks in Advance, > Hamish > GetSystemMetrics, as its name implies, gives system metrics (constants) and not that of the current foreground game as you want. It will always apply. Furthermore, this doesn't handle situation with multiple displays. You probably want to check if there's a full screen window somehow, or use MonitorFromWindow / GetMonitorInfo / GetWindowRect and compare, but I don't know if that's a good way to go about this.

Dec. 30, 2018

Re: [PATCH 8/9] quartz/vmr9: Use assignment instead of CopyRect

by Gabriel Ivăncescu

On 12/30/18 00:27, Michael Stefaniuc wrote: > On 12/29/18 12:24 PM, Gabriel Ivăncescu wrote: >> On 12/28/18 23:20, Michael Stefaniuc wrote: >>> I'm assuming those methods will do argument validation with proper error >>> code should the RECTs be NULL. Needs tests of course. But that's the >>> reason I didn't replace those when I did my CopyRect() removals back in >>> the day. >>> >>> Also we are in change freeze and pure janitorial work is kinda forbidden >>> during that; especially in the later rc versions. >>> >> >> Sorry, I had assumed that it's mostly janitorial work that is acceptable >> during code freeze, that's why I sent them, my bad :-) >> >> To be honest, I agree with Nikolay's point about most of these remaining >> CopyRect (except those not requiring NULL checks, like the combobox >> CopyRect removal). >> >> But in such case, they should have inline helpers to be consistent with >> the others. Hopefully it's reconsidered after code freeze (the original >> inline patch), though I will split it into PtInRect and CopyRect >> separately, at least for consistency. > Really, there is no need for consistency here. The inline versions were > introduced to avoid the addition of a cross dll function call when the > open coded stuff was replaced. > > bye > michael > But the cross dll function call happens in this case also. I understand why they were introduced, but it doesn't mean that should be the only reason they can be introduced. For example, if this function started with open coding and then got replaced with CopyRect, I assume you would add the inline version, correct? Even though the code in the end would be identical to now. That's why it seems so arbitrary and confusing for someone who skims through the code. I understand why you did not add them yourself, but that doesn't mean they shouldn't be added, at least for consistency's sake. IMO. Clearly it breaks nothing since if they were to replace an open-coded variant, they would *also* affect any other code that currently uses CopyRect, and obviously in that case I'm sure it would be accepted immediately...

Dec. 30, 2018

Re: [PATCH 2/2] comctl32/listview: Add FIXMEs for LVM_MOVEITEMTOGROUP and LVM_MOVEGROUP messages

by Nikolay Sivov

On 12/30/18 6:19 AM, Isira Seneviratne wrote: > - /* case LVM_MOVEGROUP: */ > + case LVM_MOVEGROUP: > + FIXME("LVM_MOVEGROUP: unimplemented by Microsoft\n"); > + return FALSE; > > - /* case LVM_MOVEITEMTOGROUP: */ > + case LVM_MOVEITEMTOGROUP: > + FIXME("LVM_MOVEITEMTOGROUP: unimplemented by Microsoft\n"); > + return FALSE; What's a point of this?

Dec. 30, 2018

Re: [PATCH 1/2] comctl32/listview: Implement LVM_ISGROUPVIEWENABLED message handling

by Nikolay Sivov

On 12/30/18 6:18 AM, Isira Seneviratne wrote: > > - /* case LVM_ISGROUPVIEWENABLED: */ > + case LVM_ISGROUPVIEWENABLED: > + /* LVS_ALIGNTOP is required for group view */ > + return GetWindowLongPtrA(hwnd, GWL_STYLE) & LVS_ALIGNTOP; No, that's not how it works.

Dec. 30, 2018

issue with DPI awareness

by Kimball Thurston

All - I'm attempting to fix my own bug report ( https://bugs.winehq.org/show_bug.cgi?id=45917) but need someone who knows this code better to comment. If one sets the process-level DPI awareness to unaware (DPI_AWARENESS_UNAWARE) (which is what battle.net does), then the mouse selection (at least) ends up not working, resulting in a scaled / shifted mouse selection (when you click on something, an item up and to the left will be selected based on the distance from top left, and scale of dpi) - it's easiest to see if the window is exactly in the upper left corner of the screen. An easy way to see this is set your HCU\Control Panel\Desktop\LogPixels to 161 (the dpi of my 4k monitor), I also have my windows version at 10, then add SetProcessDpiAwarenessContext( DPI_AWARENESS_CONTEXT_UNAWARE ); as the first line of WinMain for something (I am using programs/regedit/main.c because I know it has child windows, although I don't believe that is the issue currently, but started w/ that idea). I presume the same would happen if the dpi awareness were in the app manifest. When I look at the coordinates of the mouse as they flow through process_mouse_message in dlls/user32/message.c, the WINPOS_WindowFromPoint calls find an hwnd, and then the modification point_phys_to_win_dpi seems plausible. However, the hittest value from WindowFromPoint does not work (returns HTNOWHERE when it shouldn't). And then the ScreenToClient that happens when the mouse is in the client area overly shifts the mouse position before it is put into the lParam of the event. A common theme of both the hittest and the ScreenToClient is the client_rect. Printing out the values, it appears like the client_rect is in monitor_dpi instead of window dpi, at least for the application top level window, or there's a disconnect because there's a boundary where the desktop window is in per_monitor, but the app is in unaware. At this point, if someone could take a look, and advise me whether the various window rects should be in monitor dpi or in window dpi, then I can try to track down what needs to change where to make that work, unless by reading the above it's obvious to someone who knows this code better than I? I don't have a windows machine to run tests on to validate, but am happy to try to help write the code if someone can suggest a good type of conformance test. thank you in advance, Kimball

Dec. 30, 2018