| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
The problem is that in the function canvas_container_set_workarea the screen width
and height are in "application pixels" while the workarea ones are in "device
pixels" so when the scaling is > 1, the margins are not properly setted.
We need to scale-down the workarea geometries to "application pixels".
https://bugzilla.gnome.org/show_bug.cgi?id=769302
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We were using the internal list of the application to
iterate through the windows and closing them.
Problem is that when closing one window, the list is modified,
so next time accessing the list we are accessing the "old"
list, which is invalid and makes nautilus crash.
To fix it make a copy of the list to preserve the consistency.
https://bugzilla.gnome.org/show_bug.cgi?id=755803
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This looks not very harmful. But definitely is.
Thing is, when using nautilus_action_from_menu_item it keeps
a reference to the NautilusMenuItem from the extension.
So that menu item will never be freed.
Now, let's imagine nautilus-open-terminal have a ref to the file
that the item points to, and only unref it when the item is destroyed.
Now, sum that when a file is not unrefed completely from nautilus
when unmounting the file, so it's mark as gone and cannot be used again.
Now try to use it in this state. Nautilus crashes.
This fix few crashes reported downstream on distros that uses
this extension.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Currently if the view is resized, the column name is resized as well
given that use ellipsization allowing the column to become unreadable.
To avoid that, use width-chars property to set a desired width, but at
the same time allowing the user to resize without limits the name column
if desired.
https://bugzilla.gnome.org/show_bug.cgi?id=732004
|
| | |
|
| |
|
|
|
|
|
|
|
| |
When destroying window and closing all slots, the closing
of the active slot will trigger activation of next free slot,
we don't want to be activating slots as part of
'closing all slots' logic.
Fixes bug 741952
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In commit ae4d4960 we introduced a regression that a new window was
openned if both --no-default-window and --force-desktop options were
used.
To avoid that, activate those options before actually skipping the
activate of the application if --no-default-window option is provided.
The application nornally would exit if --no-default-window is provided
and the show-desktop-window is not activated, but, we rely on a the
detail that activating the open-desktop action when --force-desktop is
provided as a option, creates a new window, which makes the application
keep alive.
https://bugzilla.gnome.org/show_bug.cgi?id=741166
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now we were using --no-default-window in cases when we wanted to
manage the icons on the desktop, which is the most common use case of
this setting.
The problems were:
- When using --no-default-window for the first inscante, the user
couldn't open a new window of nautilus, since the only window allowed
was the desktop one in the first instance. The code was just early
returning in activate if the private setting of the instance is set.
- When using --no-default-window for the consecutive instances after
starting nautilus without --no-default-window it was creating a new
window anyway, since the first instance doesn't have the setting set in
its private and the second instance was just calling the activate of the
first instance. For instance that was happening when the user
activate/deactivate the show-desktop-icons gsetting, since the
nautilus-autostart desktop file was running nautilus
--no-default-window, but the first instance was a instance withouth the
--no-default-window.
So the solution for both cases is avoiding calling activate if the
--no-default-window is an arggument, instead of a private setting of the
instance.
To avoid calling activate we can return a value less than 0 to the
GApplication in the handle_local_options function. So if the
--no-default-window is passed as an argument, we just skip the activate
call.
Since when launching consecutive instances they take care of its own
handle_local_options they can skip as well the activate call redirected
to the first instance.
Big thanks to Ray Strode for discussion, debugging and base of this
patch, and Debarshy Ray for discussion and debugging.
https://bugzilla.gnome.org/show_bug.cgi?id=737515
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
In commit 2780ce8790fc575ea we restored the --new-window option, but at
the same time we were creating a new window for any glib option like
gapplication-service.
Instead of that, check for known application options, and if not found
any, let gapplication manage them.
https://bugzilla.gnome.org/show_bug.cgi?id=738430
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
In case of no further arguments, open home folder. Commit
4e192481 "application: minimal port to handle_local_options()"
removed this, presumably accidentally. It makes clicking the "Files"
from favorites do nothing if Nautilus is already running (and it
always is running in classic mode as it handles desktop).
https://bugzilla.gnome.org/show_bug.cgi?id=738280
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currently custom_basename_to_string uses the base name or display name
of the files for the copying and moving dialog.
In the cases of unlabeled removable drives, the name is a code, showing
in the dialog a not very friendly name.
gtkplacessidebar and nautilus-pathbar uses the mount name retrieved by
g_mount_name if available.
Use that fir the operations dialogs as well to display a more friendly
name to the user and to be consistent with the sidebar and pathbar name.
https://bugzilla.gnome.org/show_bug.cgi?id=738087
|
| |
|
|
|
|
|
| |
Not setting it can lead to very wide windows, because gtk doesn't
enforce a maximum window size anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=732117
|
| |
|
|
|
|
|
| |
I think this is the third time I've changed this. The sidebar keeps
getting bigger. We might need to compute this dynamically when it's
unset, to ensure four columns of results regardless of theme or filename
length.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Don't SIGSEGV when changing any of the three combo boxes in the
preferences' Display tab. This issue existed since commit d8a8ab3.
https://bugzilla.gnome.org/show_bug.cgi?id=728503
|
| |
|
|
|
|
| |
Or it won't follow the window size when resizing.
https://bugzilla.gnome.org/show_bug.cgi?id=728637
|
| |
|
|
|
|
|
| |
Or we'll possibly eat the event for the entry itself, which will have
bad consequences to the state tracking of editable GtkCellRendererText.
https://bugzilla.gnome.org/show_bug.cgi?id=732513
|
