There is no need to iterate through all events in a profile when
loading the timeline view, as soon as we see one event we can
move on to the next process.
This unix classic attempts to classify and identify information about
given files based on various heuristics. In this case, we're relying on
the Core::MimeData detector for file type and LibGfx::ImageDecoder for
additional metadata if the given file is an image.
It's very simple for now, but adding new detectors should be quite easy.
This attempts to guess the mime-type from a given set of bytes from the
start of a file. It only supports a few well-defined patterns for now,
but it's a start!
This patch removes an incorrect way for TextDocument::text_in_range
to return early when the first line of the selection was empty. This
fixes an issue in TextEditor where the status bar showed that 0
characters are selected when the selection started on an empty line.
The architecture here is a little bit convoluted. I ended up making a
new container widget (TimelineContainer) that works similarly to
GUI::ScrollableContainerWidget but has two subwidgets (a fixed header
that only scrolls vertically, and the timeline view that scrolls on
both axes.)
It would be nice to generalize this mechanism eventually and move it
back into LibGUI, but for now let's go with a special widget for
Profiler so we can continue iterating on the GUI. :^)
Instead of smashing together all the samples into a single timeline,
make one per process and put them all in a ScrollableContainerWidget.
This makes it much easier to see which processes were active and when.
No timeline is displayed for processes with zero samples in the profile.
Legally we could just return a null pointer, however returning a
pointer other than the null pointer is more compatible with
improperly written software that assumes that a null pointer means
allocation failure.
With the goal of centralizing all tests in the system, this is a
first step to establish a Tests sub-tree. It will contain all of
the unit tests and test harnesses for the various components in the
system.
Only keep track of that (and eventually close() it) internally instead.
This argument is not present on other systems, so we were running into
compatibility issues with ports.
Also bring the implementation closer to Linux and OpenBSD by making sure
to close the slave pty fd in the fork()'d child as well as _exit()'ing
on login_tty() failure - it's non-POSIX, so those are our references
here. :^)
* Remove unnecessary #include statements
* Move it into the TextEditor namespace
* Mark the single-argument constructor explicit
* Use move() to avoid some unnecessary copies
By default malloc manages memory internally in larger blocks. When
one of those blocks is added we initialize a free list by touching
each of the new block's pages, thereby committing all that memory
upfront.
This changes malloc to build the free list on demand which as a
bonus also distributes the latency hit for new blocks more evenly
because the page faults for the zero pages now don't happen all at
once.
This also moves Widget::load_from_json into Core::Object as a virtual
function in order to allow loading non-widget objects in GML (e.g.
BoxLayout).
Co-authored-by: Gunnar Beutner <gbeutner@serenityos.org>
This widget provides a scrollable view onto another (child) widget.
If the child is larger than the parent, scrollbars are provided for
panning around the child.
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.
