The Parser should hold information relevant for parsing, whereas the
Document should hold information relevant for displaying pages.
With this in mind, there is no reason for the Document to hold the
xref table and trailer. These objects have been moved to the Parser,
which allows the Parser to expose less public methods (which will be
even more evident once linearized PDFs are supported).
This counter is increased each time a synchronous execution sequence
completes, and will allow us to emulate the abstract operations
AddToKeptObjects & ClearKeptObjects efficiently.
These are the actual structures that allow USB to work (i.e the ones
actually defined in the specification). This should provide us enough
of a baseline implementation that we can build on to support
different types of USB device.
Let clients manage their own window ID's. If you try to create a new
window with an existing ID, WindowServer will simply disconnect you
for misbehaving.
This removes the need for window creation to be synchronous, which
means that most GUI applications can now batch their entire GUI
initialization sequence without having to block waiting for responses.
This shows all selected inodes in their parent directory.
Currently, each selection makes a seperate call to LaunchServer
and opens a seperate FileManager window. In the future selections
with a shared parent could share windows.
Whether or not tiles moved used to be determined by comparing new_tiles
with m_tiles. This is no longer possible since the slide is done
in-place.
This fix makes the game look through the m_sliding_tiles, which contains
previous and current position for each tile on the board, to determine
whether any tile moved at all. If not, the move is deemed unsuccessful.
Fixes#8008.
This is very similar to Object::define_native_property, but here the
native functions are exported as standalone JS getter and setter
functions, instead of being transparently called by interactions with
the property.
Keeping this as a separate commit as I'm not certain whether this
is a good change or not. The repeated if-else for each Foundation
stack bothered me a bit, though more so before I reduced the code
in the {}. But maybe the ifs are clearer than the loop?
Doing that also meant I could inline the move_card() code instead
of needing to make it a lambda. Again, maybe it would be better as
a lambda? I'm still figuring out the style Serenity uses, and I
know Andreas is big on expressiveness, and move_card() is more
expressive than just having the code in the loop.
The two paths did the same thing, in two different ways. Now they
are the same. :^)
Can't quite put all of the logic into
attempt_to_move_card_to_foundations() because the double-click has
to check that you clicked on the top card.
