This does not add any behaviour change to the processes, but it ties a
TTY to an active process group via TIOCSPGRP, and returns the TTY to the
kernel when all processes in the process group die.
Also makes the TTY keep a link to the original controlling process' parent (for
SIGCHLD) instead of the process itself.
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
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.
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.
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.
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.
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
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.
