Each client connection now sets up an ASBufferQueue, which is basically a
queue of ABuffers. This allows us to immediately start streaming the next
pending buffer whenever our current buffer runs out of samples.
This makes the majority of the skippiness go away for me. :^)
Also get rid of the old PlayBuffer API, since we don't need it anymore.
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.
Thanks to Dan for pointing this out on IRC:
<danboid> I see TextEditor still numbers its lines from 0. You're too much of a programmer sometimes kling! :)
< kling> that might be the most extreme form of "programmer design" I've seen in serenity
We were limiting ourselves to only play WAV files smaller than 42 MB
for no particular reason. This patch increases the limit to 1 GB.
Perhaps there should not be any limit at all, but 1GB seems like a
reasonable sanity check at the moment. :^)
This allows us to carry the same buffer all the way from the WAV loader
to the AudioServer mixer.
This alleviates some of the stutter, but there's still a noticeable
skip when switching buffers. We're gonna need to do better. :^)
I had to solve a bunch of things simultaneously to make this work.
Refactor AWavLoader to be a streaming loader rather than a one-shot one.
The constructor parses the header, and if everything looks good, you can
repeatedly ask the AWavLoader for sample buffers until it runs out.
Also send a message from AudioServer when a buffer has finished playing.
That allows us to implement a blocking variant of play().
Use all of this in aplay to play WAV files chunk-at-a-time.
This is definitely not perfect and it's a little glitchy and skippy,
but I think it's a step in the right direction.
It was a tad too bright. Also make sure we're using the same color in
all the different places. At some point it would be nice to improve global
color settings, etc.
We're going to be using dedicated server socket classes instead.
This was only implemented for CLocalSocket, and clients have been switched
over to using CLocalServer.
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.
Instead of trying to support both client and server in CLocalSocket, let's
have a specialized server class.
The basic usage is:
CLocalServer server;
server.listen("/tmp/name-of-portal");
server.on_ready_to_accept = [&] {
CLocalSocket* client = server.accept();
...
};
This will make things a lot simpler, since an accepting socket doesn't need
half of the stuff that a regular CIODevice provides. :^)
Since ChildAdded events originate from the CObject constructor, they are not
fully constructed when their parent learns that they were added.
Added a little comment about this to the child_event() declaration.
Make GWindow::close() so we can override it in GDialog and quit from the
internal event loop when the window manager tells us to close ourselves.
The dialog will return GDialog::ExecCancel in these situations.
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.
If we had already processed a couple of queued events by the time we were
told to un-nest the event loop, we'd put the entire current batch at the
head of the outer queue. This meant that we might end up trying to process
the same events multiple times.
Let's not do that. :^)
This one is a bit mysterious. I can't find any authoritative answer on what
the correct behavior is, but it seems reasonable to me that free() doesn't
step on errno, since it returns "void" and thus the caller won't know to
inspect errno anyway.
Cached tooltip windows were preventing the automatic event loop shutdown.
It's not like we were gaining much by caching these anyway, since we only
cached the GWindow, not anything on the WindowServer side.
This behavior and API was extremely counter-intuitive since our default
behavior was for applications to never exit after you close all of their
windows.
Now that we exit the event loop by default when the very last GWindow is
deleted, we don't have to worry about this.
This behavior is the new opt-out default. If you don't want your app to exit
when the last GWindow is destroyed, call this:
- void GApplication::set_quit_set_quit_when_last_window_deleted(bool)
Also renamed "windows()" to "reified_windows" in GWindow.cpp to reflect that
it only contains GWindows that have a server-side representation. :^)
