| Age | Commit message (Collapse) | Author |
|---|
|
The initial inode link count was wrong in Ext2FS, as the act of adding
new inodes to their new parent bumps the count.
This regressed in df66c28479e9206adeef1f40f8c0e448c8aea77e.
|
|
urls were previously added to history in the Tab::load()
function, which excluded the setter on window.location.href.
This commit adds all urls to browser history when the page loads,
as long as the load_type is not LoadType::HistoryNavigation.
Closes #3148
|
|
Fixes duplicate GUI::DragOperation instances being created.
Fixes #3151
|
|
This fixes a bunch of unchecked kernel reads and writes, seems like they
would might exploitable :). Write of sockaddr_in size to any address you
please...
|
|
Note that the data member is of type ImmutableBufferArgument, which has
no Userspace<T> usage. I left it alone for now, to be fixed in a future
change holistically for all usages.
|
|
After encountering the terminating chunk we need to read the
trailing headers line by line, until encountering the final
empty line.
Fixes #3197
|
|
We need to update all button rectangles when the layout changed.
We also need to clear the taskbar button rectangle when we
remove a modal window button, so that WindowServer uses the
parent's taskbar button rectangle for the minimize animation.
|
|
If a modal window is being minimized, it may not have its own
taskbar rectangle. In that case, try finding a parent in the
modal window stack that does have one, and use that for the
animation.
|
|
|
|
|
|
This avoids a call to clone() which would be discarded immediately.
Also, avoid essentially cloning for each hammer rectangle unless
there is actually a need for it.
|
|
|
|
When minimizing/maximizing windows using the keyboard shortcuts
we should use the same logic dealing with modal windows as the
window frame buttons.
|
|
This object was cumbersome and annoying (mostly due to its manually
managed, statically sized name buffer.) And now we no longer need it!
|
|
We were only using this as a temporary helper object while constructing
directories. Create a simpler Ext2FSDirectoryEntry instead for this.
|
|
The list of children can just be a bunch of { name, inode }.
|
|
We don't have to ask the VFS to find our child inode, we have a pointer
to it right here.
|
|
Unlike DirectoryEntry (which is used when constructing directories),
DirectoryEntryView does not manage storage for file names. Names are
just StringViews.
This is much more suited to the directory traversal API and makes
it easier to implement this in file system classes since they no
longer need to create temporary name copies while traversing.
|
|
|
|
As requested by @nico
|
|
These kept annoying me, because these were the only two lines in the default
boot log that went unattributed.
|
|
This is how the original game does it.
|
|
See how straightforward this was? That's because, thanks to the separation
between the model and the view, we can tweak the view without modifying the
model in any way.
|
|
Look Ali, it's simple:
* The *model* (in many cases, an instance of GUI::Model, but it doesn't have to
be) should implement the "business logic" (in this case, game logic) and
should not concern itself with how the data/state is displayed to the user.
* The *view*, conversely, should interact with the user (display data/state,
accept input) and should not concern itself with the logic. As an example, a
GUI::Button can display some text and accept clicks -- it doesn't know or care
what that text *means*, or how that click affects the app state. All it does
is it gets its text from *somebody* and notifies *somebody* of clicks.
* The *controller* connects the model to the view, and acts as "glue" between
them.
You could connect *several different* views to one model (see FileManager), or
use identical views with different models (e.g. a table view can display pretty
much anything, depending on what model you connect to it).
In this case, the model is the Game class, which maintains a board and
implements the rules of 2048, including tracking the score. It does not display
anything, and it does not concern itself with undo management. The view is the
BoardView class, which displays a board and accepts keyboard input, but doesn't
know how exactly the tiles move or merge -- all it gets is a board state, ready
to be displayed. The controller is our main(), which connects the two classes
and bridges between their APIs. It also implements undo management, by basically
making straight-up copies of the game.
Isn't this lovely?
|
|
|
|
|
|
This makes the game look closer to the original.
It also fixes a weird thing where cells were displayed in a wrong order (as if
mirrored or something), and to accommodate for that keyboard actions were also
mixed up. Now it's all working as intended.
|
|
Reading the property has a few warts (see FIXMEs in the included
tests), but with this the timestamps on http://45.33.8.238/
get localized :^)
Since the Date() constructor currently ignores all arguments,
they don't get localized correctly but are all set to the current
time, but hey, it's still progress from a certain point of view.
|
|
|
|
|
|
|
|
This allows the users to customise what is shown when a command ends
without a newline.
|
|
This function didn't depend on the editor itself.
|
|
|
|
This makes the keybindings that depend on `m_termios` (^W, ^U, etc) work.
|
|
Rather than blitting and rendering each window every time, only
render what actually changed. And while doing so, only render
the portions that are visible on the screen. This avoids flickering
because flipping framebuffers isn't always perfectly in sync with
the code, so it's possible that the flip happens slightly delayed
and we can briefly see the next iteration having partially completed.
Also, avoid touching the mouse cursor unless it is in an area that
needs updating. This reduces flickering unless it is over an area
that is updated often. And because we no longer render the entire
screen, we'll save the contents below the cursor so that we can
hide it before touching that area.
Fixes #2981
|
|
|
|
|
|
|
|
|
|
This moves all internal functions to a new file, and defines the old
keybinds with register_key_input_callback().
|
|
|
|
|
|
Inspired by #3047, and my struggles to understand how cmake is supposed to work ^^
Thanks to @bgianfo, who made me realize that ninja can be used just like make.
No idea why I didn't notice that earlier.
|
|
AK/HashTable.h is not needed from SpuriousInterruptHandler
|
|
Also adds a TypeScript definition file for the test runner object.
|
|
...{All} to ParentNode. Exposes createDocumentFragment and
createComment on Document. Stubs out the document.body setter.
Also adds ParentNode back :^).
|
|
I forgot to add these when I saw that listing and xmp are mapped to
HTMLPreElement.
|
|
Instead of translating between the sorting proxy and the underlying
file system model at all the DirectoryView API boundaries, just hand
out indexes into the sorting proxy model.
The only thing those indexes are used for on the outside is to
retrieve a GUI::FileSystemModel::Node for an index, so add a nice
helper on DirectoryView that turns a ModelIndex into a Node&.
|
|
The Node API was obnoxiously requiring you to pass the model into it
all the time, simply because nodes could not find their way back to
the containing model. This patch adds a back-reference to the model
and simplifies the API.
|
