| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Now that we have a subclass we can override the function instead of
special casing in the parent.
Also we can remove the internal boolean "sort for desktop".
And finally we can remove any desktop dependency in canvas view container.
|
| |
|
|
|
| |
Now that we have a subclass we can override the function instead of
special casing in the parent.
|
| |
|
|
|
| |
Now that we have a subclass we can override the function instead of
special casing in the parent.
|
| |
|
|
|
|
|
|
| |
So we can use a subclass for the desktop.
This will be necessary in upcoming patches in order to handle the
special links on desktop that currently are done special casing inside
the parent canvas view container.
|
| |
|
|
| |
So subclasses can use G_DEFINE_FINAL_TYPE.
|
| |
|
|
|
| |
This will be used by the desktop, so it can use its own
canvas-view-container.
|
| |
|
|
|
|
|
|
|
|
|
| |
We were special casing desktop icon files to not show the Open With
tab in the properties window.
However, this is just equal to what we need to do to display Open With
in the context menus, where we check if the app has a possible
application handling it or not.
Do the same here so we can remove another desktop dependency.
|
| |
|
|
|
|
| |
Now that we have the code to request the target uri in nautilus file,
we can use that instead of our own code special casing subclasses of
nautilus file.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
We need to avoid showing the operations popover in the desktop, or
basically in any window that has the disable-chrome property set.
We can check inside the toolbar if the toolbar itself is hidden in order
to know whether it makes sense to show the operations popover.
In this way we don't relay in special casing subclasses of the window.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
And allow overriding of subclasses.
Nautilus mime actions file currently uses the file as parameter, as if
it was part of the nautilus file class.
However it's hosted in a different file, even though we need to special
case some subclasses of nautilus file for its management.
imho, this code design is wrong, since it defeats the purpose of OOP.
So move it to the nautilus file, allow overriding, and override this
vfunc in the subclasses that need it, like the desktop-icon.
|
| |
|
|
|
|
|
|
| |
We use disable-chrome all around to not show anything that comes
from the chrome of the window.
We can use it on all the cases, so we can avoid to special casing the
desktop.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Since the desktop files needs to do nothing at all.
This removes the last desktop dependency from nautilus file (yay).
|
| |
|
|
|
| |
Now that we can use inheritance for dnd handling, use it in the subclass
instead of special casing on the parent.
|
| |
|
|
|
|
|
| |
We are special casing some cases where we want to do something different
in subclasses.
Allow to override this function so subclasses can use it.
|
| |
|
|
| |
Subclasses may want to override some dnd handling.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are requiring file handling like special casing subclasses in the
dnd handling.
We are currently doing it outside of nautilus class... which makes
overriding on subclasses impossible.
This design goes against inheritance design, so there is no point on
making it that way if it defeats this purpose.
So merge the handling of file dnd inside the file class itself, and in
upcoming patches we will override that handling in order to use
inheritance instead of special casing in the parent.
|
| |
|
|
|
| |
Now that we can do it in subclasses, use inheritance instead of special
casing in the parent.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This get target uri is used for those which we have special handling on
the activation uri, instead of the usual glib attribute
G_FILE_ATTRIBUTE_STANDARD_TARGET_URI. So it behaves like a supergroup
of those which have G_FILE_ATTRIBUTE_STANDARD_TARGET_URI, but we use
it in the same way.
We use for handling special files like desktop links on drag and drop,
etc.
However, this is useful for other parts of nautilus, and we will use it
in a upcoming patch, so we can rename it in order to communicate the
wide nature of the function.
|
| |
|
|
|
| |
So subclasses like desktop icon can make its own handling, instead
of special casing in the parent.
|
| |
|
|
|
| |
Now that we can override the vfuncs needed for special casing the
desktop icon files, move all that handling to the subclass.
|
| |
|
|
| |
We will need it for using inheritance instead of special casing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now we were creating the desktop directory in a lazy way, like
any other cached directory.
However, we have the problem that at some point we have to dispatch
between different types of files, when creating them for the cache.
We cannot know when we will need to create the desktop directory for
first time in order to discern between that type of directory, or the
regular one.
What we can do is ensure that we created the desktop directory before
any other part of nautilus request it. In this way, we can create it
on our subclasses of the desktop, and after that, nautilus will request
the cache as a regular use, without the need to special case the
desktop.
For that, create the desktop directory when the desktop application
starts, holding the reference so the cache doesn't release it, and then
let nautilus work as expected.
For that, in previous commits we moved the file dispatching to be inside
the directory, so now any file creation happens inside the directory,
and therefore we can control, when creating the desktop directory, what
subclass will be called.
|
| |
|
|
|
|
| |
So we use inheritance instead of special casing, making possible
to remove the desktop dependency for the creation of the desktop
files.
|
| |
|
|
| |
So subclasses like the desktop directory can do their own.
|
| |
|
|
|
|
|
|
|
|
| |
It's the directory who owns the files, and we were actually creating
new files from nautilus directories in nautilus-file.
We can move that code to nautilus directory.
In this way, we will able to handle files of a specific scheme better,
like the desktop, in future patches.
|
| |
|
|
| |
Now that we are free of special casing.
|
| |
|
|
|
|
|
| |
Now that we have the necessary subclasses for special slots and views
like the desktop and the other locations one, we can rely on those for
disabling the actions that are not available on those and check for
those actions state instead of special casing subclasses.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to special case the other locations view when using that
location, since it's not a files-view and doesn't support several things
that we usually support, like the changes between icon view and list
view.
Also we specifically special case its creation in window slot and we
disable few actions that are not available on it.
This patch creates a other locations slot, which will handle all of it.
The class that is responsible of creating one type of slot or another is
the window, and will use a vfunc that will request whether the slot
handles a location or not and will act accordingly.
In upcoming patches we will move all the special casing of this and the
desktop in the window slot to its respective subclasses now that we have
everything ready.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We are special casing to open the desktop, so in case we try to
open the desktop in this window slot, and was already opened, we
were opening it again.
I cannot see a reason why we would need to open it anyway if was
already opened, and the test I did works fine.
So let's remove it for now, so we remove another special casing of the
desktop.
|
| |
|
|
|
|
|
|
|
|
|
| |
We were special casing to not enable search in some cases where some
special view, like the desktop, doesn't allow it.
But that shouldn't be special cased here, but instead use a subclass of
the window slot and disable it there.
Now that we have that, move the special casing to inheritance for
disabling the search in the desktop.
|
| |
|
|
|
|
|
|
| |
Now that we can create our own custom views in subclasses of the window
slot, we can remove the special casing for subclasses in window slot and
instead use inheritance for it.
This commit move the creation of the desktop view to the desktop slot.
|
| |
|
|
|
|
|
|
| |
We would want in subclasses of nautilus window slot to have a way to
create custom views, like for instance, the desktop.
To allow it, make a vfunc for the creation of views that subclasses can
override.
|
| |
|
|
|
|
|
|
| |
We want to control few code paths, like the creation of the
desktop canvas, which currently is done by special casting in the window
slot instead of subclassing.
So create a window slot subclass that will serve for these purposes.
|
| |
|
|
|
|
|
|
| |
We are not able to create subclasses of window slots, like the one
we will need for desktop.
So create a vfunc to handle that, and expose the common code in a public
function so subclasses can use it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When a script is present we set some environment variables to allow
the scripts to work with them.
For example, we set a environment variable for selected items.
However, some views have special links, like the desktop. Therefore we
need special treatment for those.
Use inheritance instead of doing special casing in the parent class
for this case.
|
| |
|
|
|
|
|
|
|
|
| |
There is a few times that the file cannot be copied, moved etc.
This usually happens with the special links in the desktop.
We were querying whether the selection has special items or not
in the files-view itself. However, this is something that every view
could have special, like the desktop one.
So use inheritance for it.
|
| |
|
|
| |
If not the desktop will show it with insensitive, which is odd.
|
| |
|
|
|
| |
We don't want always empty states, for example, in the desktop.
Use inheritance to allow children to do its own handling.
|
| |
|
|
| |
So we remove another desktop special case
|
| |
|
|
| |
So we can remove another special casing of the desktop in a parent class
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were assuming we had in cache the files used for dnd, but with
the desktop split that's not longer the case.
What can happens is that we cannot discern whether the drop action
should be a copy or a move, since Nautilus always performs a move if
the file system is the same as the dragged files.
To fix it, in a best effort mode, we will request to update the files
information if it's not available. In future times it will be requested,
and if the files are not freed, we will have the file system information
available in order to decide a more appropriate drop action.
|
