We shouldn't assume that the pitch of some arbitrary bitmap memory that
we're wrapping is going to be 16-byte aligned. Instead, just take the
pitch as a parameter.
Also update WindowServer to pass the pitch to the framebuffer bitmaps.
Now that the window used by a WSMenu is its child CObject, the menu also
receives CChildEvent's about the window, including CEvent::ChildAdded when
the window gets created. At this point, menu_window() still returns nullptr,
so stop unconditionally assuming that it doesn't. We should not care whether
or not we have a window for unrelated events anyway.
The main changes are twofold:
* Buffer flipping is now controlled by the m_screen_can_set_buffer flag
in WSCompositor. This flag, in turn, is impacted by m_can_set_buffer
flag, in WSScreen. m_can_set_buffer is set in the WSScreen constructor
by checking the return value of fb_set_buffer. If the framebuffer
supports this operation, it will succeed, and we record this fact. This
information is then used by WSCompositor to set its own
m_screen_can_set_buffer flag.
* WSScreen now only requests a resolution change of the framebuffer. The
driver itself is ultimately responsible for what resolution or mode is
actually set, so WSScreen has to read the response from that request,
and has no choice but to accept the answer. This allows the driver to
choose a "close enough" value to what was requested, or simply ignore
it.
The result of this is that there is no special configuration necessary
for WindowServer to work with reduced-capability framebuffer devices.
We can't rely on all hardware to give us a way to flip between the back
and front buffer.
This mode should actually perform slightly better but may show some tearing
as we don't have a way to know when we're in vertical retrace.
This fixes an issue where we'd send a "cursor has left the window"
message incorrectly to the client after a button was clicked and the
user moved the cursor a little without releasing the button.
The issue was that we didn't update the 'hovered_window' out param
in mouse event processing in the case where we had an active input
window set.
A lot of things happen in response to window destruction, and some of
them may call into the window's WSClientConnection and ask it to look
through its window list.
If we're right in the middle of tearing down the window list, it's not
a great idea to start iterating over it.
Fixes#386.
Now that we can set icons directly "by bitmap", there's no need for passing
around the icon paths anymore, so get rid of all the IPC and API related
to that. :^)
Now that we support more than 2 clients per shared buffer, we can use them
for window icons. I didn't do that previously since it would have made the
Taskbar process unable to access the icons.
This opens up some nice possibilities for programmatically generated icons.
Use CLocalServer to listen for connections in WindowServer and AudioServer.
This allows us to accept incoming CLocalSocket objects from the CLocalServer
and construct client connections based on those.
Removed COpenedSocket since it's replaced by CLocalSocket.
This macro goes at the top of every CObject-derived class like so:
class SomeClass : public CObject {
C_OBJECT(SomeClass)
public:
...
At the moment, all it does is create an override for the class_name() getter
but in the future this will be used to automatically insert member functions
into these classes.
Instead of LibGUI and WindowServer building their own copies of the drawing
and graphics code, let's it in a separate LibDraw library.
This avoids building the code twice, and will encourage better separation
of concerns. :^)
This allows us to seal a buffer *before* anyone else has access to it
(well, ok, the creating process still does, but you can't win them all).
It also means that a SharedBuffer can be shared with multiple clients:
all you need is to have access to it to share it on again.
Sticking these in a namespace allows us to use a more generic
("Connection") term without clashing, which is way easier to understand
than to try to come up with unique names for both.
The only reason for the inheritance was to add FDs to the select set.
Since CNotifier is available (and now also quite useful), we can make use of it
instead, and remove the inheritance.
* Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader)
* Add CLocalSocket, and CSocket::connect() variant for local address types.
We make some small use of this in WindowServer (as that's where we
modelled it from), but don't get too invasive as this PR is already
quite large, and the WS I/O is a bit carefully done
* Add an AClientConnection which will eventually be used to talk to
AudioServer (and make use of it in Piano, though right now it really
doesn't do anything except connect, using our new CLocalSocket...)
We were sometimes delivering the same mouse event twice to the active input
window. This happened because we had already delivered it via the automatic
cursor tracking mechanism.
This is effectively a mouse grab except that we don't require any client
coordination to request it (which is probably OK, and certainly a lot
simpler to implement).
This prevents e.g. dragging the mouse cursor out of paint and over the
terminal from selecting text unexpectedly.
Update ProcessManager, top and WSCPUMonitor to handle the new format.
Since the kernel is not allowed to use floating-point math, we now compile
the JSON classes in AK without JsonValue::Type::Double support.
To accomodate large unsigned ints, I added a JsonValue::Type::UnsignedInt.
