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.
We should stop accessing the FileSystemModel outside DirectoryView.
This whole app is pretty badly factored, due to LibGUI being in its
infancy while it first developed.
Since the vast majority of message boxes should be modal, require
the parent window to be passed in, which can be nullptr for the
rare case that they don't. By it being the first argument, the
default arguments also don't need to be explicitly stated in most
cases, and it encourages passing in a parent window handle.
Fix up several message boxes that should have been modal.
Ctrl-L focuses the location bar in all file managers I know of,
and does so in SerenityOS's browser too. It should work in
SerenityOS's file manager as well.
Unfortunately, Ctrl-L was already "View List", so change the
shortcuts of all the view modes to Ctrl-1/2/3 which is what
several other file managers use. (I tried Ctrl-Shift-1/2/3
which is what Windows Explorer uses after 8.1, but it didn't
Just Work, and Ctrl-1/2/3 are currently free anyways. If
we ever want to use them for tabs or whatever, we can
change the view shortcuts then.)
By adding a special LauncherType::Application we can still
get meta data for the application, but also know that we should
consider executing that binary as the default action. LaunchServer
will not do this for us, as it should probably not be allowed to
run arbitrary binaries that haven't been registered as handlers.
