August 2024 - Wine-GitLab - list.winehq.org

Re: [PATCH v12 0/6] MR6166: separate env for windows applications (WINENV) from env for wine processes (NIXENV)
by Alois Schloegl (＠schloegl) Aug. 5, 2024

Aug. 5, 2024

On Mon Aug 5 15:13:24 2024 +0000, Zhiyi Zhang wrote: > Hi, you need to rebase your patches on top of wine master. Thanks for looking into this. After some difficulties I finally managed to do so. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6166#note_77807

1 0

[PATCH v3 0/2] MR6186: comctl32/progress: Add states for progress bar.
by Jacob Czekalla (＠JacobCzekalla) Aug. 5, 2024

Aug. 5, 2024

Comctl32 V6 adds three different states into the progress bar: Normal, Paused, and Error. These three states change the color of the bar based on the theme. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56352 -- v3: comctl32/progress: Add states for progress bar. comctl32/tests: Add tests for progress bar states. https://gitlab.winehq.org/wine/wine/-/merge_requests/6186

4 10

Re: [PATCH v2 0/5] MR6148: include/codecapi.h: Add encoder defines. - approved
by Rémi Bernon Aug. 5, 2024

Aug. 5, 2024

This merge request was approved by Rémi Bernon. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6148

1 0

[PATCH 0/1] MR6132: win32u: Implement EVENT_SYSTEM_CAPTURESTART/END.
by Esme Povirk (＠madewokherd) Aug. 5, 2024

Aug. 5, 2024

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6132

4 3

Re: [PATCH v3 0/4] MR6074: Draft: Add support for HID multi toplevel-collections
by Rémi Bernon Aug. 5, 2024

Aug. 5, 2024

Thanks, this looks good. I have opened a separate MR (https://gitlab.winehq.org/wine/wine/-/merge_requests/6206) with various minor changes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6074#note_77777

1 0

Re: [PATCH v3 0/4] MR6074: Draft: Add support for HID multi toplevel-collections
by Rémi Bernon Aug. 5, 2024

Aug. 5, 2024

Rémi Bernon (@rbernon) commented about dlls/winebus.sys/main.c: > RtlEnterCriticalSection(&ext->cs); > list_add_tail(&ext->reports, &report->entry); > > - if (!ext->collection_desc.ReportIDs[0].ReportID) last_report = ext->last_reports[0]; > + for ( i = 0; i < ext->collection_desc.CollectionDescLength; ++i ) > + { > + HIDP_COLLECTION_DESC *desc = &ext->collection_desc.CollectionDesc[i]; > + for ( j = 0; j < ext->collection_desc.ReportIDsLength; ++j ) > + { > + if (ext->collection_desc.ReportIDs[j].CollectionNumber != desc->CollectionNumber) continue; > + if (!ext->collection_desc.ReportIDs[j].ReportID) last_report = ext->last_reports[0]; > else last_report = ext->last_reports[report_buf[0]]; > memcpy(last_report->buffer, report_buf, report_len); > + break; > + } > + } I'm not sure to understand this. Is it to cover the case where some of the TLC use report IDs while other don't, and I don't think that can happen? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6074#note_77776

1 0

[PATCH v6 0/2] MR6146: comctl32/propsheet: Create pages with PSP_PREMATURE on initialization.
by Jacob Czekalla (＠JacobCzekalla) Aug. 5, 2024

Aug. 5, 2024

The UK Kalender program was crashing when a new event was created as stated in the bug report. The fix is to create all the property sheet pages from the beginning instead of when they are selected. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54861 -- v6: comctl32/propsheet: Create pages with PSP_PREMATURE on initialization. comctl32/tests: Add test for propsheet page creation when propsheet gets initialized. https://gitlab.winehq.org/wine/wine/-/merge_requests/6146

3 3

[PATCH v10 0/2] MR6145: comctl32: Implement PSN_QUERYINITIALFOCUS
by Jacob Czekalla (＠JacobCzekalla) Aug. 5, 2024

Aug. 5, 2024

Adding PSN_QUERYINITIALFOCUS helped fix some focus issues with the property sheet in bug 54862. Previously the listview in the tab control did not get focus from the start when it should have. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54862 -- v10: comctl32: Add handling for PSN_QUERYINITIALFOCUS in prop.c. comctl32/tests: Add test for PSN_QUERYINITIALFOCUS for the propsheet. https://gitlab.winehq.org/wine/wine/-/merge_requests/6145

3 5

[PATCH v10 0/1] MR6189: shell32: make SHGetStockIconInfo() attempt to set hIcon.
by Kieran Geary (＠oh-ok) Aug. 5, 2024

Aug. 5, 2024

Since LoadIconW returns NULL on an error anyway, we should try LoadIconW. This fixes a crash with the Affinity V2 installers. -- v10: shell32: make SHGetStockIconInfo() attempt to set hIcon. https://gitlab.winehq.org/wine/wine/-/merge_requests/6189

2 1

Re: [PATCH v3 0/1] MR5340: maintainers: Remove MF GStreamer section.
by Elizabeth Figura (＠zfigura) Aug. 5, 2024

Aug. 5, 2024

> Please merge this. Like I previously explained I'm not interested in fighting over code, forcing anyone into doing something they don't want, or in endless and pointless ideological discussions. > > I'm now pretty much convinced that GStreamer is not a good choice as a backend because of the impedance mismatch and the amount of dogma that apparently comes with it. I will probably start looking into other options. All else aside, there is no dogma about winegstreamer. As maintainer, I tried to use my experience working with the component to architect the best design that accommodates all of the necessary fixes and features. As reviewer, I seek to point out functional problems with any new patches. 5998 has some of these functional problems. Fundamentally the question is one of expediency and correctness, not ideology. 5988 makes use of existing code to fix the same bugs as 5998 proposes to rewrite the entire DLL to fix, and it avoids the problems that 5998 introduces. GStreamer is a poor fit in some ways, in particular its asynchronous nature and its use of callbacks from new Unix threads. For these reasons, I've never loved it. However, it is also a very good choice in some other ways: it is heavily developed, has extensive codec support, has a stable API, and the project leadership is very open to new APIs. The only other library I know of with extensive enough codec support is ffmpeg, which does *not* have a stable API. Between the two options, I believe that GStreamer is the better one, especially because it already exists and works well. Moreover, those problems with GStreamer have already been solved, and I've also talked to the project leadership about extending GStreamer to solve them on the other side and simplify our code anyway. Between (1) GStreamer and Wine as it exists now, (2) GStreamer with future extensions to simplify Wine code, and (3) writing the whole component from scratch in some other library, it is eminently much more expedient to choose the first option, perhaps with an eye to the second, than switching to some other library. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5340#note_77742

1 0