After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 745575 - "Make Link" Option Does Not Exist in Context Menu
"Make Link" Option Does Not Exist in Context Menu
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Cut Copy Paste Undo
3.15.x
Other Linux
: Normal normal
: 3.20
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 759093 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-03-04 03:20 UTC by Antoine Saroufim
Modified: 2017-07-24 20:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch for updating existing paste functions to handle pasting links (11.04 KB, patch)
2015-12-22 10:20 UTC, Razvan Chitu
none Details | Review
Patch for adding a preference checkbox for enabling paste link (4.15 KB, patch)
2015-12-22 10:21 UTC, Razvan Chitu
none Details | Review
Patch for refactoring create links action (11.93 KB, patch)
2015-12-22 13:09 UTC, Razvan Chitu
none Details | Review
Updated patch for adding a preference checkbox for enabling paste link (3.96 KB, patch)
2015-12-22 13:10 UTC, Razvan Chitu
none Details | Review
Revised patch for refactoring create links action (11.96 KB, patch)
2015-12-22 14:20 UTC, Razvan Chitu
committed Details | Review
Revised patch for adding a preference checkbox for enabling paste link (4.07 KB, patch)
2015-12-22 14:20 UTC, Razvan Chitu
committed Details | Review
files-view: formatting fixes (1.68 KB, patch)
2015-12-22 14:37 UTC, Carlos Soriano
committed Details | Review
files-view: disable create link if clipboard empty (2.57 KB, patch)
2015-12-23 09:38 UTC, Razvan Chitu
committed Details | Review
files-view: add create link menu item for selected files (5.73 KB, patch)
2015-12-23 21:42 UTC, Razvan Chitu
none Details | Review
files-view: add create link menu item for selected files (7.42 KB, patch)
2015-12-24 15:02 UTC, Razvan Chitu
committed Details | Review

Description Antoine Saroufim 2015-03-04 03:20:30 UTC
I am not sure if this is the way it is designed or if it wasn't intentional but there is no option to make a link to a file or folder in Nautilus 3.15.90
Comment 1 jeremy9856 2015-10-24 05:47:15 UTC
I agree. We should have a way to make links in GUI. Right click -> Make Link? 
I had to search on Google to find out how to do it!
Comment 2 Carlos Soriano 2015-10-24 09:39:40 UTC
(In reply to jeremy9856 from comment #1)
> I agree. We should have a way to make links in GUI. Right click -> Make
> Link? 
> I had to search on Google to find out how to do it!

why it's your use case?
Comment 3 Carlos Soriano 2015-10-24 09:39:50 UTC
what*
Comment 4 jeremy9856 2015-10-24 09:49:54 UTC
I used to create some links in my /home folder to files that are on my /Data partition to acces them more easily without moving them.

Sometimes I also create links on the desktop, again to acces them more easily without moving them. A simple Meta + D (Show Desktop) and you have the file you need.

There is also this Google+ post from Michael Heyns that indicate that he look in context menu, like everybody will do, to find the option and can't find it.

https://plus.google.com/+MichaelHeyns/posts/iJ4R6mwAtaF
Comment 5 Daniel Preston 2015-10-24 10:03:50 UTC
I make symlinks to ~/Copy/something folders to synchronize files that are outside the Copy folder. I believe the situation is similar with other sync solutions.

I also make links if I want an easier access to something, but I don't use this something often enough to warrant a bookmark in Nautilus.

And I used it to work around SpaceChem bug - I symlinked "zachtronics industries" and "Zachtronics Industries" folders (and similarly its subfolders).
Comment 6 Michael Heyns 2015-10-24 10:33:31 UTC
I recently discovered the awkward middle-click drag-drop context menu. Not all input devices have a middle-click (touch & laptop touchpads) and the right-click context menu is intuitively the first place a user would look for functions like copy/paste/link/delete.

A "Paste link.." option seems appropriate for a file manager's context menu.
Comment 7 Carlos Soriano 2015-10-24 13:50:17 UTC
So far I gather two use cases that were actually already reported in a old bug report for the same reason. However I think both of those case uses use symlink as a wrong solution:
1- Cloud providers. What they need to do is allow to synchronize any folder, not rely on you making use of a niche filesystem thing that is difficult to understand. Also is our (DE, Linux) fault to not provide a way for them to work across desktops, but I'm working to improve that.
2- For accesing data in a different filesystem. That's what bookmarks are for. Is bookmarks not enough for you? What is wrong with them for your case?
Comment 8 jeremy9856 2015-10-24 14:28:12 UTC
You mean bookmarks in Nautilus right ? I just tested it and it seems that it's only for folders. I use the links for files, not folders, so it's not really the same thing. 

The links are really convenient, you can organize them as you want, where you want and make as many as you want. You can have them on the desktop for the fastest access (again Meta + D). It's a really powerful feature of Linux.
Comment 9 Michael Heyns 2015-10-24 15:25:39 UTC
Niche filesystem thing? Symbolic links are a fundamental feature of *nix operating systems. Correct me if I'm wrong but it's pretty universal. Would it not be considered a basic file management feature?

Cloud providers serve a higher purpose of synchronization and backups, in my opinion. One could achieve the same goal by making use of symlinks, along with other stuff, if you really wanted to. Luckily, these days you don't need to but this doesn't make them obsolete.

Bookmarks are quick convenience for the user's navigational purposes and are located in a single UI space. Symlinks, can be spread across the filesystem hierarchy and are used for a number of things ranging from navigation to being used transiently by other processes. 

It's difficult asking for use cases on something as simple as a shortcut. It's a basic tool. The question should be how to empower the user with the given tool efficiently without disrupting the current models. 

In this case I would propose a folder context menu option (after item is copied) underneath 'Paste' to the tune of 'Paste Link'. I wouldn't suggest adding a 'Make Link...' in the item context menu, as it's already rather crowded. (Personally I feel the 'Copy/Move to...' isn't needed either if navigation is efficient enough)
Comment 10 Daniel Preston 2015-10-24 16:02:33 UTC
> What they need to do is allow to synchronize any folder.
But they don't. That's why a lot of people use symlinks even on Windows. In fact for Copy it's an official way to sync a different folder. (On Windows you can also use shortcuts.) See https://techlib.barracuda.com/copy/syncotherfolders

> That's what bookmarks are for. What is wrong with them for your case?
Currently I have 3 bookmarks for the things I use often. (Out of curiosity I just tried having six and they took too much space - a scrollbar appeared. When maximized Nautilus can fit 8 bookmarks on my screen before the scrollbar appears - if no external drives are connected, that is.) I don't want to litter the bookmark bar with stuff that I rarely use. For example I have a symlink to "/mnt/Windows/Users/User/Source/Repos/Treemap", but I don't use it too often so bookmark would be an overkill.

So some people definitely want it (like me), some don't (like you) and some are indifferent. Why not make it configurable then? For example by making it an extension - just like the "open terminal here" extension.

BTW I agree with Michael Heyns. I have never used 'Copy/Move to...' or 'E-mail...' in my life. I would be happy if these were removed. But I'm pretty sure there are people who use them daily and they would be very upset if these menu items disappeared. So configurability again...
Comment 11 Isaque Galdino 2015-10-26 13:36:25 UTC
(In reply to Carlos Soriano from comment #7)
> why it's your use case?

not specific use case, but if the OS supports it why to prevent users from using it? links are already there in the middle-click mouse button, but that is not what regular users do.

Just now I though about when I was in my MBA classes I used to tag files related to some subject using links, i.e. I created a folder named HR and linked there all docs related to that even from different disciplines.

I have documents, basically PDFs that I tag for my kids and categories. I have a folder called Expenses, with well, all expenses and I have folders for kid's school payments and folder for year's month, like this:
- expenses
-- 201501
--- kid1 school 201501
--- kid2 school 201501
--- water service 201501
--- energy service 201501
-- school
--- kid1 school 201501
--- kid1 school 201502
--- ...
--- kid2 school 201501

thanks.
Comment 12 Isaque Galdino 2015-10-26 13:40:12 UTC
(In reply to Michael Heyns from comment #9)
> crowded. (Personally I feel the 'Copy/Move to...' isn't needed either if
> navigation is efficient enough)

I disagree. Copy/Move to... are what I use the most.
Comment 13 Carlos Soriano 2015-10-26 15:36:07 UTC
So far I gathered these points:
Bookmarks are not enough because:
- they doesn't refer to specific files
- sidebar can be crowed quick

So I think what we can do is fix point 1 and allow bookmarks for files.
And for point 2, I don't have a good solution to be honest. Browsers also have this problem and they "fixed" it by having folders of bookmarks, which is kind of symbolic links in your usual folders.

So answering some questions.

> Niche filesystem thing? Symbolic links are a fundamental feature of *nix operating systems. Correct me if I'm wrong but it's pretty universal

Yes, but not a very understandable concept. As you may know some people in Windows systems tried to uninstall a program deleting the shortcut, at least I saw it several times :) . Maybe "niche" was not the correct word, as my English is not the best.

> But they don't. That's why a lot of people use symlinks even on Windows.

It's their fault... (but as I said it's also our fault to not providing a good support for them, but we are working already on that)

> Why not make it configurable then? For example by making it an extension - just like the "open terminal here" extension.

Configurable in nautilus? Well I have this discussion with hundreds of items/options, as you may guess this kind of bug reports with hundred of different things are a normal thing, so basically configuration is provided if worth it enough.

BUT, as you said, extension is perfectly fine! It's not default nautilus, you can go crazy there and I actually would like to have an extension with this!

> not specific use case, but if the OS supports it why to prevent users from using it? 
If you refer to why not put a right click menu item, the reason is already provided. We could add a right click menu for every entry in files info and more things... we tried to keep the rigth click menu controlled.
However shorcuts with the keyboard or mouse actions are not crowing the menu, so they are perfectly fine and they exist already in nautilus.

> BTW I agree with Michael Heyns. I have never used 'Copy/Move to...' or 'E-mail...'

As you may guess, part of my job is gather who use it and who doesn't, and believe me this is used much more than symlinks. Sadly I don't have a good way to show it to you, as is more just listening people and talking with designers (they have experience and user testings).

Conclusion is:
I still think symslinks are used mostly to workaround other things, which we are working on already or which I think we can improve. Why don't "just use symlinks"? Because the same reason, I think is a bad solution for the use cases we are talking about. However, you can still use them with shortcuts or mouse actions, just that crowing the menu with it imho doesn't worth it (but my personal opinion can evolution of course, and I talk with designers and other devs as well of course).

Let's try to fix the use cases we were talking about and let's see how it goes.
Comment 14 jeremy9856 2015-10-27 08:31:28 UTC
I think that allowing bookmarks for files in Nautilus is a good idea. It doesn't replace the symlinks at all and it's absolutely not the same thing but it's a nice and logical feature. Maybe allowing to make folders of bookmarks can be interesting too?

What I really don't understand is why "Open a Terminal" and "Make a Link" are not in the right click menu by default. On Linux the Terminal is so powerful and so useful. "Open a Terminal" shouldn't be an extension but a built in feature. It's the same for "Make a Link" it is really powerful and so useful. For me, and I think a lot of people, these 2 items have their place in the right click menu just as "Copy/Paste", "Rename". Moreover I think they deserve a lot more than "email" to be in the right click menu.

If we really can't have this in the right click menu, it's not that bad because we have the terminal extension and we can make symlinks with the mouse. At least we should have an extension to add "Make a Link" in the right click menu even if I really want "Open a Terminal" and "Make a Link" by default in the right click menu.

As a side note, Carlos, did you see my comments on this https://bugzilla.gnome.org/show_bug.cgi?id=749334 ?

Thank you
Comment 15 Casey Jao 2015-10-29 20:10:51 UTC
(In reply to Carlos Soriano from comment #2)
> (In reply to jeremy9856 from comment #1)
> > I agree. We should have a way to make links in GUI. Right click -> Make
> > Link? 
> > I had to search on Google to find out how to do it!
> 
> why it's your use case?

Say one is applying for jobs, and collects the required documents for each employer its own folder. While various employers may ask for different sets of documents, some documents, like the resume, are common to all employers. Linking to a central copy of those common documents lets one easily propagate edits to each folder.
Comment 16 jeremy9856 2015-11-09 17:41:06 UTC
So, Carlos, can we have this little but very useful feature please ?
Thank you
Comment 17 Carlos Soriano 2015-11-10 09:28:28 UTC
(In reply to jeremy9856 from comment #16)
> So, Carlos, can we have this little but very useful feature please ?
> Thank you

My last comment is: "Let's try to fix the use cases we were talking about and let's see how it goes." and still applies.
However adding use cases here or reasons why it should be there is always good, for example what comment 15 did, I don't have a idea how to "fix" that use case, only idea is with tags, but not sure how it would work.
Comment 18 Casey Jao 2015-11-13 03:28:06 UTC
(In reply to Carlos Soriano from comment #17)

> However adding use cases here or reasons why it should be there is always
> good, for example what comment 15 did, I don't have a idea how to "fix" that
> use case, only idea is with tags, but not sure how it would work.

What was wrong with the previous "Make link" context menu option? Windows lets you create shortcuts. OS X lets you make aliases.
Comment 19 jeremy9856 2015-11-19 00:11:00 UTC
(In reply to Carlos Soriano from comment #17)
> I don't have a idea how to "fix" that use case, only idea is with tags, but not sure how it would work.
The thing is there is nothing to "fix". It already have been fixed long time ago. We have some use cases, manage our files, and we have some solutions for these use cases, Nautilus > File system > Links. The only thing to improve is Nautilus to simplify the link creation. 

If for each "old" feature you think that we can be doing it differently we should not use GNU/Linux, it's old, and build something different that do the same thing, from scratch. But when we have that shiny new thing that work we will think that we can be doing it differently and again build everything from scratch. That's not really efficient.

I love innovation but not when it's useless. Or at least add back the "Make link" context menu option and work on something aside if you want and if, and only if, it's better then replace the old feature.
Comment 20 Carlos Soriano 2015-11-19 10:22:19 UTC
(In reply to jeremy9856 from comment #19)
> (In reply to Carlos Soriano from comment #17)
> > I don't have a idea how to "fix" that use case, only idea is with tags, but not sure how it would work.
> The thing is there is nothing to "fix". It already have been fixed long time
> ago. We have some use cases, manage our files, and we have some solutions
> for these use cases, Nautilus > File system > Links. The only thing to
> improve is Nautilus to simplify the link creation. 
> 
> If for each "old" feature you think that we can be doing it differently we
> should not use GNU/Linux, it's old, and build something different that do
> the same thing, from scratch. But when we have that shiny new thing that
> work we will think that we can be doing it differently and again build
> everything from scratch. That's not really efficient.
> 

I disagree with this.

> I love innovation but not when it's useless. Or at least add back the "Make
> link" context menu option and work on something aside if you want and if,
> and only if, it's better then replace the old feature.

This is true, we should not replace something if we don't have a good enough alternative. In this case in my opinion we don't, and a clear example is comment 15. So I will rethink this.
Comment 21 jeremy9856 2015-11-19 10:38:06 UTC
(In reply to Carlos Soriano from comment #20)
> This is true, we should not replace something if we don't have a good enough
> alternative. In this case in my opinion we don't, and a clear example is
> comment 15. So I will rethink this.
Does this mean that you will add back "Make link" context menu option and replace it if/when you have something better ?
Comment 22 Carlos Soriano 2015-11-19 10:41:07 UTC
(In reply to jeremy9856 from comment #21)
> (In reply to Carlos Soriano from comment #20)
> > This is true, we should not replace something if we don't have a good enough
> > alternative. In this case in my opinion we don't, and a clear example is
> > comment 15. So I will rethink this.
> Does this mean that you will add back "Make link" context menu option and
> replace it if/when you have something better ?

No, it means I will rethink it.
Comment 23 jeremy9856 2015-11-19 10:44:55 UTC
Ok but please, at least, don't remove the Ctrl+Shift+Move thing to create links ;)
Comment 24 Carlos Soriano 2015-11-19 10:49:11 UTC
-> 3.20 to keep track
Comment 25 Carlos Soriano 2015-11-30 10:41:48 UTC
So following a more global question about putting some dconf options for a few items on the context menu, I think this one goes with them.

So we can follow the example of Delete Permanently in commit: https://git.gnome.org/browse/nautilus/commit/?id=0e5f6710df593de3455fe0e8b1509cdf2fb55bbe , since:
- we don't have solutions for some of its use cases.
- the code for making links is already there and not going to be removed making the maintenance cost not very high as a dconf option.
- no default UI change.

However for this one I would like to have a cleaner and better code than the one that was there before as in the commit which removed it: https://git.gnome.org/browse/nautilus/commit/?id=2a6da28db757da74316e4a8e5cb5b9d82f74edae

Also mark this bug as newcomer friendly for someone who wants to create the patch.
Comment 26 jeremy9856 2015-11-30 12:24:46 UTC
Thank you Carlos ! I hope we will have it for Gnome 3.20 ;)
Comment 27 Khurshid Alam 2015-12-19 06:40:16 UTC
Use case? 

Simple. I work with hundreds files and folders each day. Middle click-drag will simply slows me down. Where should I drag those? On a folder? On empty space (which is hard to find with very big icons and less grid width)? Most of time I end up create links for folders which I don't intend to.

And ctrl+shift dragging is even more inconvenient. First you have to press Ctrl+Shift with one hand. Then you need to select folder/files with mouse/keyboard. Then you have to drag those with mouse while pressing left mouse button.While dragging you must drag it to a empty space; if by mistake, you move mouse over to a folder, you will immediately go inside that and symlinks will be created inside that folder (probably another bug).

I think, until we have a viable option a dconf settings like that permanent delete option would be good.
Comment 28 Razvan Chitu 2015-12-22 10:20:21 UTC
Created attachment 317777 [details] [review]
Patch for updating existing paste functions to handle pasting links

I updated the current functions that handle pasting the clipboard to support pasting links to the copied files (where it is possible).
Comment 29 Razvan Chitu 2015-12-22 10:21:40 UTC
Created attachment 317778 [details] [review]
Patch for adding a preference checkbox for enabling paste link

Added a preference dialog option for enabling "Paste Link" in the context menu.
Comment 30 Carlos Soriano 2015-12-22 10:39:24 UTC
Review of attachment 317777 [details] [review]:

You reuse the backend part, so this starts to look really good.
However, don't try to use the paste action for it, instead create a new function like action_create_link and perform the required code for it there. As you can see it's actually simple since you only have to use nautilus_files_view_move_copy_items with the GDK_LINK action. If you need anything else to perform it and it's shared code with the paste action, just extract it into another function and use it from both actions code.

Also, I add some inline comments:

::: data/org.gnome.nautilus.gschema.xml
@@ +82,3 @@
       <description>If set to true Nautilus will show a delete permanently context menu item to bypass the trash.</description>
     </key>
+    <key type="b" name="show-paste-link">

show-create-link, it's not pasting but actually creating new link. fwiw it's how it was called before.

@@ +83,3 @@
     </key>
+    <key type="b" name="show-paste-link">
+      <default>true</default>

default to false

@@ +84,3 @@
+    <key type="b" name="show-paste-link">
+      <default>true</default>
+      <summary>Whether to show a context menu item to paste links to copied files</summary>

create link

@@ +85,3 @@
+      <default>true</default>
+      <summary>Whether to show a context menu item to paste links to copied files</summary>
+      <description>If set to true Nautilus will show a paste link context menu item to paste links to the copied files</description>

create link

::: src/nautilus-files-view.c
@@ +2434,3 @@
+    NautilusFilesView *view;
+    gboolean symbolic;
+} PasteData;

This won't be need with the approach I proposed

@@ +6211,3 @@
         selection_contains_recent = showing_recent_directory (view);
         selection_contains_search = nautilus_view_is_searching (NAUTILUS_VIEW (view));
+        selection_contains_cut = clipboard_info != NULL? clipboard_info->cut : TRUE;

can_create_link = clipboard_info != NULL? !clipboard_info->cut : FALSE;
Comment 31 Carlos Soriano 2015-12-22 10:42:03 UTC
Review of attachment 317778 [details] [review]:

It needs to be renamed following the previous proposal. Also, the title of the commit message is too long, how about:
"preferences: add preference for create a link in context menu"

::: libnautilus-private/nautilus-global-preferences.h
@@ +165,3 @@
 /* Context menu options */
 #define NAUTILUS_PREFERENCES_SHOW_DELETE_PERMANENTLY "show-delete-permanently"
+#define NAUTILUS_PREFERENCES_SHOW_PASTE_LINK "show-paste-link"

This needs to be in the previous patch, if not it won't work
Comment 32 Razvan Chitu 2015-12-22 13:09:50 UTC
Created attachment 317782 [details] [review]
Patch for refactoring create links action

Refactored as suggested.
Comment 33 Razvan Chitu 2015-12-22 13:10:40 UTC
Created attachment 317783 [details] [review]
Updated patch for adding a preference checkbox for enabling paste link

Refactored as suggested.
Comment 34 Carlos Soriano 2015-12-22 13:38:58 UTC
Review of attachment 317782 [details] [review]:

The commit message still says "pasting links". Also it needs reordering to clearly say what's the important part of the change, it's not the refactoring, but the fact that you added a menu item for it and a gsetting. Also we don't mention the reasons we are implementing it, which are stated in this bug report, but it's nice to have the background of the change also in the commit message, keeping it as short as possible.

Something along the lines of:
files-view: add optional menu item for creating links

The menu item for creating links was removed in previous
versions of nautilus since it exposes a concept of the
file system that it's not really clear.
However, we don't have a working solution yet for the use cases
that crating links is workarounding, so we didn't remove the
functionality altogether.

We were allowing to create links with a shortcut and with
the middle button while performing a drag and drop operation.
However, some users would need to use a context menu action
instead of a drag and drop operation, which usually is less
convenient and prone to errors.

Since this is demanded, implement the menu action for it and
add a gsetting preference to show it in the context menu for
those users who will like to have it there.

Also the new implementation uses the code that is already used
for other operations, improving the implementation compared
to the previous one.

In an upcoming patch we add the UI for the preference dialog.



ok, and also some inline comments:

::: data/org.gnome.nautilus.gschema.xml
@@ +84,3 @@
+    <key type="b" name="show-create-link">
+      <default>false</default>
+      <summary>Whether to show a context menu item to create links to copied files</summary>

from copied files

@@ +85,3 @@
+      <default>false</default>
+      <summary>Whether to show a context menu item to create links to copied files</summary>
+      <description>If set to true Nautilus will show a paste link context menu item to create links to the copied files</description>

if set to true Nautilus will show a create link context menu item to create links from the copied files

::: src/nautilus-files-view.c
@@ +2404,2 @@
 static void
+move_copy_clipboard_data (NautilusFilesView *view,

handle_clipboard_action

@@ +2434,3 @@
+        GdkDragAction action;
+
+        action = nautilus_clipboard_monitor_is_cut (nautilus_clipboard_monitor_get ()) ? GDK_ACTION_MOVE : GDK_ACTION_COPY;

too long, do it multiline:
action = nautilus_clipboard_monitor_is_cut (nautilus_clipboard_monitor_get ()) ?
         GDK_ACTION_MOVE : GDK_ACTION_COPY;

@@ +6209,3 @@
         gboolean selection_contains_recent;
         gboolean selection_contains_search;
+        gboolean selection_contains_cut;

as said previously, rename it to can_link_files and move it together with the other can_*

@@ +6243,3 @@
         selection_contains_recent = showing_recent_directory (view);
         selection_contains_search = nautilus_view_is_searching (NAUTILUS_VIEW (view));
+        selection_contains_cut = nautilus_clipboard_monitor_is_cut (nautilus_clipboard_monitor_get ());

once you rename it, you can do something like:
can_create_links = nautilus_clipboard_monitor_is_cut (nautilus_clipboard_monitor_get () &&
!is_read_only && !selection_contains_recent

@@ +6476,3 @@
                                              "new-folder");
         g_simple_action_set_enabled (G_SIMPLE_ACTION (action), can_create_files);
+

this is unrelated change.

::: src/resources/ui/nautilus-files-view-context-menus.ui
@@ +20,3 @@
     <section>
       <item>
+        <attribute name="label" translatable="yes">Paste _Link</attribute>

Create link
Comment 35 Carlos Soriano 2015-12-22 13:42:38 UTC
Review of attachment 317783 [details] [review]:

The commit message needs a description. Something along the lines of:

preferences: add preference for create a link in context menu

Following the "Delete Permanently" option, add a preference to show
the context menu item for creating links.

::: src/resources/ui/nautilus-preferences-dialog.ui
@@ +154,3 @@
+                            <child>
+                              <object class="GtkCheckButton" id="show_create_link_checkbutton">
+                                <property name="label" translatable="yes">Show context menu item to create links to copied files</property>

from copied files
Comment 36 Razvan Chitu 2015-12-22 14:20:01 UTC
Created attachment 317785 [details] [review]
Revised patch for refactoring create links action

Modified as suggested.
Comment 37 Razvan Chitu 2015-12-22 14:20:54 UTC
Created attachment 317786 [details] [review]
Revised patch for adding a preference checkbox for enabling paste link

Modified as suggested.
Comment 38 Carlos Soriano 2015-12-22 14:28:13 UTC
Review of attachment 317785 [details] [review]:

This one looks excellent now, I will fix the small nitpicks in a upcoming patch, so no worries.
Thanks for the work!

::: src/nautilus-files-view.c
@@ +2435,3 @@
+
+        action = nautilus_clipboard_monitor_is_cut (nautilus_clipboard_monitor_get ()) ?
+                GDK_ACTION_MOVE : GDK_ACTION_COPY;

missing space

@@ +6265,3 @@
+        can_link_files = (!nautilus_clipboard_monitor_is_cut (nautilus_clipboard_monitor_get ()) &&
+                          !selection_contains_recent &&
+                          !is_read_only);

not need for enclosing parentheses
Comment 39 Carlos Soriano 2015-12-22 14:28:56 UTC
Review of attachment 317786 [details] [review]:

LGTM thanks!
Comment 40 Carlos Soriano 2015-12-22 14:37:46 UTC
Created attachment 317787 [details] [review]
files-view: formatting fixes

For the previous patch.
Comment 41 Carlos Soriano 2015-12-22 14:42:15 UTC
Attachment 317787 [details] pushed as eb55448 - files-view: formatting fixes
Comment 42 jeremy9856 2015-12-22 14:49:29 UTC
Razvan Chitu, thank you very much !
Comment 44 Razvan Chitu 2015-12-22 18:03:07 UTC
(In reply to jeremy9856 from comment #42)
> Razvan Chitu, thank you very much !

No problem! Happy to be of help.
Comment 45 Razvan Chitu 2015-12-23 09:38:40 UTC
Created attachment 317810 [details] [review]
files-view: disable create link if clipboard empty

This fixes an oversight in commit 0eef086.
Comment 46 Carlos Soriano 2015-12-23 09:42:47 UTC
Review of attachment 317810 [details] [review]:

LGTM thanks!
Comment 47 Carlos Soriano 2015-12-23 09:45:12 UTC
Attachment 317810 [details] pushed as 37053e7 - files-view: disable create link if clipboard empty
Comment 48 Khurshid Alam 2015-12-23 09:58:14 UTC
The implementation seems weird to me. Why do I have to copy it first to create links? That's two clicks. Is there any mockup/design blueprint that adheres this idea? OSX, Solaris, BSD none does that.
Comment 49 Carlos Soriano 2015-12-23 10:16:36 UTC
How do you link files to a different location if not?
Comment 50 Razvan Chitu 2015-12-23 21:42:33 UTC
Created attachment 317829 [details] [review]
files-view: add create link menu item for selected files

The menu item for this feature was removed in previous versions of nautilus.
A context menu item for creating links from copied files was added, but some
users prefered to create links from selected files.

Since this is demanded, implement the menu action for it and use the gsetting
added in the previous commits.
Comment 51 Carlos Soriano 2015-12-24 14:51:44 UTC
Review of attachment 317829 [details] [review]:

Just small nitpicks, otherwise code and commit message looks good to me, congrats!

::: src/nautilus-files-view.c
@@ +5368,2 @@
 static void
+action_create_links_inplace (GSimpleAction *action,

in_place, use full words. Rename also the action etc.

@@ +6446,3 @@
+                                     can_copy_files &&
+                                     can_create_files &&
+                                     settings_show_create_link);

now that we have two links actions, it will be confusing the can_link_files to not be used here. So can you also simply rename can_link_files to can_link_from_copied_files?
Comment 52 Razvan Chitu 2015-12-24 15:02:10 UTC
Created attachment 317862 [details] [review]
files-view: add create link menu item for selected files

The menu item for this feature was removed in previous versions of nautilus.
A context menu item for creating links from copied files was added, but some
users prefered to create links from selected files.

Since this is demanded, implement the menu action for it and use the gsetting
added in the previous commits.
Comment 53 Carlos Soriano 2015-12-24 15:06:41 UTC
Review of attachment 317862 [details] [review]:

excellent, thanks!
Comment 54 Carlos Soriano 2015-12-24 15:09:30 UTC
Comment on attachment 317862 [details] [review]
files-view: add create link menu item for selected files

pushed as https://git.gnome.org/browse/nautilus/commit/?id=a3a7ac81b77fd65b8d3902aea8e00d2da4ad9f6c
Comment 55 Ernestas Kulik 2017-07-24 16:33:13 UTC
*** Bug 759093 has been marked as a duplicate of this bug. ***