| Age | Commit message (Collapse) | Author |
|---|
|
This was an old event type in the early days of userspace WindowServer.
|
|
We were not sending the ID of the window that was listening for window
management (WM) events along with the WM messages. They only included
the "target" window's ID.
Since the taskbar's single window had the first window ID for its own
connection to the WindowServer, it meant that it would only receive
WM events for the first window ID in other processes as well.
This broke when I ported WindowServer to LibIPC.
Fix this by including the WM listener ID in all WM messages, and since
we're here anyway, get rid of a bunch of unnecessary indirection where
we were passing WM events through the WindowServer event loop before
sending them to the listener.
|
|
Thanks Tibor for pointing this out. :^)
|
|
|
|
This always felt out-of-place in LibC.
|
|
|
|
This is done here rather than pick_new_active_window() so that when
there are no other windows to focus but the previous window hasn't
been removed (just minimized), the menu bar remains on that client.
|
|
Also make sure we send out the WM event for window deactivations.
This fixes an issue where the taskbar button for a window would appear
depressed, even after the window was deactivated.
|
|
|
|
Instead of just boosting the main thread, let's boost all threads in
the currently active client process.
This avoids creating internal priority inversion problems in clients.
|
|
When the currently active (foreground) window is owned by a client,
we now apply a +10 priority boost to the client's main thread.
You normally want the window you're interacting with to be responsive,
so this little boost allows it to run a bit sooner and more often. :^)
|
|
Threads now have numeric priorities with a base priority in the 1-99
range.
Whenever a runnable thread is *not* scheduled, its effective priority
is incremented by 1. This is tracked in Thread::m_extra_priority.
The effective priority of a thread is m_priority + m_extra_priority.
When a runnable thread *is* scheduled, its m_extra_priority is reset to
zero and the effective priority returns to base.
This means that lower-priority threads will always eventually get
scheduled to run, once its effective priority becomes high enough to
exceed the base priority of threads "above" it.
The previous values for ThreadPriority (Low, Normal and High) are now
replaced as follows:
Low -> 10
Normal -> 30
High -> 50
In other words, it will take 20 ticks for a "Low" priority thread to
get to "Normal" effective priority, and another 20 to reach "High".
This is not perfect, and I've used some quite naive data structures,
but I think the mechanism will allow us to build various new and
interesting optimizations, and we can figure out better data structures
later on. :^)
|
|
|
|
|
|
|
|
Otherwise, menu applets with an alpha channel may leave behind ghost
pixels when updating.
Fixes #949.
|
|
Palette is now a value wrapper around a NonnullRefPtr<PaletteImpl>.
A new function, set_color(ColorRole, Color) implements a simple
copy-on-write mechanism so that we're sharing the PaletteImpl in the
common case, but allowing you to create custom palettes if you like,
by getting a GWidget's palette, modifying it, and then assigning the
modified palette to the widget via GWidget::set_palette().
Use this to make PaintBrush show its palette colors once again.
Fixes #943.
|
|
Build them if they don't exist, but don't care about them being
newer or older than the target.
I believe this is what was causing build loops where IPCCompiler was
being run a second time, rebuilding its .h file, then a library
would depend on that .h file and get re-archived, then an
application would need relinking, and something in that whole
process would trigger IPCCompiler running again touching its .h
file.
|
|
We have clock applet.
|
|
When filling in some missing part of a window (typically happens during
interactive window resize) we now use the ColorRole::Background from
the system theme palette instead of expecting the clients to send us
the same information when creating windows.
|
|
When adding/removing windows, or moving a window from the front to the
back, we have to recompute everyone's occlusion states.
|
|
We wouldn't be able to see what they paint anyway, and nobody should
be using paint events to drive program logic.
|
|
WindowServer now tracks whether windows are occluded (meaning that
they are completely covered by one or more opaque windows sitting above
them.) This state is communicated to the windows via WindowStateChanged
messages, which then allow GWindow to mark its backing store volatile.
This reduces the effective memory impact of windows that are not at all
visible to the user. Very cool. :^)
|
|
WindowServer will now send out a WindowStateChanged message to clients
when one of their windows is minimized.
This is then forwarded to the GWindow, which will try to mark its
underlying window backing store as volatile.
This allows the kernel to steal the memory used by minimized windows
in case it starts running low. Very cool! :^)
|
|
This allows the very aesthetic "Hotdog Stand" theme to have quite
reasonable looking menus.
|
|
Use a pthread_cond_t to have the ASMixer thread wait until a client has
connected and added a buffer queue to the "pending mixing" vector.
This solves the long-standing issue of the system "idling" at ~8% CPU.
|
|
Instead of directly manipulating LDFLAGS, set LIB_DEPS in each
subdirectory Makefile listing the libraries needed for
building/linking such as "LIB_DEPS = Core GUI Draw IPC Core".
This adds each library as an -L and -l argument in LDFLAGS, but
also adds the library.a file as a link dependency on the current
$(PROGRAM). This causes the given library to be (re)built before
linking the current $(PROGRAM), but will also re-link any binaries
depending on that library when it is modified, when running make
from the root directory.
Also turn generator tools like IPCCompiler into dependencies on the
files they generate, so they are built on-demand when a particular
directory needs them.
This all allows the root Makefile to just list directories and not
care about the order, as all of the dependency tracking will figure
it out.
|
|
GApplication now has a palette. This palette contains all the system
theme colors by default, and is inherited by a new top-level GWidget.
New child widgets inherit their parents palette.
It is possible to override the GApplication palette, and the palette
of any GWidget.
The Palette object contains a bunch of colors, each corresponding to
a ColorRole. Each role has a convenience getter as well.
Each GWidget now has a background_role() and foreground_role(), which
are then looked up in their current palette when painting. This means
that you no longer alter the background color of a widget by setting
it directly, rather you alter either its background role, or the
widget's palette.
|
|
|
|
These are now separate from the Window and WindowText colors.
|
|
|
|
Color themes are loaded from .ini files in /res/themes/
The theme can be switched from the "Themes" section in the system menu.
The basic mechanism is that WindowServer broadcasts a SharedBuffer with
all of the color values of the current theme. Clients receive this with
the response to their initial WindowServer::Greet handshake.
When the theme is changed, WindowServer tells everyone by sending out
an UpdateSystemTheme message with a new SharedBuffer to use.
This does feel somewhat bloated somehow, but I'm sure we can iterate on
it over time and improve things.
To get one of the theme colors, use the Color(SystemColor) constructor:
painter.fill_rect(rect, SystemColor::HoverHighlight);
Some things don't work 100% right without a reboot. Specifically, when
constructing a GWidget, it will set its own background and foreground
colors based on the current SystemColor::Window and SystemColor::Text.
The widget is then stuck with these values, and they don't update on
system theme change, only on app restart.
All in all though, this is pretty cool. Merry Christmas! :^)
|
|
We were pumping the sound device full of silence even after the last
audio client disconnected.
|
|
Allow everything to be built from the top level directory with just
'make', cleaned with 'make clean', and installed with 'make
install'. Also support these in any particular subdirectory.
Specifying 'make VERBOSE=1' will print each ld/g++/etc. command as
it runs.
Kernel and early host tools (IPCCompiler, etc.) are built as
object.host.o so that they don't conflict with other things built
with the cross-compiler.
|
|
When we're in a drag, we're no longer concerned with streaming mouse
events to the window that initiated the drag, so just clear the active
input window pointer.
This fixes an issue where you'd have to click once after drag and drop
in order to "release" the mouse from the active input window.
|
|
These fields are intended to carry the real meat of a drag operation,
and the "text" is just for what we show on screen (alongside the cursor
during the actual drag.)
The data field is just a String for now, but in the future we should
make it something more flexible.
|
|
This is no longer necessary, since the audio applet has been moved to
its own process.
|
|
This patch introduces the second MenuApplet: Audio. To make this work,
menu applet windows now also receive mouse events.
There's still some problem with mute/unmute via clicking not actually
working, but the call goes from the applet program over IPC to the
AudioServer, where something goes wrong with the state change message.
Need to look at that separately.
Anyways, it's pretty cool to have more applets running in their own
separate processes. :^)
|
|
Instead of implementing menu applets as their own thing, they are now
WSWindows of WSWindowType::MenuApplet.
This makes it much easier to work with them on the client side, since
you can just create a GWindow with the right type and you're in the
menubar doing applet stuff :^)
|
|
|
|
Using int was a mistake. This patch changes String, StringImpl,
StringView and StringBuilder to use size_t instead of int for lengths.
Obviously a lot of code needs to change as a result of this.
|
|
|
|
Windows that are being moved around by the user are now called "moving"
windows instead of "dragging" windows, to avoid confusion with the
drag and drop stuff.
|
|
|
|
This bitmap is displayed alongside the dragged text underneath the
mouse cursor while dragging.
This will be a perfect fit for dragging e.g files around. :^)
|
|
This patch enables basic drag&drop between applications.
You initiate a drag by creating a GDragOperation object and calling
exec() on it. This creates a nested event loop in the calling program
that only returns once the drag operation has ended.
On the receiving side, you get a call to GWidget::drop_event() with
a GDropEvent containing information about the dropped data.
The only data passed right now is a piece of text that's also used
to visually indicate that a drag is happening (by showing the text in
a little box that follows the mouse cursor around.)
There are things to fix here, but we're off to a nice start. :^)
|
|
|
|
|
|
Instead of passing the PIDs back and forth in a handshake "Greet"
message, just use getsockopt(SO_PEERCRED) on both sides to get the same
information from the kernel.
This is a nice little simplification of the IPC protocol, although it
does not get rid of the handshake since we still have to pass the
"client ID" from the server to each client so they know how to refer
to themselves. This might not be necessary and we might be able to get
rid of this later on.
|
|
Currently menu applets are laid out relative to the "audio rect" which
is the rect of the little audio muted state icon thingy.
There was an issue where applets would be placed at a negative X coord
if they were added to the WindowServer before the first time drawing
the menubar.
|
