Fork the IPC Connection classes into Server:: and Client::ConnectionNG.
The new IPC messages are serialized very snugly instead of using the
same generic data structure for all messages.
Remove ASAPI.h since we now generate all of it from AudioServer.ipc :^)
- Add IEndpoint::handle(IMessage), a big switch table on message type.
handle() will return a response message for synchronous messages,
and return nullptr otherwise.
- Use i32 instead of int for everything
- Make IMessage::encode() const
- Make IEndpoint::decode_message() static, this allows template code to
decode messages without an endpoint instance on hand.
If the underlying variant type is a String, try to parse out a color
when to_color() is called.
This makes VisualBuilder apply the saved colors when loading forms.
This API was returning a "const char*" and it was unclear who took care
of the underlying memory. Returning a String makes that obvious.
Also make sure we close the /etc/passwd file when we're done with it.
It is now possible to mount ext2 `DiskDevice` devices under Serenity on
any folder in the root filesystem. Currently any user can do this with
any permissions. There's a fair amount of assumptions made here too,
that might not be too good, but can be worked on in the future. This is
a good start to allow more dynamic operation under the OS itself.
It is also currently impossible to unmount and such, and devices will
fail to mount in Linux as the FS 'needs to be cleaned'. I'll work on
getting `umount` done ASAP to rectify this (as well as working on less
assumption-making in the mount syscall. We don't want to just be able
to mount DiskDevices!). This could probably be fixed with some `-t`
flag or something similar.
Furthermore, fread() has already handled EOF, so there's no need to do
it again. If we read a character, return it, otherwise return EOF.
Note that EOF means "EOF or error" here.
There's some confusion between the write syscall and CIODevice::write()
here. The internal write() returns a boolean, and has already whined
in case the syscall failed, so we don't need to do that again.
I originally thought I'd have to implement text clipping in Painter for
this, but it seems like I can get away without doing that today. :^)
Fixes#390.
In the event where you want to find the index of a deeply-nested path
with a GFileSystemModel that hasn't yet traversed most of that path, it
is possible for a false negative failure to occur. This failure is
caused by the GFileSystemModel incorrectly bailing out of the search
when it hits the first unseen path segment that is not at the very end
of the path.
This patch fixes this problem by reifying the intermediate nodes during
that search and traversal process.
The goal here is to generate most of this code from IPC protocol
descriptions, but for now I've spelled them all out to get started.
Each message gets a wrapper class in the ASAPI_Client or ASAPI_Server
namespace. They are convertible to and from the old message structs.
The real hotness happens when you want to make a synchronous request
to the other side:
auto response = send_sync<ASAPI_Client::GetMainMixVolume>();
Each request class knows his corresponding response class, so in the
above example, "response" will be an ASAPI_Server::DidGetMainMixVolume
object, and we can get the volume like so:
int volume = response.volume();
For posting messages that don't expect a response, you can still use
post_message() since the message classes are convertible:
post_message(ASAPI_Server::DidGetMainMixVolume(volume));
It's not perfect yet, but I already really like it. :^)
Give the mixer a main volume value (percent) that we scale all the
outgoing samples by (before clipping.)
Also add a simple "avol" program for querying and setting the volume:
- "avol" prints the current volume.
- "avol 200" sets the main mix volume to 200%
We had some kernel-specific gizmos in AK that should really just be in the
Kernel subdirectory instead. The only thing remaining after moving those
was mmx_memcpy() which I moved to the ARCH(i386)-specific section of
LibC/string.cpp.
Processes can now have an icon assigned, which is essentially a 16x16 RGBA32
bitmap exposed as a shared buffer ID.
You set the icon ID by calling set_process_icon(int) and the icon ID will be
exposed through /proc/all.
To make this work, I added a mechanism for making shared buffers globally
accessible. For safety reasons, each app seals the icon buffer before making
it global.
Right now the first call to GWindow::set_icon() is what determines the
process icon. We'll probably change this in the future. :^)
Show some information about the file we're playing, and display how many
samples we've played out of how many total.
This might be a bit buggy as I haven't tested it with many different files,
but it's a start. :^)
This is a total hack, because I haven't really looked into why these are
happening. Somehow we're producing one extra sample and it's glitching
up the sound stream ever so slightly.
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.
