The FileManager PropertiesDialog always let the user change the name of
files and folders to then be prompted with write permissions error.
Now it checks for write permissions on the containing folder so it can
"disable" the TextBox input. We can't really disable TextBox right now,
hence the quotes.
Before this the delete action would be enabled in whenever was the case
in which the user had some selection made. This patch forces a check
to access() with the current folder path to see if the user actually can
delete nodes in it.
This action is a bit different to the regular paste action because it
takes into account the folder in which the context menu was opened,
so it can be enabled/disabled whether that folder is writable or not for
the current user.
Both paste action use the same logic, now moved to the function
do_action(const GUI::Action&), but in the case of the folder being
right clicked, it pastes inside of it.
Now the "New directory..." contextual menu is disabled if the current
user doesn't have enough permissions to create a node in the current
path.
This prevents the user going to the "New Directory" InputBox, writing
an appropriate name and accepting just to find they can't even do it :)
Now FileManager will paste the clipboard contents inside a folder if the
paste action was clicked through a folder context menu, being the target
directory the selected folder.
This mimicks most of the behaviours that the different file managers
have.
This patch adds GUI::Action::create_checkable() helpers that work just
like the existing create() helpers, but the actions become checkable(!)
Clients are no longer required to manage the checked state of their
actions manually, but instead they will be checked/unchecked as needed
by GUI::Action itself before the activation hook is fired.
Previously, drag and drop would only work when dragging between node
items on a DirectoryView. This commit makes it possible to drag files to
the empty area of the DirectoryView and copy files more easily between
windows.
When a drag operation is accepted, we don't check whether the source
nodes contain the destination directory. This could trigger an unwanted
recursive copy.
If the selection is empty, the model index will be invalid and the file
system model will return the root directory path by default. This causes
the file manager to jump to the root directory when the currently
selected item on the tree view is deselected.
FileManager can now be started with the --desktop argument. When it's
started in this mode, it will run as a WindowType::Desktop window and
not create any of its regular UI.
The desktop version of the file manager is currently pretty bare-bones
but we can improve it over time and share more code with the regular
file manager windows.
I think this is pretty cool! :^)
POSIX says, "Conforming applications should not assume that the returned
contents of the symbolic link are null-terminated."
If we do include the null terminator into the returning string, Python
believes it to actually be a part of the returned name, and gets unhappy
about that later. This suggests other systems Python runs in don't include
it, so let's do that too.
Also, make our userspace support non-null-terminated realpath().
This allows us to construct menus in a more natural way:
auto& file_menu = menubar->add_menu("File");
file_menu.add_action(...);
Instead of the old way:
auto file_menu = GUI::Menu::construct();
file_menu->add_action(...);
menubar->add_menu(file_menu);
We also clean up some old references to the old G prefixed GUI classes
This also fixes a potential bug with using: C_OBJECT_ABSTRACT(GAbstractButton)
instead of C_OBJECT_ABSTRACT(AbstractButton)
There were two issues with this code:
- The result of the readlink() call was checked incorrectly for errors.
- This code shouldn't return because otherwise it leaves the GUI buttons
uninitialized below, causing RefPtr asserts to trigger when the dialog
tries to access the buttons later on.
Now that add() returns a WidgetType&, we can't rely on the parent of a
GUI::Dialog to still keep it alive after exec() returns. This happens
because exec() will call remove_from_parent() on itself before
returning.
And so we go back to the old idiom for creating a GUI::Dialog centered
above a specific window. Just call GUI::Dialog::construct(), passing
the "parent" window as the last parameter.
Since the returned object is now owned by the callee object, we can
simply vend a ChildType&. This allows us to use "." instead of "->"
at the call site, which is quite nice. :^)
This patch adds two new API's:
- WidgetType& GUI::Window::set_main_widget<WidgetType>();
This creates a new main widget for a window, assigns it, and returns
it to you as a WidgetType&.
- LayoutType& GUI::Widget::set_layout<LayoutType>();
Same basic idea, creates a new layout, assigns it, and returns it to
you as a LayoutType&.
