On Sat Dec 7 21:33:25 2024 +0000, Rémi Bernon wrote:
> I don't know for sure but there are probably some ways to make it work.
> It works already more or less well with embedded systray windows, so
> maybe doing something similar could be enough.
> Alternatively mouse input is mapped in `map_event_coords` and we
> preferred event root/x_root/y_root values when available because it
> avoided some inconsistencies when moving windows, but window positioning
> has been refactored lately, and maybe this isn't necessary anymore.
> Using window-relative mouse input could solve your case too (or we could
> also perhaps consider a winecfg option to prefer it over absolute positions).
Hi Rémi. With the change below (bug51357.patch) from https://bugs.winehq.org/show_bug.cgi?id=51357 the wrong mouse offset is fixed in the VST plugin's main window titled 'Spire'. But, e.g. clicking the 'menu' button shows the menu in the wrong place. See screenshot. The menu should appear below the 'menu' button (top row) in the window titled 'Spire'. So the change above does not fix the issue but hopefully it gives you an idea what the problem might be. If you need more information please let me know. Thanks!
[bug51357.patch](/uploads/dea8a1e711846f7e7642c16eacd284b4/bug51357.patch)

--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_92034
if you can start cmd.exe and notepad.exe from your installation, that should be sufficient to run the tests
are you running the tests with winetest or make test? the later can sometimes have issues with some symlinks from the build directory. using the former is safer
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7131#note_92028
OK, well, these tests appear to be practically a complete failure on my system. I'm receiving what appears to be an endless stream of lines like "Can't recognize 'temp.bat "Z:\\home\joe..." as an external command"..., etc. Admittedly, my wine build system is minimal; I do not have nearly all of the dependencies installed, but it was enough to build a basic wine installation including my changes to DIR. What I can probably do is make the changes to DIR as I think they should be, and either submit those changes or leave them here for someone else if they want to devote the time and effort into getting the tests to run.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7131#note_92010
The aim of this MR is to mark some debug formats loaded by dbghelp as
deprecated.
The idea is to remove them from dbghelp:
- after Wine 11 is released (for the ones still working)
- during PDB rewrite landing (after Wine 10 is released) if this
can help the process
The considered debug formats are:
1) COFF inside PE images
2) CodeView inside PE images
3) OMAP inside PE images
4) split debug info in .DBG files
5) PDB (in JG format). This is an early format, which has been superseded
by the DS format. clang only supports/understands the later DS format.
I retested on a small 'Hello World' application, using a MSVC compiler
from 1998 (version 12.0).
This compiler allows to emit COFF in PE images, split .DBG and PDB/JG debug
formats (it doesn't even seem to be able to emit Codeview inside PE images,
nor OMAP).
And from MSVC 14.0 onwards, none of these formats are available (only PDB DS).
Test results with MSVC 12.0:
- COFF inside PE image: doesn't work
- split .DBG: doesn't work
- PDB JG: does work (even if exceptions are caught)
work = can set BP on main, can backtrace (with line number) when that BP is hit
(using winedbg + builtin dbghelp)
--
v2: dbghelp: Emit deprecation FIXME for embedded, .dbg and PDB JG formats.
winedump: Use correct computation for first section out of a .DBG file.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7148
The aim of this MR is to mark some debug formats loaded by dbghelp as
deprecated.
The idea is to remove them from dbghelp:
- after Wine 11 is released (for the ones still working)
- during PDB rewrite landing (after Wine 10 is released) if this
can help the process
The considered debug formats are:
1) COFF inside PE images
2) CodeView inside PE images
3) OMAP inside PE images
4) split debug info in .DBG files
5) PDB (in JG format). This is an early format, which has been superseded
by the DS format. clang only supports/understands the later DS format.
I retested on a small 'Hello World' application, using a MSVC compiler
from 1998 (version 12.0).
This compiler allows to emit COFF in PE images, split .DBG and PDB/JG debug
formats (it doesn't even seem to be able to emit Codeview inside PE images,
nor OMAP).
And from MSVC 14.0 onwards, none of these formats are available (only PDB DS).
Test results with MSVC 12.0:
- COFF inside PE image: doesn't work
- split .DBG: doesn't work
- PDB JG: does work (even if exceptions are caught)
work = can set BP on main, can backtrace (with line number) when that BP is hit
(using winedbg + builtin dbghelp)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7148
About the multicriteria sort, there is clearly a hierarchy involved, and some options are mutually-exclusive (e.g DIR /O:SD on Windows 10 sorts by size, not time). Looking at the available options, it appears to me that G is the only one that can be combined, and with only one additional option. In the code, we probably need separate handling for N,E,S,D each by themselves, and separate handling for these combined with G.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7131#note_92002
"DIR /o" (no order specifier after /o) hasn't functioned the same as it does on Windows. This change makes the functionality of /o by itself equivalent to behavior on Windows.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7131
This is more code refactoring than micro-optimization. Modern compilers may skip optimizations in some places, so we strictly make it clear to them that we need common variable to determine const result strlen() function.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7143
On Tue Jan 14 07:51:31 2025 +0000, Jacek Caban wrote:
> Sorry for the delay, I'm not sure what to think about it. If it's
> dropped in modern Windows, it's not clear if we want it. I guess it
> wouldn't hurt...
> We usually add SVGs so that maintainer mode can generate binary blobs.
> It seems that Tango theme repo contains SVGs, could we use them?
Hi Jacek, thanks for the review. When I wrote this patch, I considered combining the Tango SVGs into a single SVG file that would be converted to a PNG when building in Wine maintainer mode, but it turned out to be more trouble than it was worth. It's trivial to combine PNG files with ImageMagick, whereas combining SVG files requires a lot of manual effort. Moreover, no one cares about modifying these icons or has made an argument for why different icons would be better than the Tango defaults. And if in the future someone decides to import the SVGs into Wine, the resulting PNG will still have to be regenerated and replaced in the Git repository; we have to have a PNG in Git regardless of how it is created.
It seems to me that we either need to merge a patch like the one I am proposing, or we need to close [Bug 40236](https://bugs.winehq.org/show_bug.cgi?id=40236) as WONTFIX and remove the [patches in Wine Staging](https://github.com/wine-staging/wine-staging/tree/master/patches/s…. The most important thing is just to make a decision.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4174#note_91975
Since we're checking the child window clipping rules it is possible
that a toplevel window also has an onscreen client window, for instance
if the window wasn't created with WS_CLIPCHILDREN. The last window to
present between the parent and its children should be visible.
GDI blits always happen over the toplevel window, and we need to use
IncludeInferiors to make sure it goes through any onscreen client window
that is otherwise hiding the toplevel pixels.
It should be safe to use that flag wrt other child windows, as we also
set the clipping region to exclude the area that should be obscured by
any sibling.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57661
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7141