| Age | Commit message (Collapse) | Author |
|---|
|
New serenity_app() targets can be defined which allows application
icons to be emedded directly into the executable. The embedded
icons will then be used when creating an icon for that file in
LibGUI.
|
|
|
|
Not sure why I put this into LibGUI in the first place.
|
|
The qualified name of a font is "<Family> <Size> <Weight>". You can
get the QN of a Font via the Font::qualified_name() API, and you can
get any system font by QN from the GUI::FontDatabase. :^)
|
|
|
|
This adds a "settings" option that allows the user to configure the
board size and target tile, and optionally save them to a config file.
Closes #3219.
|
|
The logic only works with nxn grids, so no need to take separate
row_size/column_size arguments.
|
|
As requested by @nico
|
|
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.
|
|
|
|
This is a follow up to #2936 / d3e3b4ae56aa79d9bde12ca1f143dcf116f89a4c.
Affected programs:
- Applications: Browser (Download, View source, Inspect DOM tree, JS
console), Terminal (Settings)
- Demos: Cube, Eyes, Fire, HelloWorld, LibGfxDemo, WebView,
WidgetGallery
- DevTools: HackStudio, Inspector, Profiler
- Games: 2048, Minesweeper, Snake, Solitaire
- Userland: test-web
A few have been left out where manual positioning is done on purpose,
e.g. ClipboardManager (to be close to the menu bar) or VisualBuilder (to
preserve alignment of the multiple application windows).
|
|
|
|
|
|
|
