freq_bin was converted to double after it was calculated, so there was
a much higher probability it could be 0 instead of some comma number,
which meant that the bars always stayed on top.
The freq_bin in bins_per_group was multiplied only to be divided later,
which could even result in a crash if you set higher buffer size
(like 1000ms) in PlaybackManager, due to rounding errors I presume.
Casting u64 to float is probably not a safe thing to do. Also, keep
time deltas in u64 values as they can easily wrap between calculations.
This fixes CPU usage calculation when a process is spinning in a loop.
Prior this change, opening a playlist always spawned a new widget.
This could end up with having a few the same widgets, which you couldn't
even close (besides the last one).
The fd would get closed when the File went out of scope, so we couldn't
open any file specified by 'pp <path to file>'. We need the fd to be
alive and we solemnly swear to take good care of it and close it
ourselves later.
Previously all memory values on the performance was formatted as KiB,
but with such formatting it can be quite hard to read large numbers
(as mentioned by Andreas on todays office hours livestream :^)).
This patch makes use of the human readable formatting utilies and
displays them in an easier to read format.
Every tool that has a slider now registers the primary/secondary
sliders and now uses the same keyboard shortcuts to modify the
primary and secondary properties. `[` and `]` for the primary,
`{` and `}` for the secondary.
There are quite a few tools that might want to change certain values
based on consistent keyboard shortcuts. This commit allows tools to
hook up a "primary" and "secondary" slider with the base `Tool`
class, which can then handle updating those sliders with the common
shortcuts.
Note that any derived classes that want to override the `on_keydown`
function will manually need to call `Tool::on_keydown()`.
This new class will open and parse files (either images directly or .pp
project files) and one can get the parsed Image as well as other
information from it.
This patch removes a bunch of 'try_create_from..." methods from Image in
favor of using the ProjectLoader.
The only json_metadata that is available are Guides for now.
The ImageEditor knows more about the image than Image itself. So to save
a project with all the information known to the program about an image
it's logical that ImageEditor performs that task rather than the Image.
There isn't any additional data added yet, but now there's the
possibility to do so.
Our existing implementation did not check the element type of the other
pointer in the constructors and move assignment operators. This meant
that some operations that would require explicit casting on raw pointers
were done implicitly, such as:
- downcasting a base class to a derived class (e.g. `Kernel::Inode` =>
`Kernel::ProcFSDirectoryInode` in Kernel/ProcFS.cpp),
- casting to an unrelated type (e.g. `Promise<bool>` => `Promise<Empty>`
in LibIMAP/Client.cpp)
This, of course, allows gross violations of the type system, and makes
the need to type-check less obvious before downcasting. Luckily, while
adding the `static_ptr_cast`s, only two truly incorrect usages were
found; in the other instances, our casts just needed to be made
explicit.
And also try_create<T> => try_make_ref_counted<T>.
A global "create" was a bit much. The new name matches make<T> better,
which we've used for making single-owner objects since forever.
This also required adding a new hook to `ImageClient`, since there
wasn't a way of telling the ImageEditor that the full rect of the
image has changed (as when we rotate).
If we don't have enough layers to be able to scroll, the layers
are pushed to be at the top of the layer list. This doesn't make
much sense now that we are correctly drawing the layers in the
right order, so now we draw them justified towards the bottom.
Previously we were also clipping the bottom gadget slightly when
there were enough layers to scroll. Now, I'm adding some offset to
the total height to account for this and give equivalent spacing
from the top and bottom layers.
Previously the background layer was shown at the top, and layers
in front of it were shown below it. This was really unintuitive.
This patch fixes LayerListWidget to now properly differentiate
between the index of a gadget, and the index of a layer, since they
are essentially mirrored. I chose not to modify the order in which
layers are stored since back-to-front makes it really convenient
there.
This resets the DOM Inspector to a default state when re-opening it,
instead of it displaying the previous selection and properties, which
may be outdated. This is closer to how Chrome and Firefox behave.
Eventually, it probably makes sense to copy their behavior of selecting
the `<body>` element by default.
The direct-Document-access DOMTreeModel is no longer used, since the DOM
Inspector has to access the Document remotely over IPC. This commit
removes it, and renames DOMTreeJSONModel to take its place, since it no
longer has to differentiate itself from the non-JSON one.
In case that didn't make sense:
- Delete DOMTreeModel
- Rename DOMTreeJSONModel -> DOMTreeModel
Also simplify the logic by removing `Tab::view_dom_tree()`, and making
the Tab keep a pointer to the InspectorWidget instead of its Window,
since that's more often what we want to access.
We use TextEditor::on_modified_change() to update the modified window
flag, which it also works on file saves, so we don't have to unset
it there anymore!
It isn't really what the FIXME note asked about -- GUI::TextDocument
only sends us notifications about the changes, but overall I don't
think it's that bad, given that the whole window update logic is now
in one function. :^)
Previously it would only change the color of the ColorWidget itself,
but not make it the primary/secondary color. I think it feels nicer
this way, if I'm adding a color to the palette I likely want to use
it.
If you *really* need to only change the color of the palette, you
can just Ctrl+Middle click.
Previously, if you wanted to use a custom color, the only way to
do so was to first Ctrl+click on one of the pallette colors, which
would just change that palette item. Then, you would need to
manually click on that color.
Now, you can just click on the preview of the primary/secondary
color to open up the picker and only temporarily use the new color
without affecting the palette at all.
Only one place used this argument and it was to hold on to a strong ref
for the object. Since we already do that now, there's no need to keep
this argument around since this can be easily captured.
This commit contains no changes.
