By "hide" I really mean collapse them down to 24px height. We grow them
to a normal size when they're needed. The user is also free to resize
them at will.
This keeps them out of the way when you just want to do editing. :^)
Instead of only doing a relayout in the widget you're invalidating,
we now do a recursive top-down relayout so everything gets updated.
This fixes invalid results after updating a preferred size in some
situations with nested layouts.
Add a list of hard-coded standard types (including AK types) and show
them in a different style.
Rehighligt the file whenever it changes. (This is very inefficient but
makes it much easier to experiment.)
Also keep tweaking the colors. :^)
When we open a file whose name ends in ".cpp", we now pass the contents
through CppLexer, which produces a CppToken stream.
Those CppTokens are then converted into GTextEditor::Spans and handed
over to GTextEditor which then colorizes the source code accordingly.
This is pretty neat. :^)
It's now possible to give GTextEditor a vector of Span objects.
Spans currently tell the editor which color to use for each character
in the span. This can be used to implement syntax highlighting :^)
Added a window creation callback to GApplication that gets called
by GWindow which will reset any pending exit request in the
CEventLoop.
This is to prevent a bug which prevents your application from
starting up if you had a message box or other dialog before
showing your main application form. The bug was triggered by
there being no more visible windows which was triggering a
premature quit().
I broke this when factoring out the find-in-files widget into its own
class. This patch adds a main_editor() global getter for grabbing at
the main GTextEditor from wherever you are.
I have no idea why this was here. It makes no sense. If you're trying
to find out if something is a directory, why wouldn't you be allowed to
ask that about a FIFO? :^)
Thanks to Brandon for spotting this!
Also, while we're here, cache the directory state in a bool member so
we don't have to keep fetching inode metadata when checking this
repeatedly. This is important since sys$read() now calls it.
This is the closest I could figure out how to get to what's actively
running on the terminal view at the moment.
Perhaps we can bundle up every process with the same tty and sum it
all up somehow. I'm not sure.
This makes tcgetpgrp() on a master PTY return the PGID of the slave PTY
which is probably what you are looking for. I'm not sure how correct or
standardized this is, but it makes sense to me right now.
We now have a little widget that sits above the terminal view in the
build/application console. When a child process is running, we show its
PID, name, scheduling counter, and amount of resident memory in a live
little overview.
This is not working right just yet, since we don't know how to get to
the actually active PID on the TTY. Or, well, we find the active PID by
looking at the PGID of our fork()ed child.
This manages to find children spawned by Shell, but not children
spawned by make, for instance. I need to figure out how to find those.
We now return EISDIR whenever a program attempts to call sys$read
on a directory. Previously, attempting to read a directory could
either return junk data or, in the case of /proc/, cause a kernel
panic.
When using the bounded string operations (e.g. snprintf), the null
terminator was always being written even if there was no space for
it (or indeed any valid buffer at all)
This overwriting caused segmentation faults and memory corruption
When attempting to open a file that doesnt exist or has permission
problems, the application would end after hitting OK on the message
box instead of starting up to an empty editor.
I believe this has something to do with the dialog event loop
interfering with the application event loop, or possibly the fact
that the window creation code is in the show() method.
To work around this I now call the open_file() method after the
show() method.
Have Ctrl+Shift+F open the find-in-files widget and focus the text box
so you can start entering text right away.
Also make it do a search when you press the return key.
Projects now contain a set of TextDocument objects. Each TextDocument
represents a member file in the project. TextDocuments may not have
their file contents loaded at all times, but they will be loaded on
demand when calling TextDocument::contents().
"Find in files" works by iterating over the documents in the project
and calling find(needle) on each one. The return value from find() is
a vector of line numbers where the needle was found.
This is obviously going to need a bunch more work. :^)
This could happen if a child was added to a GTabWidget before the
GTabWidget had its first layout.
Also add an assertion to catch this in GWidget::set_relative_rect()
since it was not immediately obvious what was happening.
Previously we would not run destructors for items in a CircularQueue,
which would lead to memory leaks.
This patch fixes that, and also adds a basic unit test for the class.
Fixed an issue with operator precedence in calls to `send_byte()`, in
which a value of `1` was being sent to the function. This had the
nasty side-effect of selecting the slave drive if the value of
`head` was equal to one. A read/write would fail in the case, as
it would attempt to read from the slave drive (not good).
I've also added a seek to the top of the read/write code, which seems
to have fixed an issue with Linux not detecting the disk images after
they have been unmounted from Serenity. This isn't specified in the
datasheet, but a few other drivers have it so we should too :^)
Thread::make_userspace_stack_for_main_thread is only ever called from
Process::do_exec, after all the fun ELF loading and TSS setup has
occured.
The calculations in there that check if the combined argv + envp
size will exceed the default stack size are not used in the rest of
the stack setup. So, it should be safe to move this to the beginning
of do_exec and bail early with -E2BIG, just like the man pages say.
Additionally, advertise this limit in limits.h to be a good POSIX.1
citizen. :)
Previously, procfs$pid_fds would return nothing when called
for a process that had either no open files or a non-existent
handle. This could cause problems when a userspace program
expected a valid Json response.
Procfs$pid_fs now returns an empty array in the aforementioned
cases.
