This was mentioned in #4574, and the more I think about it the more it
feels just right - let's move it there! :^)
Having to link LaunchServer against LibGUI explicitly should've been
telling enough...
This way, if you press F2 to edit the name of an item, the name will be
selected in the editor that pops up, and you can start typing a new
name for it immediately.
Move the shadow 1 more pixel away from the unhovered icon location,
making a total 2 pixel distance between the icon and the shadow.
Also tweak the shadow color to be a darkened variant of the base color
underneath the icon.
This was a goofy kernel API where you could assign an icon_id (int) to
a process which referred to a global shbuf with a 16x16 icon bitmap
inside it.
Instead of this, programs that want to display a process icon now
retrieve it from the process executable instead.
If an ELF application contains sections called "serenity_icon_s"
or "serenity_icon_m" then parse these as PNG images and use them
for the 16x16 and 32x32 executable file icons respectively.
If the application is not an ELF binary, the sections do not
exist, the sections are not valid PNGs, or the file cannot be read
then the default application icon will be used.
Problem:
- `(void)` simply casts the expression to void. This is understood to
indicate that it is ignored, but this is really a compiler trick to
get the compiler to not generate a warning.
Solution:
- Use the `[[maybe_unused]]` attribute to indicate the value is unused.
Note:
- Functions taking a `(void)` argument list have also been changed to
`()` because this is not needed and shows up in the same grep
command.
This patch replaces the UI-from-JSON mechanism with a more
human-friendly DSL.
The current implementation simply converts the GML into a JSON object
that can be consumed by GUI::Widget::load_from_json(). The parser is
not very helpful if you make a mistake.
The language offers a very simple way to instantiate any registered
Core::Object class by simply saying @ClassName
@GUI::Label {
text: "Hello friends!"
tooltip: ":^)"
}
Layouts are Core::Objects and can be assigned to the "layout" property:
@GUI::Widget {
layout: @GUI::VerticalBoxLayout {
spacing: 2
margins: [8, 8, 8, 8]
}
}
And finally, child objects are simply nested within their parent:
@GUI::Widget {
layout: @GUI::HorizontalBoxLayout {
}
@GUI::Button {
text: "OK"
}
@GUI::Button {
text: "Cancel"
}
}
This feels a *lot* more pleasant to write than the JSON we had. The fact
that no new code was being written with the JSON mechanism was pretty
telling, so let's approach this with developer convenience in mind. :^)
Just like the other event handler functions, handle_resize_event()
shouldn't assume that the window has a main widget (which is being
resized in this case).
Fixes#4450.
Let's make SelectionBehavior a view concept where views can either
select individual items (row, index) or whole rows. Maybe some day
we'll do whole columns, but I don't think we need that now.
This is a rather ugly hack just to get app icons to show up in the
FileManager. It would be a lot nicer to embed icons in executables
instead but it's not obvious to me how to do that.
Instead of symlinks showing up with the "filetype-symlink" icon, we now
generate a new icon by taking the target file's icon and slapping a
small arrow emblem on top of it.
This looks rather nice. :^)
If a hook triggers the deletion of the GUI::Button, we would be unable
to proceed in a well-defined manner here, so let's protect ourselves.
This probably needs to be done in a whole lot of places, since GUI
widgets are just ref-counted Core::Objects and running arbitrary code
can mean that they get deleted.