ec9fa78...
by
=?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>
window-slot: Clean up location loading error handling
We have a whole branch of dead code under the condition that a window
is not visible. This is dead code because, as of GTK4, the :visible
property is TRUE by default; but even before that, I doubt the window
wasn't presented already before this callback.
The logic on this conditional branch is ancient[0] and employs rather
drastic measures: destroy the window if it failed to load its initial
location. At a later point[1], a special case hase been added not to
destroy the window if there is no other nautilus window. It would open
Home instead, or, failing that, the filesystem root. But if both fail,
it would still resort to destroying the window.
Not only is destroying the window unecessary, the special case of a
single application window assumes NautilusWindowSlot can only exist
inside a NautilusWindow (belonging to NautilusApplication). This is
going to be a problem for the FileChooser window, which will not be
a NautilusWindow, not belong to the NautilusApplication, but still
run in the same process.
Let's drop the dead branch. But salvage the handling of rare cases
where $HOME fails to load for some reason.
2676748...
by
=?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>
files-view: Don't assume NautilusWindow ancestor
We don't need to, for a matter of fact. `gtk_widget_get_root()` is
just as effective and is going to make it easier to reuse in the
upcoming FileChoser window.
e826c9c...
by
=?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>
previewer: Manage window handles internally
We've been expecting NautilusFilesView to pass a window handle to
nautilus_previewer_call_show_file(), requiring it to call async
methods from NautilusWindow to get them.
There are a few problems with this approach:
1. It's a layer violation for the view to call into the window.
Not only is this conceptually wrong, it's keeping us from
reusing the view in other windows which are not NautilusWindow
instances, like as the upcoming FileChooser window.
2. It's leaking details of the NautilusPreviewer2 D-Bus API into
NautilusFilesView and NautilusWindow, namely the expected format
of the window handle.
3. Even though this format is a de-facto standard nowadays, we are
not using it for anything else, so there is no value in keeping
it in NautilusWindow API.
4. Even if we start using it for other purposes, there it nothing
specific to NautilusWindow in how to generate a window handle;
it's the same process for any toplevel surface.
5. Tying the window handle's validity to the lifetime of the
NautilusWindow instance means we keep it exported even if no
longer used by the previewer, and in theory we would use the
same handle for multiple peers.
So, have NautilusFilesView pass a generic GtkRoot pointer instead
and handle the exporting and unexporting lifetime of window handles
in the previewer glue code instead.
The NautilusWindow API, no unused, is also removed. If the need arises
in the future to reuse this export/unexport logic, we can always move
it into ui-utilities.c or something like that.
1e28526...
by
=?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>
pathbar: Don't call NautilusWindow nor NautilusApplication
We want to make the pathbar reusable for the FileChooser window,
which is neither going to be a NautilusWindow nor part of the
NautilusApplication instance.
But we don't really need anything from the application or window
classes which cannot be done directly with the slot class. And
the slot is going to be reused in FileChooser too.
In order to have access to the slot, expect the pathbar owner
(currently only NautilusToolbar) to set it as a property. The
FileChooser is going to be able to set the slot itself as well.
0e35fe8...
by
=?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>
toolbar: Have PathBar and LocationEntry in UI template
We have "container" boxes in the .ui file to which we add the
actual widgets in code.
I believe this was done back when we desired these UI files to
be editable in Glade, which didn't know our custom widgets.
But we no longer care about that, so let's do everything in the
UI template. This will make the next commit simpler by enabling
bindings to be declared in the UI template as well.
63084c4...
by
=?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>
files-view: Stop getting active slot from the window
We can ask the slot directly whether it is the active one.
This removes one NautilusWindow method call from inner widgets,
which is a layer violation and gets in the way of reusing them
for the upcoming FileChooser window.
