The timer is no longer used to trigger a paint event for all updates; it
is only used to paint the new-game and game-over animations. So only run
the timer during those events.
A series of events led to this change: The goal is to add more widgets
to the Solitaire GML, such as a GUI::Statusbar. To do so without this
change, the window ends up with some black artifacts between the main
Solitaire frame and the added elements, because the GML specifies the
main widget to have fill_with_background_color=false. However, setting
that property to true results in the background color of the widget
interferring with the Solitaire frame trying to manually paint its
background green. This results in flickering and some elements in the
Solitaire frame being painted over by the main background color.
To avoid all of that behavior, this sets fill_with_background_color=true
and the Solitaire frame's background color to green in the GML. Further,
the frame now only queues a paint update on the specific Gfx::Rect areas
that need to be updated. This also means we no longer need to track if a
stack of cards is dirty, because we only trigger a paint event for dirty
stacks.
No functionial change here, but this more easily allows for adding GUI
elements to the Solitaire window. This nests the SolitaireWidget as a
child of the main window's widget so that the SolitaireWidget does not
color the entire window green when it paints its background.
The purpose is to allow the Solitaire widget to be used in GML. The
macro to register a widget requires a namespace, so this moves all files
in the application to the Solitaire namespace. This also renames the
SolitaireWidget class to Game - this is to avoid the redundancy /
verbosity of typing "Solitaire::SolitaireWidget", and matches many other
games in Serenity (Breakout, 2048, etc.).
This is just a bit nicer than owning a separate timer in the Solitaire
application because LibCore will prevent timer events from firing when
e.g. the window is not visible. Therefore SolitaireWidget doesn't need
need to check for such conditions.
Stacks of cards currently cover the suit completely and players must
click-and-drag cards out of the way to see the suit beneath other cards.
This bumps the stacks down a bit to let players peek the suit without
having to take any action.
BuildIt.sh had a bunch of SC2086 errors, where we were not quoting
variables in variable expansions. The logic being:
Quoting variables prevents word splitting and glob expansion,
and prevents the script from breaking when input contains spaces,
line feeds, glob characters and such.
Reference: https://github.com/koalaman/shellcheck/wiki/SC2086
As bcoles noticed in #6772, shellcheck actually found a real bug here,
where the user's build directory included spaces.
Close: #6772
BuildFuseExt2.sh was saying it should be run under /bin/sh but it is
using bash extensions like pushd/popd, ${BASH_SOURCE[0]}, etc. So just
run it under bash to avoid any potential issues.
I can't say I like starting yet another thing on boot... but now that
LookupServer provides mDNS (and optionaly DNS) services to other hosts,
we have to start it on boot, not when the first local client connects.
The implementation is extremely basic, and is far from fully conforming
to the spec. Among other things, it does not really work in case there
are multiple network adapters.
Nevertheless, it works quite well for the simple case! You can now do
this on your host machine:
$ ping courage.local
and same on your Serenity box:
$ ping host-machine-name.local
An IP socket can now join a multicast group by using the
IP_ADD_MEMBERSHIP sockopt, which will cause it to start receiving
packets sent to the multicast address, even though this address does
not belong to this host.
When using `sysctl` you can enable/disable values by writing to the
ProcFS. Some drift must have occured where writing was failing due to
a missing `set_mtime` call. Whenever one `write`'s a file the modified
time (mtime) will be updated so we need to implement this interface in
ProcFS.
This was hiding on the serenityos.org website previously, where not
many people found it. Let's put it in a more natural location, and
also make sure to link to it from the README.
Also adds an AK::Empty struct, because 'empty' variants are useful, but
this implementation leaves that to the user (i.e. a variant cannot
actually be empty, but it can contain an instance of Empty - i.e. a
byte).
Note that this is more of a constrained Any type, but they basically do
the same things anyway :^)
The fact that current_time can "fail" makes its use a bit awkward.
All callers in the Kernel are trusted besides syscalls, so assert
that they never get there, and make sure all current callers perform
validation of the clock_id with TimeManagement::is_valid_clock_id().
I have fuzzed this change locally for a bit to make sure I didn't
miss any obvious regression.
The variety of checks for Processor::id() == 0 could use some assistance
in the readability department. This change adds a new function to
represent this check, and replaces the comparison everywhere it's used.
FileDescriptionBlocker::m_should_block was shadowing the parent's
FileBlocker::m_should_block variable, which would cause should_block()
to return the wrong value.
Found by @gunnarbeutner
For regular elements, this is just the qualified name.
However, for HTML elements in HTML documents, it is the qualified name
uppercased.
This is used by jQuery to determine the document is an HTML document.
Not having this made jQuery assume the document was XML, causing
weird behaviour.
To do this, an internal string of qualified name is created.
This is to prevent constantly regenerating it. This is allowed by
the spec.
This is the same for the HTML-uppercased qualified name.
This fixes extensive copying data around, and also makes head(1) in
bytes mode read exactly as much data as it needs.
Also, rename --characters to --bytes: that's exactly what it does
(actual character counting is way more complicated), and that's what
the option is called in GNU coreutils.
Fixes https://github.com/SerenityOS/serenity/issues/6852
