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. :^)
PR #1495fixes#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.
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.
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 :^)
This patch adds GUI::DisplayLink, a mechanism for registering callbacks
that will fire at the display refresh rate.
Note that we don't actually know the screen refresh rate, but this is
instead completely driven by WindowServer's compositing timer. For all
current intents and purposes it does the job well enough. :^)
Previously windows would either extend past the screen or stay at their
previous smaller size in the corner, now they are resized to fit the new
resolution.
It makes a little more sense for the menubar to control what the font of
the menu title is, as opposed to the menu manager. Menumanager now
simply uses the font that the menu wants it to use.
We also clean up some old references to the old G prefixed GUI classes
This also fixes a potential bug with using: C_OBJECT_ABSTRACT(GAbstractButton)
instead of C_OBJECT_ABSTRACT(AbstractButton)
Now it actually defaults to "a < b" comparison, instead of forcing you
to provide a trivial less-than comparator. Also you can pass in any
collection type that has .begin() and .end() and we'll sort it for you.
While the menu system is swallowing mouse events, just clear any resize
candidate we had set. This ensures that we don't end up with a resize
cursor when slipping into a menu-controlled part of the screen.
Fixes#1306.
This feels a lot more consistent and Unixy:
create_shared_buffer() => shbuf_create()
share_buffer_with() => shbuf_allow_pid()
share_buffer_globally() => shbuf_allow_all()
get_shared_buffer() => shbuf_get()
release_shared_buffer() => shbuf_release()
seal_shared_buffer() => shbuf_seal()
get_shared_buffer_size() => shbuf_get_size()
Also, "shared_buffer_id" is shortened to "shbuf_id" all around.
Now we return a boolean value from set_resolution() in the Compositor
and Screen class. Also, the WindowServer IPC now returns a richer result
after changing the resolution, which can be used in clients later.
Let's temporarily disable the boosting calls until we have a solution
for boosting in the new multi-user world. The error messages keep
confusing people into thinking they're doing something wrong.
Previously it was only possible to change these window attributes when
creating a new window. This patch adds an IPC message that allows you
to change them at runtime.
The open menu stack is an internal data structure that outside classes
shouldn't really need to know about. Add MenuManager::has_open_menu()
so that the WindowManager can still know whether a menu is open or not.
We were failing to check if the current menu being set was already open.
This could result in multiple occurrences of the menu in the open menu stack.
When we close all menus descending from a menu we only delete the first
occurrence of a given menu from the menu stack (a fair assumption to make as
a menu should only be open once).
Because of this a menu (or multiple instances of it) could remain in the open
menu stack when it should actually be closed, leading to goofy behaviour.
Fixes#1238
We were not repainting windows that were occluded at the time of the
theme changing. This patch adds a way to bypass occlusion testing when
invalidating window rects.
Fixes#1249.
