The default action (shown in bold) indicates what would you get
by double-clicking on file. Since it's a default option, I think it
deserves to be on top (together with alternative launch options). :^)
Also they're not task actions like "Extract .zip here" or "Add to
bookmarks".
Let DirectoryView manage these actions itself. This matches what we
already do for a bunch of other actions, and prepares for the next
patch which will add Config::Listener to the mix.
The `open()` function of DirectoryView should change the current working
directory, so that the "Go to Location" menu item can process relative
paths correctly. Update other functions in DirectoryView to use `open()`
when opening a directory.
The FileManager/Window/Maximized flag was incorrectly read from the
ConfigServer using read_i32 instead of the intended read_bool function
call.
It is now being read with the correct type :^)
Put the "Open in terminal" action next to the other navigation actions.
And separate the "New File" and "New Directory" actions from the actions
that operate on existing items.
This allows for typing [8] instead of [8, 8, 8, 8] to specify the same
margin on all edges, for example. The constructors follow CSS' style of
specifying margins. The added constructors are:
- Margins(int all): Sets the same margin on all edges.
- Margins(int vertical, int horizontal): Sets the first argument to top
and bottom margins, and the second argument to left and right margins.
- Margins(int top, int vertical, int bottom): Sets the first argument to
the top margin, the second argument to the left and right margins,
and the third argument to the bottom margin.
Previously the argument order for Margins was (left, top, right,
bottom). To make it more familiar and closer to how CSS does it, the
argument order is now (top, right, bottom, left).
Most of the models were just calling did_update anyway, which is
pointless since it can be unified to the base Model class. Instead, code
calling update() will now call invalidate(), which functions identically
and is more obvious in what it does.
Additionally, a default implementation is provided, which removes the
need to add empty implementations of update() for each model subclass.
Co-Authored-By: Ali Mohammad Pur <ali.mpfard@gmail.com>
The action never worked properly here. It used the selection
from the directory view, instead of the tree view.
Furthermore, the tree view isn't even editable.
Just making tree view editable wouldn't fix it -- it'd probably
need something like creating an on_stop_editing() function
in the AbstractView to change the path after the rename.
For now, I'll remove the action from the menu as a "temporary fix".
The original work was done in #2752
(deceb91c48 to be precise),
but unfortunately 2c772d1848 replaced
on_selection with on_selection_change, which caused the function
to never be executed, as it was reassigned a few lines below.
This fixes#6902.
Previously, dragging and dropping multiple files would create a window
for each file or directory that was selected. Now, we combine them and
show one progress window for the whole batch. :^)
Applications previously had to create a GUI::Menubar object, add menus
to it, and then call GUI::Window::set_menubar().
This patch introduces GUI::Window::add_menu() which creates the menubar
automatically and adds items to it. Application code becomes slightly
simpler as a result. :^)
Adds a new on_rename_error handler and renames the old on_error handler
to on_directory_change_error in FileSystemModel. The on_rename_error
handler creates a MessageDialog with the error message.
File Manager and Spreadsheet had an inconsistent order relative
to other apps (they had a copy-cut-paste order, where every other app
had a cut-copy-paste order).
The issue was that the desktop IconView has Gfx::FrameShape::NoFrame as
its frame shape, but with a non-zero frame_thickness().
This caused us to not render a frame, but to include one in the
selection boundary calculations.
Fix this by setting the desktop icon view's frame thickness to 0.
Fixes#8525.
This fixes#8204.
In the case that we just navigated up from a directory because it was
deleted, we can detect that easily by checking if the child directory
exists, and then remove the relevant breadcrumbs immediately.
However, it's harder to notice if a child directory for a breadcrumb
is deleted at another time. Previously, clicking that breadcrumb would
crash, but now we check to see if the directory it points to actually
exists. If it doesn't, we pop that breadcrumb and any after it, off
of the breadcrumbbar.
This may not be the ideal solution - maybe it should detect that the
directory is gone automatically - but it works and doesn't involve
managing additional directory watchers.
