A window repaint may change the alpha value, resulting in a different
hit test outcome. In those cases, re-evaluate the cursor hit testing
after a window was painted, and update the cursor if needed.
Tool windows are secondary windows with a smaller title bar. The sit on
the layer above normal windows, and cannot be minimized.
These are intended for complex yet non-modal interactions with the
content of a primary window, such as find/replace windows, property
windows, etc.
We need to first deliver the mouse event and possibly the double click
event and record these facts. Then, we need to iterate all global
tracking listeners and deliver the mouse event (but not the double
click event) to any such listener, unless they already had these
events delivered.
Fixes#4703
Merely moving a window shouldn't require re-rendering the window
frame anymore now that we cache the rendered frame in bitmaps. This
reduces CPU usage significantly when moving windows.
We weren't properly handling switching between having a shadow and
not having a shadow when switching themes. This allows an empty string
in the theme configuration for a shadow path, meaning no shadow should
be rendered.
Button now can handle middle and right clicks.
Added 2 new handlers in button class: on_right_click for Right mouse
button and on_middle_click for middle mouse button.
Added functionality to vertically maximize window with middle mouse
click on the maximize window button.
Also added a way to vertically maximize window by resizing window
height-wise lower than the maximum window height.
Since theme changes may change geometrics, which are also affected by
window shadows, we need to recompute occlusions as well as re-render
window frames.
This implements simple window shadows around most windows, including
tooltips. Because this method uses a bitmap for the shadow bits,
it is limited to rectangular window frames. For non-rectangular
window frames we'll need to implement a more sophisticated algorithm.
This only renders the window frame once until the size of the window
changes, or some other event requires re-rendering. It is rendered
to a temporary bitmap, and then the top and bottom part is stored
in one bitmap as well as the left and right part. This also adds
an opacity setting, allowing it to be rendered with a different
opacity.
This makes it easier to enhance window themes and allows using
arbitrary bitmaps with e.g. alpha channels for e.g. shadows.
This commit:
- merges the two(!) places that defined independently the minimum size of a window.
- splits Window::normalize_rect(), which was originally just a function to apply
the minimum size requirement, and has taken on the additional job of nudging
windows back onto the desktop.
This inadvertantly fixes a crash that happens when a malicious program creates a
window of size (0, 0). Now, a window at [0,0 50x50] is created instead.
That's what that piece of logic is probably supposed to be doing.
Let's help it acheive that purpose! Apparently the top of the desktop
(i.e. the menubar) was forgotten, so consider it part of the deadzone.
This is based on a comment by @tomuta on #4644, and should prevent all future
instances of bugs like #4644.
Disadvantage: The current implementation may generate a lot of WM_WindowRectChanged
events for a listener while bouncing occurs. Feel free to improve this.
- Unmaximization/untiling had nearly but not quite code duplication;
this patch replaces the actual "regrabbing" logic with Rect::set_size_around.
- When undoing maximization/untiling, it used to be possible to to grab a window
"outside" of its frame, and thus drag it off the screen. This is no longer
possible. Fixes#4644.
- As a side effect, when untiling from the bottom/left/right, the regrab is now
a much smoother experience.
- Setting the resize aspect ratio while being tiled now untiles and umaximizes
the window, as these things are incompatible. Fixes an undocumented bug
(steps to reproduce: maximize, then set aspect ratio).
- When unmaximizing, spurious WindowLeft events were sent, because that path
didn't set hovered_window. Fixes an undocumented bug.
Since these things are interwoven, this is all a single commit.
Bitmap::load_from_file("foo.png", 2) will now look for "foo-2x.png" and
try load that as a bitmap with scale factor 2 if it exists. If it
doesn't, it falls back to the 1x bitmap as normal.
Only places that know that they'll draw the bitmap to a 2x painter
should pass "2" for the second argument.
Use this new API in WindowServer for loading window buttons and
cursors.
As a testing aid, ctrl-shift-super-i can force HighDPI icons off in
HighDPI mode. Toggling between low-res and high-res icons makes it easy
to see if the high-res version of an icon looks right: It should look
like the low-res version, just less jaggy.
We'll likely have to grow a better API for loading scaled resources, but
for now this suffices.
Things to check:
- `chres 640 480` followed by `chres 640 480 2` followed by
`chres 640 480`
- window buttons in window context menu (in task bar and on title bar)
still have low-res icons
- ctrl-shift-super-i in high-res mode toggles sharpness of window
buttons and of arrow cursorf
- arrow cursor hotspot is still where you'd expect
The priority boosting mechanism has been broken for a very long time.
Let's remove it from the codebase and we can bring it back the day
someone feels like implementing it in a working way. :^)
Window icons in Taskbar were previously received in WM events with
shbuf ID's. Now that Gfx::ShareableBitmap is backed by anonymous files,
we can easily switch to using those.
Now, `chres 640 480 2` can set the UI to HighDPI 640x480 at runtime. A
real GUI for changing the display factor will come later.
(`chres 640 480 2` followed by `chres 1280 960` is very fast since
we don't have to re-allocate the framebuffer since both modes use
the exact same number of physical pixels.)
