[for discussion] drag-n-drop behavior in bookmarks section of sidebar: what to do?

[monsta]

@stefano-k @flexiondotorg @NiceandGently @sunweaver @willysr @infirit

Some history:

1. Some time ago, drag-n-drop of files to the bookmarked folders didn't work (drag and drop to bookmarks in side pane does not work #345).
2. Later it has been fixed by @NiceandGently in 910b914.
3. I've filed this Debian bug report, asking to make a patch for Debian out of that commit.
4. During the patch testing, @sunweaver found out that adding new folders via drag-n-drop to bookmarks list does not work anymore.

The choice:

• if we revert 910b914, we'll be able to add new folders to bookmarks via drag-n-drop. Like it's currently done in Caja 1.8: drag some folder to the empty space in bookmarks section, then a horizontal line appears, then you can drop the folder there, and it will become a new bookmark. But we'll also reintroduce drag and drop to bookmarks in side pane does not work #345 back.
• if we leave it as is, we'll be able to drag-n-drop files into some existing bookmarked folder, but won't be able to add new folders to bookmarks via drag-n-drop.

Current situation:

The patch isn't accepted in Debian (and Ubuntu), and we have Caja 1.8 there, so currently #345 affects these distros.
Once 1.10 makes it there, #345 will be fixed, but the ability to add new folders to bookmarks via drag-n-drop will be lost.

Upstream situation:

@NiceandGently found out that Nautilus now has both behaviors - that is, it allows both drag-n-drop of files into the existing bookmarks and adding new folders to bookmarks. It shows which action will be done so the user could distinguish between them and choose the one he wants.
It had been implemented somewhere between 3.8 and 3.10.

Bad news: during the development of Nautilus 3.10, they made their own GtkPlacesSidebar widget and switched Nautilus to it. So we don't have any upstream code to cherry-pick - we need to analyze GtkPlacesSidebar code and try to implement the same logic in Caja to fix our issue. This is not easily and quickly done...

Nemo, the Cinnamon file manager, also has both behaviors working, but again, the amount of changed code there is too big (see linuxmint/nemo@f96357d for example), and picking something we need from it is not a quick job.

So what should we do here?
Should we consider the current 1.10 behavior a regression and revert it, or should we leave it as is and tell the users that it's a new feature? 😆

Personally, I'm inclined to do the latter.
First, drag-n-drop of files to bookmarks should be fixed. If it doesn't work, there's no other quick way to do the same thing.
Second, Caja already has a quick way to add a new bookmark (via menu or Ctrl-D shortcut), so having an additional drag-n-drop action that does the same thing isn't that necessary.

[monsta]

Just thought that @clefebvre might be interested in this as well since 1.10 is planned for Mint soon :)

[raveit65]

I aggree with Monsta, and i would prefer not to revert the commit.
It's bit bad to explain users why a old fixed bug happens again.
And with the nemo commit we have chance to implement both behaviours.
And i don't see that someone build 1.10 in debian jessie the next time.
Also it is possible to revert the commit during package build if this is needed.
On the other hand fedora is much flexible and i can/will use this commit as patch again, what i did since a year.
I can't implement old fixed bugs again.
During this time i never received a report at bugzila that a user complains about missing option to create a bookmark with drag&drop.

[raveit65]

here are all links from nemo given by mtwebster
linuxmint/nemo@f18c4dd
linuxmint/nemo@473e959

[flexiondotorg]

The consensus was to revert 910b914 for the 1.10.1 release. Fedora will carry a patch in the meantime.

[sunweaver]

For the record, from yesterday's chat on IRC:

14:22 < sunweaver> I never tried to copy files into bookmarks folders since the beginning of GNOMEv2
14:23 < sunweaver> but used drag'n'drop for bookmark folders regularly.
14:23 < sunweaver> so for me that commit is zero-gain and 100%-functionality loss.
14:23 < raveit65> sunweaver, as i said for me it's no prob to revert it, i can use the commit as patch for fedora, i can't introduce this regression for fedora again
14:24 < sunweaver> but I will ship the change in 1.10 and wait for community feedback.
14:24 < sunweaver> hmmm...
14:24 < sunweaver> so in Fedora someone complained about the lack of being able to copy files? Interesting.
14:25 < sunweaver> I only know about my usage pattern regarding bookmarks.
14:25 < raveit65> sunweaver, i fixed a fedora bug with that commit in the past, so i can't revert it
14:25 < sunweaver> So no clue if others will complain...
14:25 < raveit65> but i can use a patch
14:25 < raveit65> np
14:27 < sunweaver> I can also unpatch that commit in Debian, but I,d rather not want to ship a Debian specific patch if it can be avoided.
14:27 < sunweaver> no clue on how to proceed in upstream...

... So I am happy to see the previous functionality of caja bookmarks drag'n'drop continued...

[raveit65]

@sunweaver
I have expected that you post your point of view not a paste from our discussion.
Honestly, you gave only one agument.

14:23 < sunweaver> so for me that commit is zero-gain and 100%-functionality loss.

[monsta]

In the meanwhile, @flexiondotorg reverted the commit...