This fixes regression CORE-16289 where we could not longer
move the taskbar at a different than default location,
as WindowSnap would interfere.
Many Thanks to the patches author Doug Lyons.
Eventually the heuristic that we use here to identify the
taskbar via used window-styles could be improved later.
Theoretically possible that it bails out on some other windows.
The regression was introduced by 0.4.12-dev-373-g
7e396787ed
patch is a backport from master 0.4.13-dev-962-g
4193b8d8ac
as the release data is close and we have to manage the risk.
This reverts last commit and all menu related code back to the state of
0.4.12-dev-369-g
007ec0310c
Although Mark Jansen seems to be on a very promising path in master,
we still revert one last time for this release to the more well known
state we had during 0.4.12dev'ing.
This will fix regressions CORE-16298, CORE-16297
and will keep CORE-15863 in fixed state.
Systray and nested desktop popups do work very well like this.
We therefore intentionally and willingly have to accept the broken
partial-offscreen-menus of CORE-15733.
Those are not as important as the other tickets.
Meanwhile we keep on improving master based on the more recent states.
to fix regression CORE-15863
This is the work that Mark jansen committed into master
0.4.13-dev-791-g
a59df3858c
and
0.4.13-dev-792-g
7c45a646e9
and
0.4.13-dev-793-g
b5c6af459c
squashed into one single commit for 0.4.12RC.
It's not perfect yet anymore for positioning the
popup for systray icons if they contain many entries.
And also not perfect when pressing the context menu key
on desktop after a .lnk has been started,
but overall gives a better user-experience for nested popups
on the desktop, which is much more important.
We can build up on top of it later in master.
to the workaround in last commit 0.4.12-RC-19-g
700779e643
Many thanks to reviewer jimtabor for this very prompt review!
I tested, the new state still succeeds in CORE-15477, CORE-14979, CORE-15599, CORE-15600, CORE-15654
Fixes 'multiple apps leaving the taskbar visible erroneously when switching into fullscreen.'
Please note that the problem with taskbar staying visible is only fixed for some, but not all apps
(see CORE-11242 for some still failing examples, e.g: Bound Around).
We now have the same state in 0.4.12RCs, that we just have committed to master in 0.4.13-dev-247-g
0f29b3faa7
Fixes 'multiple apps leaving the taskbar visible erroneously when switching into fullscreen.'
Please note that the problem with taskbar staying visible is only fixed for some, but not all apps (see CORE-11242 for examples).
This partially reverts commit 09ab5ea7ed (SVN r75407)
I applied this interim solution into 0.4.12RCs for the very first time and rls-tests still
have to prove it being free of obvious side-effects.
Theoretically we could still switch to a better solution at any time.
The workaround never was applied to master to date.
https://reactos.org/testman/compare.php?ids=67536,67539
Resizing a themed window does not longer show a flashing rectangle in the title-bar after the fix.
Still this seems to be work-in-progress even after this first commit, but makes me happy for 0.4.12RCs
for now.
See CORE-7166 & CORE-15934.
cherry picked from commit 0.4.13-dev-8-g
cfdf36e442
By applying for the first time clientFix.patch from CORE-15911 contributed by JIRA-user 'I_Kill_Bugs'.
The patch acts as a better replacement for a workaround of DougLyons from CORE-15429
that aimed to hide the issue for our file-browser only.
The new approach gave good results for the testbots
https://reactos.org/testman/compare.php?ids=66723,66729
but wasn't tested much yet. In case it causes any problems during testing-cycle,
I might eventually switch back to our old workaround instead from the last releases.
- Bugcheck VIDEO_DRIVER_INIT_FAILURE in case initializing video fails.
- Bugcheck WIN32K_INIT_OR_RIT_FAILURE (Windows-compatible) in case
the USER subsystem version does not match.
Implemented the following actions: stick the window on the left/right or maximize it,
with the following shortcuts:
- Win key + Arrows;
- drag to left/right screen border;
- double-click on top/bottom.
CORE-12845
Previously, we would just stick the menu on the edge of the screen.
We should actually try to flip the menu around the point of origin,
and only when that fails move it to the edge of the screen.
CORE-15001
CORE-9037
- Add a check in co_UserCreateWindowEx() for parentless windows,
that checks the default layout direction; if it's LAYOUT_RTL
add the WS_EX_LAYOUTRTL flag to the extended window styles.
- Make the internal routine accepting also LAYOUT_LTR as a value for SetProcessDefaultLayout().
Limit receiving value to LAYOUT_ORIENTATIONMASK (and not just LAYOUT_RTL)
or LAYOUT_LTR, as per written in:
https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-setprocessdefaultlayout
Now all the applications that call SetProcessDefaultLayout() to mirror the layout get mirrored.
This is based on Wine.
This change is similar to what is done in UserChangeDisplaySettings()
after changing screen video mode.
This allows e.g. having windows to be correctly maximized during
2nd-stage GUI setup. To compare and reproduce during 2nd-stage GUI
setup, open cmd.exe (Shift-F10) and from there a GUI app, e.g.
regedit.exe, and maximize it. Observe the limits used by the window.
This helps when e.g. changing the resolution on the Dell Latitude D531,
which reports that it supports large resolutions (e.g. 1920x1440x32 and
others larger than 1024x768x32) but fails to apply these.
This usually happens because PDEVOBJ_pSurface(), and more precisely
ppdev->pldev->pfn.EnableSurface(), fails for these resolutions.
- PDEVOBJ_bSwitchMode(): Set the new video mode, or restore the original
one in case of failure + release the allocated ppdevTmp if previous
calls fail. Also unlock in reverse order of locking order.
- UserChangeDisplaySettings(): In case PDEVOBJ_pSurface() fails (but has
reverted the original video mode), we still need to refresh the
display since the display may have been messed up.
- NtUserOpenInputDesktop: Don't crash if there is no input desktop yet
- NtUserOpenInputDesktop: Fail if the process doesn't belong to the interactive window station
- NtUserCreateWindowStation: Clear error on success
- DesktopWindowProc: Use UserOpenInputDesktop to get a handle to the input desktop
* Add an NDK header to define INIT_FUNCTION/INIT_SECTION globally
* Use _declspec(allocate(x)) and _declspec(code_seg(x)) on MSVC versions that support it
* Use INIT_FUNCTION on functions only and INIT_SECTION on data only (required by MSVC)
* Place INIT_FUNCTION before the return type (required by MSVC)
* Make sure declarations and implementations share the same modifiers (required by MSVC)
* Add a global linker option to suppress warnings about defined but unused INIT section
* Merge INIT section into .text in freeldr
- Add UserCreateSystemThread function that will signal csrss to create a new system thread.
- NtUserCreateWindowStation: Create the raw input thread and the desktop thread when the IO window station gets created.
- IntMakeHungWindowGhosted: Create the ghost system thread that will own all ghost windows.
- Let the raw input thread manage the window station of csrss.
[USERSRV] Remove system threads creating hack
- Implement SrvCreateSystemThreads
- Don't create the system threads in UserServerDllInitialization.
- NtUserSetInformationThread: Stub UserThreadUseActiveDesktop and UserThreadRestoreDesktop
- Properly mark the first thread that enters win32k belonging to csrss. At this point we assume that since gpepCSRSS isn't initialized yet, it probably is the first thread.
[WINSRV] Use NtUserSetInformationThread to set the current desktop when needed
-When csrss needs to use user32 or enter win32k, it first needs to assign the current thread to a desktop.
