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.
This commit unifies methods and method/param names between the above
classes, as well as adds [[nodiscard]] and ALWAYS_INLINE where
appropriate. It also renamed the various move_by methods to
translate_by, as that more closely matches the transformation
terminology.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
This warning informs of float-to-double conversions. The best solution
seems to be to do math *either* in 32-bit *or* in 64-bit, and only to
cross over when absolutely necessary.
I hereby declare these to be full nouns that we don't split,
neither by space, nor by underscore:
- Breadcrumbbar
- Coolbar
- Menubar
- Progressbar
- Scrollbar
- Statusbar
- Taskbar
- Toolbar
This patch makes everything consistent by replacing every other variant
of these with the proper one. :^)
The previous names (RGBA32 and RGB32) were misleading since that's not
the actual byte order in memory. The new names reflect exactly how the
color values get laid out in bitmap data.
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
The randomness is taken from arc4random() which is independent from srand/rand/rand_r,
so there's no need to call srand(). At best, it confuses the reader to think that
there would eventually be a call to rand().
Now that WindowServer broadcasts the system theme using an anonymous
file, we need clients to pledge "recvfd" so they can receive it.
Some programs keep the "shared_buffer" pledge since it's still used for
a handful of things.
