| Age | Commit message (Collapse) | Author |
|---|
|
It didn't feel right to have a "DHCPClient" in a "Servers" directory.
Rename this to Services to better reflect the type of programs we'll
be putting in there.
|
|
When a window is maximized by clicking the 'maximize' button in the window frame,
the WindowFrame *is* invalidated and repainted properly. However, the internal
state of the WindowServer::Button does not get updated until the next mouse
movement. This means that the 'maximize' button is erroneously highlighted until
the mouse moves again. This is very visible.
Ideally, a patch should compute the actual new m_hovered. However, this requires
knowledge of the new rect, or calling something on the Button after the new rect
has been determined. Until someone can figure out a good way around this,
setting m_hovered to false is a solution that 'usually' works.
Note that this does *not* work when after maximizing/restoring, the maximize
button falls exactly under the mouse again. The button functions properly, but
is erroneously not highlighted.
At least a *missing* highlight is less noticable than a highlight too many.
|
|
ComboBox creates a regular (non-modal) window; I believe this is fine.
A Dialog (modal window) can contain a ComboBox; I believe this is fine.
A non-modal child window of a modal window (e.g. a ComboBox pop-out within
a Dialog) wasn't clickable, and was blocked in the WindowManager.
I want to change this behavior.
This edge case occurs when trying to select a month in the "Calendar"
Application.
|
|
|
|
Fixes #2073.
|
|
Thanks for movAX13H for pointing this out!
|
|
We'll call the "Back" and "Forward" since that's what they are normally
mapped to in some other systems.
|
|
Frameless windows don't need to show up in the taskbar or the switcher.
|
|
If a window has child windows when it's destroyed, WindowServer will
now automatically tear down all of its children as well.
This is communicated to the client program through a vector of window
ID's included with the response to WindowServer::DestroyWindow.
This does feel a little bit awkward, but managing it on the client side
also seems a bit awkward.
|
|
This allows you to create windows with no title bar or window frame.
|
|
Nobody was using this flag, so let's stop maintaining it. It's easy to
add it back if we ever want the behavior.
|
|
Whenever a parent window is moved to front, we now follow up by
immediately moving its children to front as well.
|
|
When moving a window, we will now move any child windows by the same
position delta as the parent. This makes ComboBox popup list windows
follow the window they were opened by, which looks nice. :^)
|
|
If a window has another window in its Core::Object ancestor chain,
we now communicate that relationship to WindowServer so that it can
act with awareness of parent/child windows.
|
|
|
|
|
|
|
|
|
|
When clicking the window icon, we now pop up the window menu at the
bottom left of the icon, no matter where you clicked it.
Right-clicking the title bar still pops up at the event position.
|
|
|
|
|
|
This will make the compositor draw our colour wallpaper, instead
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The original implementation only sent out notifications when there was
something being drawn on screen. If nothing was going on, we'd get too
lazy and just not notify display links.
This obviously break requestAnimationFrame(), so now we just drive the
DisplayLinks at 60 fps no matter what. :^)
|
|
|
|
|
|
This prevents accesing the parent window menubar when a modal is
currently open, which was not a desired behavior.
|
|
PR #1495 fixes #1464 but only accounts for window menus. In File
Manager, for example, attempting to pop up the context menu on the file
name text box of the properties modal window, will result in the same
behavior.
Removing the code altogether solves the problem, altough I'm
not sure if it could have any bad implications.
I was thinking it might allow interaction with a parent window menu if
it remains open just before the popup window is shown, but I have not
seen a way to replicate this behavior.
|
|
This was not done previously and resulted in modal windows not being
able to accept input unless they were clicked one time if their parent
windows were the active input window.
|
|
|
|
Fixes #1862.
|
|
|
|
Normally we focus any window that's added to the window stack. However,
for WindowType::Desktop this gets annoying since if the desktop manager
comes up after other GUI processes have already started, it steals the
focus from them.
Solve this by only auto-focusing desktop windows if they are the very
first window added.
|
|
|
|
This allows us to focus the desktop and interact with it normally. :^)
|
|
|
|
This new window type can be used to implement a desktop file manager
for example. :^)
|
|
Previously the WindowServer would assert `topmost_menu->menu_window()`
and crash.
Fixes #1716
|
|
|
|
This is just a convenience function for creating single-shot timers.
|
|
Previously the WindowServer would assert `!is_empty()` and crash.
Fixes #1689
|
|
Disconnecting from WindowServer without explicit calls to DestroyWindow
would leave nulled-out WeakPtr's in the AppletManager applet list.
This led to a null dereference when adding a new applet, since we were
assuming the list contained no nulled-out applets.
This patch fixes the issue by always unregistering applet windows from
the AppletManager in ~ClientConnection(). We also do an extra pass of
pruning any nulled-out WeakPtrs from the applet list when adding to it.
Fixes #1551.
|
|
This patch adds a specialized window type for notifications. They now
have a title bar on the right-hand side, with a close button.
This removes the need for the "Done" button in notifications, giving us
a bit more horizontal space overall.
Design based on a mock-up from @xTibor :^)
|
|
|
