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

Re: [PATCH v2 0/6] MR5724: widl: Various fixes.
by Elizabeth Figura (＠zfigura) May 28, 2024

May 28, 2024

On Tue May 28 07:03:51 2024 +0000, Rémi Bernon wrote: > Can this really happen? If that's the case then sure. Yes. I don't imagine anyone does it but it's how midl behaves. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5724#note_71568

1 0

Re: [PATCH v8 0/11] MR5444: jscript: Do not allocate dispex_prop_t for indexed props.
by Gabriel Ivăncescu May 28, 2024

May 28, 2024

On Mon May 13 19:14:17 2024 +0000, Gabriel Ivăncescu wrote: > > They could potentially be just indices, the association between name > and ID may be easily done on MSHTML side (it's already doing that now). > I don't think I follow. The name is used for jscript prop lookup, not > mshtml. We absolutely need it for hash and standard name lookup. It's > not an internal thing. PROP_PROXY doesn't care what name it has, it only > stores the DISPID (index basically) to access it from mshtml. But > looking it up **does** require name, because the prop has a name, so we > do need dispex_prop_t, just like builtins. To be fair I'm talking about > **being accessed by name via jscript**, nothing to do with mshtml internals. > Think of window props, for example. I'm not talking about simple dynamic > props on the window, which can be stored in jscript as simple values > (and will be, later though, not in my branch yet, as I said I don't want > to overcomplicate it). Instead, think of the other "global_props" (from > mshtml's meaning of it) on the window, such as other scripts, elements, > etc. Those need PROP_PROXY to get accessed… > > I think I can live with it, but note that the requirement to create a > function object instance for all MSHTML builtin functions that are used > is not exactly optimal. It would be possible to optimize that in the > future, hopefully without full rewrite of the interface. Just like we do > for jscript builtin functions. > We can save that for later, but I believe it's as optimal as builtins > right now. That is, they get allocated on demand (when needed), but > otherwise we need them as functions, because even builtins had to be > converted from builtins into actual functions at some point. Only the > "value prop" builtins still remain as such (it's same with PROP_PROXY). > > Sure, although... it's by no means something for now, but I could > imagine getting rid of `PROP_BUILTIN` and use the same 'external' > properties for them instead, just like other external props (MSHTML and > indexed props in the current proposal). > How would that work? Builtins have a name, so we can't just use the same > as indexed props because such name needs to have a DISPID mapping to it > and be looked up by hash. We could use an extra layer of mapping for > builtins of course, but I think that's overkill and likely slower > (instead of just one hash lookup, now it's two lookups). > It also complicates it because, for instance, builtins can be deleted, > and then we have to actually implement every prop behavior on them > instead of relying on dispex_prop_t facilities. Right now if they get > deleted, the prop remains as PROP_DELETED and so can be easily replaced > by something else. But yeah, maybe it's worth it way later though, we'll > need measurements I guess. After rebasing more of my patches, I found a problem with the IID approach, when it comes to weird prototype chains. For example the HTMLCurrentStyle shares an "abstract" common prototype with HTMLStyle, even though some of those methods don't work on it. But some are exposed in multiple interfaces, for instance the `zoom` prop setter (not getter). The IID would have the IHTMLStyle3 interface (which is correct), but when looking the "zoom" prop up on HTMLCurrentStyle via DISPID, it would get the one from CSSStyleDeclaration, which has different behavior. Yes, it's weird as hell, and my explanation isn't that great either. Anyway, the IID isn't that useful, mshtml already queries the IID for the respective function. Instead I'm now using a mixed approach where I have a new method (but a normal method in the vtbl like PropInvoke rather than a function pointer callback) that uses a "func_ctx" which is basically the `func_info_t` (it's opaque to jscript, it doesn't care). This way there's zero ambiguity as to which function is actually used, and the prototype chain fiasco is cleanly solved. All tests pass now. Anyway, this is not very related to this MR, is there something I can do to get this moving? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5444#note_71566

1 0

[PATCH v2 0/1] MR3518: wininet: unify timeout values closer to hInternet
by Jacob Pfeiffer (＠Cthuflu) May 28, 2024

May 28, 2024

Also: Add new timeouts to NETCON calls impacted by change Timeout values are able to be set on all hInternet handles, so they should be able to set in a unified way. Submitting what I have so far for review. Known TODO: Tests, verify timeouts are set where NETCON is used, verify ULONG vs DWORD usage rules. -- v2: wininet: unify timeout values closer to hInternet https://gitlab.winehq.org/wine/wine/-/merge_requests/3518

2 1

[PATCH 0/1] MR3518: wininet: unify timeout values closer to hInternet
by Jacob Pfeiffer (＠Cthuflu) May 28, 2024

May 28, 2024

Also: Add new timeouts to NETCON calls impacted by change Timeout values are able to be set on all hInternet handles, so they should be able to set in a unified way. Submitting what I have so far for review. Known TODO: Tests, verify timeouts are set where NETCON is used, verify ULONG vs DWORD usage rules. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3518

3 5

[PATCH 0/1] MR5743: user32/tests: Add a test to show that SendMessage(LB_SETCOUNT) adds a scrollbar.
by Dmitry Timoshkov (＠dmitry) May 28, 2024

May 28, 2024

In addition to existing tests this shows that the call SendMessage(listbox, LB_SETCOUNT, 100, 0); adds a scrollbar to the listbox however it doesn't add a nonclient area to an update region because the call ValidateRect(listbox, NULL); validates a client area, and after that a window no longer has an update region. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5743

2 1

[PATCH 0/4] MR5639: comctl32/syslink: Don't delete font when destroying the control.
by Zhiyi Zhang (＠zhiyi) May 28, 2024

May 28, 2024

The font set by WM_SETFONT is not owned by syslink so it shouldn't be deleted when handling WM_DESTROY for the control. Fix Toad for Oracle text gets reset to the system font after installing Team Coding. The application creates a font and set it to a syslink. Then after the syslink destroys itself, the font becomes invalid so other controls using the font end up falling back to the system font. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5639

4 6

Re: [PATCH v2 0/1] MR5706: comctl32/rebar: Hide chevron if the full width of rebar is displayed
by Zhiyi Zhang (＠zhiyi) May 28, 2024

May 28, 2024

Please give two screenshots demonstrating the changes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5706#note_71557

1 0

Re: [PATCH v3 0/4] MR5738: win32u: More DPI awareness context fixes.
by Rémi Bernon May 28, 2024

May 28, 2024

On Tue May 28 10:12:25 2024 +0000, Rémi Bernon wrote: > changed this line in [version 3 of the diff](/wine/wine/-/merge_requests/5738/diffs?diff_id=115405&start_sha=837a51a59c0de7dd45a2c7da92545ca8d18da2e2#85770a8b187bd82db4dbb9a2b8a5f34616049d0f_4787_4787) Dropped that change for now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5738#note_71550

1 0

Re: [PATCH v2 0/4] MR5738: win32u: More DPI awareness context fixes.
by Rémi Bernon May 28, 2024

May 28, 2024

On Tue May 28 10:20:03 2024 +0000, Alexandre Julliard wrote: > I don't think we can do that until the drivers support window scaling. Hmm, right thanks. That was mostly meant to fix the tests, but I see now that it breaks things. Still not clear to me why or how. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5738#note_71547

1 0

Re: [PATCH v2 0/4] MR5738: win32u: More DPI awareness context fixes.
by Alexandre Julliard (＠julliard) May 28, 2024

May 28, 2024

Alexandre Julliard (@julliard) commented about dlls/win32u/sysparams.c: > > /* FIXME: what do the DpiScalingVer flags mean? */ > get_dword_entry( (union sysparam_all_entry *)&entry_DPISCALINGVER, 0, &dpi_scaling, 0 ); > - if (!dpi_scaling) NtUserSetProcessDpiAwarenessContext( NTUSER_DPI_PER_MONITOR_AWARE, 0 ); I don't think we can do that until the drivers support window scaling. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5738#note_71546

1 0