FileManager windows now alternate between the old-style location text
box and a new-style breadcrumb bar. The location bar shows up when you
try to edit the location (with Ctrl+L) and disappears once the textbox
loses focus.
The textbox and breadcrumb bar are mutually exclusive to keep it tidy.
The focus_dependent_delete_action that sits in the file manager's
toolbar would always remain enabled, even if nothing was selected,
activating it if nothing was selected would then crash the application.
The action is now correctly enabled/disabled, but due to the way
selection works in TreeViews, something is always selected, what really
matters is if the TreeView has something selected, and it has focus.
As it currently stands, there is no way to know when the TreeView's
is_focused status changes. In order for this to work I added a callback
to the Widget class which fires when a widget receives or looses focus.
In that callback, the focus_dependent_delete_action's enabled value is
recalculated.
TreeViews using FileSystemModels collapse whenever the file system is
changed in anyway. This includes creating, dragging, deleting or
pasting any files/folders. This commit updates the refresh_tree_view()
lambda, which seems to have stopped working at some point, and calls it
whenever any of the actions mentioned above are activated.
We can't use current_view() before we've actually constructed the
subviews, so just ignore statusbar update requests before they get
a chance to call current_view().
This is not the most beautiful thing, and maybe we can think of a
nicer approach.
Setting it as model root path in DirectoryView::setup_model() for
windowed mode as well would cause an issue with the following:
- "open ~/Desktop"
- "FileManager ~/Desktop"
- "Show in FileManager..." from Desktop context menu
When viewing the Desktop as the initial path it would be the same and
on_path_change wasn't called, leading to various widgets and window
properties not being updated.
Fixes#3772.
This enables inline editing of filenames for table views, where this is
already supported. More work in LibGUI will be required to support the
feature in icon and columns views.
When opening something in the left-side treeview, it also opens in the
right-side directory view. That triggers the "path changed" hook in the
directory view, which causes us to fully reveal the opened directory
in the left-side treeview.
This feedback loop made the UI feel weird since it caused directories
to expand just by selecting them in the left-side treeview. So let's
break that loop.
Use the new TreeView::expand_all_parent_of() API to ensure that newly
opened directories are revealed and scrolled-into-view in the left-side
treeview. :^)
When we enter an inaccessible directory, we still allow that directory
to become selected in the left-side treeview, so we need to update the
location box and window title to reflect the new current path.
This is not perfectly factored and there's a bit of duplication between
the model's on_error and on_complete hook callbacks in DirectoryView.
Needs more work. :^)
Instead of popping up a message box whenever we can't read an opened
directory, show the error message inside the DirectoryView (as a label)
instead.
This fixes a visual inconsistency where an inaccessible directory would
be selected in the left-side treeview while the previous directory's
contents were still showing on the right.
This also makes keyboard navigation a bit more pleasant since you're
not suddenly interrupted by a message box.
This gives you something to click on if you actually want to open
the root directory. Previously, if you wanted to get to /, you had to
use the "to parent directory" repeatedly. Silly. :^)
This code was confusing two different versions of scroll_into_view that
were getting mixed up due to member function shadowing.
Adding an "override" to the subclass declaration exposed the problem.
With this fixed, we no longer lose our scroll position wildly when
using the mouse to select TreeView items.
This is a little bit messy since the left-side treeview also has a
delete action. Because of that, we have to put a focus-dependent action
that delegates to the relevant view-specific action in the tool bar
and menu bar.
I'm not sure yet what a good abstraction would be for this. We'll see
what we can think of.
Instead of translating between the sorting proxy and the underlying
file system model at all the DirectoryView API boundaries, just hand
out indexes into the sorting proxy model.
The only thing those indexes are used for on the outside is to
retrieve a GUI::FileSystemModel::Node for an index, so add a nice
helper on DirectoryView that turns a ModelIndex into a Node&.
The Node API was obnoxiously requiring you to pass the model into it
all the time, simply because nodes could not find their way back to
the containing model. This patch adds a back-reference to the model
and simplifies the API.
This patch begins the process of converting FileManager's desktop mode
to using the DirectoryView class.
This will allow us to share most of the code between the two different
runtime modes of FileManager.
We lose a bit of functionality in this patch, but we'll bring it back!
I noticed that nothing actually applies the wallpaper on startup.
I wasn't sure where to put the responsibility, so I gave it to
the desktop mode file manager.
Also adds a save_config option to set_wallpaper so it doesn't
needlessly save the config.
Instead of SortingProxyModel having a column+order, we move that state
to AbstractView. When you click on a column header, the view tells the
model to resort the relevant column with the new order.
This is implemented in SortingProxyModel by simply walking all the
reified source/proxy mappings and resorting their row indexes.
This removes one major source of confusion in DirectoryView. It's still
weird that we mix sorting model indexes with filesystem model indexes
a bit willy-nilly but we'll improve that separately.
