search

linuxmint / muffin

The window management library for the Cinnamon desktop (libmuffin) and its sample WM binary (muffin)
GNU General Public License v2.0
197 stars 93 forks source link

Drag'n'Drop between two snapped windows does not work in Nemo 5.4.3 #659

Closed GuidoBartoli closed 1 month ago

GuidoBartoli commented 2 years ago 
 * Nemo 5.4.3 version 
 * Issue with desktop and windowed Nemo

             ...-:::::-...                 guido@SATURN 
          .-MMMMMMMMMMMMMMM-.              ------------ 
      .-MMMM`..-:::::::-..`MMMM-.          OS: Linux Mint 21 x86_64 
    .:MMMM.:MMMMMMMMMMMMMMM:.MMMM:.        Host: Intense-PC2 (IPC2) 1.x 
   -MMM-M---MMMMMMMMMMMMMMMMMMM.MMM-       Kernel: 5.15.0-46-generic 
 `:MMM:MM`  :MMMM:....::-...-MMMM:MMM:`    Uptime: 2 hours, 26 mins 
 :MMM:MMM`  :MM:`  ``    ``  `:MMM:MMM:    Packages: 2147 (dpkg) 
.MMM.MMMM`  :MM.  -MM.  .MM-  `MMMM.MMM.   Shell: bash 5.1.16 
:MMM:MMMM`  :MM.  -MM-  .MM:  `MMMM-MMM:   Resolution: 1920x1200 
:MMM:MMMM`  :MM.  -MM-  .MM:  `MMMM:MMM:   DE: Cinnamon 5.4.10 
:MMM:MMMM`  :MM.  -MM-  .MM:  `MMMM-MMM:   WM: Mutter 
.MMM.MMMM`  :MM:--:MM:--:MM:  `MMMM.MMM.   WM Theme: Mint-Y 
 :MMM:MMM-  `-MMMMMMMMMMMM-`  -MMM-MMM:    Theme: Mint-Y-Dark [GTK2/3] 
  :MMM:MMM:`                `:MMM:MMM:     Icons: Mint-Y-Dark [GTK2/3] 
   .MMM.MMMM:--------------:MMMM.MMM.      Terminal: gnome-terminal 
     '-MMMM.-MMMMMMMMMMMMMMM-.MMMM-'       CPU: Intel i7-4600U (4) @ 3.300GHz 
       '.-MMMM``--:::::--``MMMM-.'         GPU: Intel Haswell-ULT 
            '-MMMMMMMMMMMMM-'              Memory: 3734MiB / 7619MiB 
               ``-:::::-``

Issue

Using drag'n'drop to move or copy items from one window to another does not work, even using CTRL or SHIFT keys to force copy or move respectively.

Steps to reproduce

  1. Open two Nemo windows of two different folders
  2. Drag and drop one item from the first to the second window

Expected behaviour

The item should be copied or moved as it should (Linux Mint 20.3 did not have this issue).

Other information

I attached a screencast of this behavior on my PC. https://user-images.githubusercontent.com/16103676/184610644-24604e5f-31fa-466a-b84f-497c674fcbd3.mp4

GuidoBartoli commented 2 years ago

UPDATE: Cutting and pasting the item from the first window to the second works and also dragging and dropping it back from the second to the first, too. Drag and drop from the first to the second does not work yet.

Here is another screencast of this thing: https://user-images.githubusercontent.com/16103676/184636284-cc7a0691-0a13-4288-b1c9-dc7a056aa7db.mp4

mtwebster commented 2 years ago

Unable to reproduce. Can you restart nemo from a terminal and try to see if there are any errors? (Close all nemo windows first)

GuidoBartoli commented 2 years ago

I just closed all the windows and restarted Nemo from command line, the issue is still there. New screencast: https://user-images.githubusercontent.com/16103676/184640905-c8036c2b-a0d5-4aed-82d8-37278d09168f.mp4

Now I completely reboot Mint and try again...

GuidoBartoli commented 2 years ago

Ok, restarting the system solved the issue.

Anyway it was a very strange behavior of Nemo, in so many years of using Mint it had never happened to me, if it happens again, I will write it here.

Thanks

stitheridge commented 2 years ago

@GuidoBartoli I have exactly the same issue, as per your screencast (and same version of Nemo) on Linux Mint 21. I can't resolve it by restarting my machine though. Have you had this problem recur?

Key system info:

stitheridge commented 2 years ago

Update: My problem is wider. Seems I can't even drag/drop a file between folders within the same nemo window. I can Ctl-X Ctl-V fine to work around the problem (including between separate windows).

GuidoBartoli commented 2 years ago

@stitheridge To be honest, after my last comment here, sometimes has randomly happened again, but more frequently when working with network drives, I do not know if it related (Cut/Copy + Paste always works, however).

Maybe it could be a keyboard issue that the system receives an always pressed modifier key like ALT or CTRL that inhibits item dragging?

mtwebster commented 2 years ago

Can you try a different (preferably newly-created) user account to see if the issues persist there - this will narrow things down significantly.

mtwebster commented 2 years ago

Use inxi instead of neofetch (or whatever prints the ascii art), it gets in the way of seeing useful info in github issue summaries.

stitheridge commented 2 years ago

@mtwebster I created a new user account, logged in as the new user and tried drag/drop again. This time the Drag/drop between separate windows worked. It seemed to sporadically stop and start working again so I logged back out and back in (as the new user) and it worked fine consistently this time. Behaviour when logged in as my original/problematic user is still consistently failing to drag/drop between windows.

Interesting side-note: For my original/problematic user, I am seeing the drag/drop behaviour continue to fail within the same window. I have two Nemo windows open (left-hand side and right-hand side). The drag-drop behaviour between folders within the window works fine in left-hand window, but doesn't work on right-hand window.

Hope that helps.

GuidoBartoli commented 2 years ago

I add that when it happens, it occurs between Nemo panes and windows too.

mtwebster commented 2 years ago

Ok one more thing to try.. it's odd, but it's possible this isn't nemo at all -

When the problem is occurring, open up the cinnamon debugger (super-L) and click the little eyedropper in the bottom left corner.

This allows you to inspect desktop elements, including windows - as you hover different windows they'll get highlighted. I'm curious to see if maybe something invisible is obstructing the nemo windows. It's not really that likely but it could happen - just take a look around while that mode is active and see if anything seems out of place.

Another thing is, do you have any desklets enabled? Is there any correlation between their positions and the drag issue?

Lastly, can you monitor your .xsession-errors file to see if anything is printed when this stuff occurs - you can do this with:

tail -f ~/.xsession-errors

Thanks

stitheridge commented 2 years ago

@mtwebster Righto, I've managed to consistently replicate this issue now. This happens for both my regular/original user account, and the brand new one I created when I first started looking at this issue.

Steps to reproduce 1) Open two Nemo windows (refered to as A and B) 2) Snap Window A to left hand edge of screen so it takes up left half of screen 3) Snap Window B to right hand edge of screen so it takes up right half of screen 4) Observe dragging files to folders within each window and between windows works fine. 5) Snap Window B to upper-right corner so it takes up upper-right quarter of the screen 6) Observe dragging files to folders within each window and between windows works fine. 3) Snap Window B to right hand edge of screen again so it takes up right half of screen 8) Observe dragging files to folders within Window B and from Window A to Window B no longer works. Dragging from Window B to A works fine. 9) On further inspection, it seems that moving the mouse with a dragged file to the bottom-right corner or Window B causes folders in the top left to be highlighted as drop-targets. Basically there is a big X and Y offset between the mouse position and the drop target.

Re: Your debug request: 1) Cinnamon debugging: Nothing obscuring the individual elements that I can tell 2) tail -f ~/.xsession-errors: Nothing appears in the log during all the nemo interactions. 3) Desklets: I have no desklets installed.

Hope this helps.

mtwebster commented 2 years ago

Still no luck reproducing.

Can you share your desktop settings:

dconf dump /org/cinnamon/ > dconf.dump

There shouldn't be any personal info there but make sure to check in case.

Thanks

stitheridge commented 2 years ago

@mtwebster 1) I do use a 28-inch 4K monitor. I use fractional text scaling (1.6) on my main user, but not on the new user that I'm also testing with. Both user accounts have the problem. 2) I've now tried with different modes of tiling. Using mouse drag to snap to right-hand side always results in the problem. Using super-right-arrow from a non-snapped window position also results in the problem. Using any series of super-arrows to dock to right-hand-side from another snapped located causes the problem to go away. Swapping the position of the two nemo windows (via mouse drag and snap) causes the problem to be on the window now snapped to the right-hand edge. 3) Effects were enabled. Disabling didn't affect the problem. One thing I noticed is that the effects don't appear to be working at all (I never noticed until now) so disabling them made no difference to any window behaviour.

Desktop settings attached for both my main and new/test user.

dconf.new_user.dump.txt dconf.main_user.dump.txt

6630507 commented 2 years ago

I have this issue as well. I just opened a thread on the Mint user forums:

https://forums.linuxmint.com/viewtopic.php?f=47&t=384150&p=2248397&hilit=nemo#p2248397

On my machine, this problem affects only dragging from the left tiled window into the right tiled window. I can drag from the right window to the left window just fine.

I also encounter this both on local instances of Nemo and over X11 forwarding.

6630507 commented 2 years ago

UPDATE:

After I posted that I was having this issue also, I tried a suggestion from earlier in the thread. I made a new user account, and drag-and-drop worker properly with window snapping/tiling.

After creating this new account, everything also worked as expected in my normal account.

The fix/workaround has persisted across multiple reboots, and I've deleted the test account with no reversion.

dubrowgn commented 2 years ago

This is easily reproducible for me on on multiple machines. Pressing win+e, win+left, win+e, win+right, opens two nemo windows and snaps them left/right respectively. Both are open to my user's home directory. From here, I can drag-and-drop from the right window into the left, but not the other way around. Event stranger is subsequently snapping each window to the opposite side of the monitor reverses which window I'm allowed to drag-and-drop (I can still DnD right-to-left, but not left-to-right, even though the same windows have switched sides).

I'm using a 2x display scaling on a 4k monitor in both cases, but dropping back to 1x doesn't seem to have any affect. I'm running LM21, up to date. At first I thought this may have something to do with using XFS (instead of the default ext4), but the fact that behavior changes based on the position of the nemo windows makes me think this is unrelated.

On one machine where this is still happening, we have several users.

dubrowgn commented 2 years ago

After playing around with it for a while, it seems related to the position of the windows before snapping. In the following video, I can affect the drop zone by moving the window before snapping it to the right side of the screen. It looks like the drop zones are where the window used to be before snapping.

https://user-images.githubusercontent.com/1294253/200193005-7b9a2d64-f4f0-4d74-bc4f-1560259d5a59.mp4

GuidoBartoli commented 2 years ago

I also confirm that it happens to me only when windows are snapped on the screen edges.

6630507 commented 2 years ago

@stitheridge above indicated

@mtwebster I created a new user account, logged in as the new user and tried drag/drop again. This time the Drag/drop between separate windows worked. It seemed to sporadically stop and start working again so I logged back out and back in (as the new user) and it worked fine consistently this time. Behaviour when logged in as my original/problematic user is still consistently failing to drag/drop between windows.

https://github.com/linuxmint/muffin/issues/659

This matches my experience.

I created a new user account, drag-and-drop worked as expected while windows were snapped. I deleted the new account, and the fixed behavior persisted ... with occasional inconsistencies.

For example, sometimes I could drag and drop between snapped windows in one workspace, but not another.

It also seemed random whether this improved (i,e, post-new-account) behavior applied to Nemo instances running locally or over X11 forwarding.

I reported the issue here, on the community forums

https://forums.linuxmint.com/viewtopic.php?f=47&t=384150&p=2250203&hilit=nemo+tiling#p2250203

and user @spamegg may have found a related issue, which pertains to dragging/adjusting the size/boundaries of tiled/snapped windows (with screen recording); this issue I can reproduce as well:

https://github.com/linuxmint/cinnamon/issues/11169

The border/edge issue is reported by a user running AMD graphics and confirmed by a user with NVIDIA; I am running Intel integrated.

mtwebster commented 2 years ago

Okay I finally figured out how to reproduce this. I'd like to confirm the conditions I've established for when it happens.

Could you guys test the two different scenarios here and confirm their outcomes for me:

Problem SHOULD NOT occur

What's weird is I can't reproduce this in any other two-opposed-window orientations (top/bottom, corner/corner).

Thanks

dubrowgn commented 2 years ago

Problem SHOULD NOT occur

Works as expected for me.

Problem SHOULD occur

This one depends on where the second window spawns, and I'm not sure how nemo/cinnamon decides the spawn location. Sometimes the second window spawns at the expected size over the top of the left-snapped window. The issue is reproducible in this case. Sometimes, the second window spawns in the empty space to the right of the left-snapped window. The issue is NOT reproducible in this case. However, I can reproduce the issue in the second case by simply moving the window to the left before right-snapping it.

dubrowgn commented 2 years ago

I compiled nemo v5.4.3 from source, and reproduced the issue. By adding a call to printf in drag_motion_callback in nemo-icon-dnd.c, I was able to show that the drag_motion event is only received when the cursor is within the area the window occupied before being snapped to the right. The x and y values received in the event also appear to be relative to the window's previous position.

As far as I can tell, this event seems to be coming from clutter, so maybe this is actually a clutter issue?

Potentially related: https://github.com/linuxmint/muffin/issues/566

Holzkohlen commented 2 years ago

This is a weird one. I'm on Arch Linux Cinnamon 5.4.12 I can drag and drop when I dock via keyboard shortcuts. Then again only the destination seems to matter. If I tile the destination via mouse dragging it does not work, if I do it via keyboard shortcuts it works. The source does not seem to matter. But then it's only an issue on my secondary monitor. If I tile via mouse dragging on my main monitor in works. But that's not all. On my secondary monitor I works (mouse tiled) when the source is on the right and the destination on the left. Switch them around and it doesn't work. What about tabs? Tile the window to the left and I can drag and drop to another tab. Tile the window to the right and it does not work (keyboard or mouse tiling). Moving the tabs around did not affect it. I even tried this on different workspaces to see if even that affects the issue, but as far as I can tell it does not.

For me the issue is specific to tiling via mouse but ONLY on my 2nd monitor and ONLY if the destination is on the right side (the one next to my other monitor - 2nd monitor is to the left). I did wonder if it was related to the crossover between two monitors, so I quickly switch them around using nvidia-settings, but the issue was still on the 2nd monitor to the right, which was the rightmost edge of my desktop then).

But hold on, it gets better. my 2nd monitor is 21:9, what if I were to set it to 16:9 1080p and what do you know it works. This gets rid of the issue for me. Back to 21:9, it happens again. That's not all, my main monitor is 144hz while my 2nd one is 60hz. What if I were to put the main one on 60 too? You guessed it, the issue is gone. Back to 144hz and the I can't get the issue anymore. I'm assuming it will be back after a reboot. But now I do have the issue on workspace 1 (did this whole thing on workspace 2 before, where it's gone) on a fresh workspace 3 I do not have the issue either.

This is getting too weird for me. I assume that something down the line goes awry when paired with specific setups (multiple monitors, high refresh rate and aspect ratios apart from 16:9)

speich commented 2 years ago

From here, I can drag-and-drop from the right window into the left, but not the other way around.

This saved me. Since I always DnD from left to right, this bug was driving me crazy. At least now I have a work-around.

mmiller7 commented 1 year ago

I have this issue as well. I just opened a thread on the Mint user forums:

https://forums.linuxmint.com/viewtopic.php?f=47&t=384150&p=2248397&hilit=nemo#p2248397

On my machine, this problem affects only dragging from the left tiled window into the right tiled window. I can drag from the right window to the left window just fine.

I also encounter this both on local instances of Nemo and over X11 forwarding.

Oh this is bizarre!

I'm also having this problem and I didn't realize it changed depending on window position. I can't drag from left-tiled to right-tiled, I can't drag from desktop onto right-tiled.

I can drag from right-tiled to left-tiled. I can also drag from desktop to a not-snapped floating window.

I am fairly sure this used to work fine, but I don't know which update it "broke" on. I'm on Mint 21.1, Nemo 5.6.1 with a 1080P 19:9 display resolution.

Jeremy7701 commented 1 year ago

This is long standing.

When you have two panes open one of them is active, the other is inactive. You can drag & drop from the active pane only. I believe this is something to do with the way GTK handles mouse clicks. One mouse click can get swallowed to change the pane focus from inactive to active.

stitheridge commented 1 year ago

@Jeremy7701 I disagree; this issue isn't about the window being active/inactive. It is about the right-hand window using incorrect coordinates for the drop-target, different from the mouse pointer.

See the screen-recording (nemo-dnd-repro.mp4) from earlier comment here. See at 0:25 to 0:35 in the recording how folders located at the far-right on window are being highlighted as drop-targets even though the mouse-pointer is much further left. The general failure to dragndrop is simply a specific manifestation where there isn't a valid drop-target at the incorrectly-used/offset coordinates.

Jeremy7701 commented 1 year ago

OK

NintendoManiac64 commented 1 year ago

While the title says Nemo 5.4.3, it may or may not be worth noting that I think that I may have just been running into this very issue on Nemo 5.6.6 on Mint 21.1 (perhaps this is already known to not be exclusive to Nemo 5.4.3?).

GuidoBartoli commented 1 year ago

I would like to add that this behavior also occurs when the window is snapped to the right side of the screen and you try to drag'n'drop an item into the folders in the left sidebar, Nemo refuses to accept both copy and move actions.

As soon as you snap the window to the left side of the screen (or in any other position other than snapped on the right), the problem disappears and the item is correctly moved across folders to and from the sidebar, see the screen recording below (please ignore the visual glitch caused by GPU driver fllipping interfering with the screen recorder).

https://user-images.githubusercontent.com/16103676/215450750-6d5a5415-4d8f-4f9d-b307-4138be18f0a1.mp4

Maybe it's really related to the conversion of the mouse pointer coordinates when the window is on the right side of the screen?

zpangwin commented 1 year ago

On Fedora 37, Cinnamon spin and wanted to add / confirm that this is present in Nemo 5.6.2 there as well.

Nemo is hands-down my favorite file manager and I've been using it for well over a decade at this point. Figured I'd try to do a little testing on my end and here's what I've found so far. Hopefully, it's helpful rather than just more "debugging noise" ... anyway, apologies for the longish post but trying to get proper detail and not sure what is and is not useful here so here goes:

  1. As described in the original post and best documented with mtwebster's comment on Nov 7, 2022, the issue occurs with left-window-to-right-window drag-and-drop but right-to-left drag-and-drop does not appear to be impacted. Dragging to bookmarks of the right-tiled window has the same issue. However, only drags TO right-tiled windows (as opposed to top/bottom/{upper,lower}-{right,left}-corner tiled windows) seem to be impacted. As long as the drag source is from a non-right-tiled window (e.g. left-tiled, top-tiled, etc), then same-window dragging, dragging to bookmarked folders within that window, dragging to other non-right-tiled windows, and/or dragging to desktop wallpaper are NOT impacted.
  2. Interestingly, if you encounter the problem while dragging TO a right-tiled window and then change its tiling position and then change it back to a right-tiled window (e.g. Super+Up arrow to tile it to upper-right-corner followed by Super+Down arrow to undo the upper-corner tiling change), seems to fix things and the dnd operation will then work (as least it did in my testing).
  3. As noted by stitheridge on Sep 26, 2022, this seems to also impact drag-n-drop within the same window, if the window is tiled to the right. This seems to apply both when dragging to bookmarked folders (as in GuidoBartoli's comment/video immediately above this one), as well as other folders in the main view area/pane of the right-tiled window. But does NOT apply for right-to-left-window drags (or right-to-any other position besides right, including right-to-desktop wallpaper).
  4. I have Cinnamon desktop on several computers and VMs as well as several more at my parents' place and am in a position to easily observe differences in how Nemo behaves on different setups. My primary two computers are an (older) gaming box with a single display hooked up to a tv as well as an (also older) dev box with 2 normal computer monitors. I have noticed that I am able to recreate the issue on the gaming box with no effort whatsoever, even without following mtwebster's steps, by simply opening another Nemo window and right-tiling it then trying to dnd within the same window. On my dev box (dual monitors), I am not able to recreate unless I follow mtwebster's steps OR I first disable my 2nd monitor in display settings.
  5. My gaming box has an older Nvidia GTX-970 card, while the dev box has an ancient AMD R9 290X... both are using proprietary drivers/codecs (nvidia drivers, mesa+codecs from rpmfusion). So I don't think AMD vs Nvidia matters.. or if it does, then other factors might need to be present as well (e.g. due to me being on Fedora, not using FOSS-only drivers, having older gpu's, etc).
  6. On the gaming box with a right-tiled window doing same-window-dnd, I am able to still able recreate the issue after switching view types and for all View types (Icon/List/Compact).
  7. I had fractional scaling on for both boxes. For the fractional scaling part of the equation, turning the setting off without logging out/rebooting doesn't seem to make any difference. TODO: I need to retest with a log off/reboot later when I don't have so much crap running in the background to see if that makes any difference... but based on initial tests in VM's and some of the comments above, I suspect that it does not matter.
  8. In List View when you are dragging a file/folder over another folder as a (potential) drop-target, normally if the target folder has any contents, Nemo will expand it* to show sub-folders etc. This behavior does NOT trigger when the bug is present (e.g. left-to-right OR right-same-window dnd).
  9. Using a new VM of Fedora 37 Cinnamon, in virt-manager, (offline install using Nemo 5.4.3 - not updated to latest in order to attempt to be as close as possible to when the issue first presented) with default (for Fedora) Nemo settings, I initially had trouble recreating the issue with left-to-right tiled dnd. After opening and closing Nemo windows several times, I closed all of the Nemo windows and opened 1 right-tiled window, then tried the same-window drag and was able to recreate the issue. After this, I was also able to recreate the left-to-right drag issue as well. The Enable fractional scaling controls option was ON out-of-the-box. I toggled it off and rebooted the VM, and noticed more oddities. I was able to easily recreate the right-tiled same-window issue any time I closed all Nemo instances and opened a fresh one from any .desktop launcher (menu, pinned panel icon, or one on desktop). Same with the left-to-right issue, if both instances were opened from launchers. BUT if I opened one window from a launcher, and another from the Open New Window context menu option, then I was not able to recreate either issue. Switching back to Fractional Scaling and rebooting, I observed the same behavior in the VM. I was NOT able to reproduce the launcer-related aspect of this on my bare-metal systems though. >!Also: I mean no slight to Mint or anything by testing on Fedora; they're both top-tier distros IMO... I just already had a F36 Cinnamon VM and I was able to install/test the F37 one while waiting on the Mint 21.1 iso to download!<
  10. Using an existing VM of Fedora 36 Cinnamon, also in virt-manager, (up-to-date install using Nemo 5.2.4 - updated to latest in order to attempt to be as close as possible to when the issue first presented) with mostly default (for Fedora) Nemo settings - this was an existing VM install and I think I had only changed the View settings to List mode. On this one, I tried several times opening and closing Nemo, tiling back and forth but ultimately was NOT able to recreate either the left-to-right tiled drag issue OR the right-tiled same-window drag issue.
  11. I was NOT able to recreate the issue with the Mint 21.1 Cinnamon live disc (Nemo v5.6.1) in a VM. Probably could have updated in-place but I didn't think of it before starting the install.
  12. After installing Mint 21.1 into a VM and updating packages, after rebooting, confirmed Nemo as v5.6.4. First try (right-tiled window launched from panel/quicklaunch) seemed to work ok for dnd within the same window. Closed window. Opened two fresh Nemo windows by clicking panel icon twice quickly. Tiled one to the left, then one to the right. Made new folder on left, then tried dragging to background area on right -> did nothing when released (e.g. issue present / dnd did not work). Dragging left-to-right onto a folder, same thing (dnd did not work). Right-window: created two folders and tried to drag one into the other -> same thing (dnd did not work).

* Probably not the best place for this and sorry about that but as a side-question / just in case anyone happens to know... I've actually been interested for a while now in writing a patch to make the folder dragndrop/expansion behavior (in my 8th point above) be something configurable from Nemo's Preferences menu (and possibly some other stuff too). Just curious where the best place to ask dev questions and such specifically related to Nemo would be? (e.g. if I had build questions / didn't understand something in the code / wanted to gauge likelihood of an idea being accepted or rejected before I started working on something / etc)

zpangwin commented 1 year ago

Moved to Fedora Cinnamon 38 (Nemo 5.6.4) last week and just wanted to confirm that above also applies there as well (understanding that it's not officially supported but more just to confirm for anyone else using it)

trr commented 1 year ago

I have been able reproduce this more than one with a nemo window snapped to the right half of the screen only and no other nemo window open at the time, just dragging and dropping a file from that window into another part of that same window (ie, a visible subfolder) does not work.

Un-snap the window from the right half of the screen and drag-and-drop within the window works.

However as is alluded to in other comments it doesn't happen every time and may depend on factors from before the window was docked, just pointing out that "having a second window open" is not a requirement to reproduce this. It's also a very annoying bug, it is happening surprisingly often.

NintendoManiac64 commented 1 year ago

I believe I have pretty much narrowed-down how to cause this issue and how to undo the issue in an extremely repeatable and/or reproducible manner. And, yes, it still occurs in Mint 21.2.

(not so?) fun fact: the issue even occurs dragging & dropping within a single nemo window, not just from one to another

TO CAUSE Simply dock the nemo window on the left or right half of your screen, close nemo, open nemo again, and dock it on the right side of your screen.

Now anything being dragged into that nemo window docked on the right side will not be placed where it's supposed to go.

TO UNDO Simply manually resize the nemo window docked on the right side or maximize its window, close it, re-open it, and then dock it again onto the right side.

As long as you don't close that nemo window again and immediately dock it onto the right side, you should be able to drag & drop files/folders without issue even while it's docked.

Video demonstration (live Mint 21.2)

video.webm

6630507 commented 1 year ago

What I find so maddening about the issue is that it violates the logic of rsync syntax: source --> destination

The source is on the left and the destination on the right. But this bug prohibits that, while allowing drag-and-drop trnsfers right-to- left. It's sacriligious.

It also violates the logic of the cp command, which is also left --> right.

This Nemo bug violates the logic of Linux somehow.

On Mon, 2023-07-31 at 15:42 -0700, NintendoManiac64 wrote:

I believe I have pretty much narrowed-down how to cause this issue and how to undo the issue in an extremely repeatable and/or reproducible manner. And, yes, it still occurs in Mint 21.2. (not so?) fun fact: the issue even occurs dragging & dropping within a single nemo window, not just from one to another TO CAUSE Simply dock the nemo window on the left or right half of your screen, close nemo, open nemo again, and dock it on the right side of your screen. Now anything being dragged into that nemo window docked on the right side will not be placed where it's supposed to go. TO UNDO Simply manually resize the nemo window docked on the right side or maximize its window, close it, re-open it, and then dock it again onto the right side. As long as you don't close that nemo window again and immediately dock it onto the right side, you should be able to drag & drop files/folders without issue even while it's docked. Video demonstration (live Mint 21.2) video.webm — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

NintendoManiac64 commented 1 year ago

What I find so maddening about the issue is that it violates the logic of rsync syntax: source --> destination

The source is on the left and the destination on the right.

If you look at my above-posted video, you'll see that the issue doesn't really have much to do with left --to-> right but is instead related to how docking a window in the right side makes it "bug out" regardless of where the source location is, including a source within the very same window.

IfGremlinThen commented 1 year ago

Posting my two cents because this is by far the biggest bug impacting my workflow right now.

This occurs in Linux Mint 21.2 & Linux Mint: Debian Edition 6 (the latest versions of both operating systems).\ I did not experience this issue in Linux Mint 20.3.

I am using Cinnamon 5.8.4, Muffin 5.8.1, & Nemo 5.8.5 in both operating systems and this occurs both on my AMD Ryzen 3 desktop computer and ASUS laptop.

The main thing that I haven't seen mentioned yet (do correct me if I've missed it) is that drag-and-drop DOES move the files sometimes, but it's as though the drop point on the screen is offset by some amount, so sometimes I'll move files from the desktop to a folder, and the files will disappear, but they won't appear in the destination folder. I haven't tested it yet, but I believe that the file selection is depositing at a point offset to the left of the actual cursor by some distance and that is dropping the selection into some of the My Computer/Bookmarks shortcuts in the left panel of Nemo's file explorer.

I believe... that when a file is dragged into a right-tiled Nemo window, the actual drop point is offset to the left by some unknown pixel distance. Obviously there are some parts of the Nemo file manager's windows that are not legitimate targets for moving files, so the effect of moving a selection to a window offset to these points is to treat it as though the file wasn't moved at all, because the destination is invalid. However, sometimes the offset is over an another directory, or shortcut to a directory, which are valid destinations, and the files will be moved there, in which case the apparent effect is that the files you moved have simply disappeared (though you can Ctrl+Z to get them back).

Hopefully this helps. If this isn't a dead issue I'll certainly test my theory.

NintendoManiac64 commented 1 year ago

I haven't tested it yet, but I believe that the file selection is depositing at a point offset to the left of the actual cursor by some distance and that is dropping the selection into some of the My Computer/Bookmarks shortcuts in the left panel of Nemo's file explorer.

You can see this in my above-posted video at around the 50 second mark as well as around the 1 minute 12 second mark.

6630507 commented 1 year ago

this is by far the biggest bug impacting my workflow right now

This is a daily nuisance for me too.

It's not always, but part of the circumstance might be unrelated to the bug, and might be a subtle behavioral thing.

For example, if your drag from left to right and it doesn't work, super-up or super-down the window to tile it into a corner, and then back into the whole right side, it works.

But, yeah, its a weird bug, and it violates the source- destination/left-right logic of many Linux text commands

On Wed, 2023-09-27 at 14:40 -0700, IfGremlinThen wrote:

Posting my two cents because this is by far the biggest bug impacting my workflow right now. This occurs in Linux Mint 21.2 & Linux Mint: Debian Edition 6 (the latest versions of both operating systems). I did not experience this issue in Linux Mint 20.3. I am using Cinnamon 5.8.4, Muffin 5.8.1, & Nemo 5.8.5 in both operating systems and this occurs both on my AMD Ryzen 3 desktop computer and ASUS laptop. The main thing that I haven't seen mentioned yet (do correct me if I've missed it) is that drag-and-drop DOES move the files sometimes, but it's as though the drop point on the screen is offset by some amount, so sometimes I'll move files from the desktop to a folder, and the files will disappear, but they won't appear in the destination folder. I haven't tested it yet, but I believe that the file selection is depositing at a point offset to the left of the actual cursor by some distance and that is dropping the selection into some of the My Computer/Bookmarks shortcuts in the left panel of Nemo's file explorer. I believe... that when a file is dragged into a right-tiled Nemo window, the actual drop point is offset to the left by some unknown pixel distance. Obviously there are some parts of the Nemo file manager's windows that are not legitimate targets for moving files, so the effect of moving a selection to a window offset to these points is to treat it as though the file wasn't moved at all, because the destination is invalid. However, sometimes the offset is over an another directory, or shortcut to a directory, which are valid destinations, and the files will be moved there, in which case the apparent effect is that the files you moved have simply disappeared (though you can Ctrl+Z to get them back). Hopefully this helps. If this isn't a dead issue I'll certainly test my theory. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

NintendoManiac64 commented 1 year ago

it violates the source- destination/left-right logic of many Linux text commands

As I already stated, I really don't think this has anything to do with left-to-right not working and has everything to do with a window docked on the right side of your screen being borked since this issue can even occur within a single window docked on the right side of the screen with files dragged downwards from the top of the window.

I'm starting to feel like a bit of a broken record with pointing out the video demonstration I made that, as far as I can tell, exactly identifies the problematic behavior in question in an extremely repeatable manner...

6630507 commented 1 year ago

I understand the underlying technical issue is more nuanced that simply left-to-right movements, but that's how I experience the bug in my workflow.

On Wed, 2023-09-27 at 19:10 -0700, NintendoManiac64 wrote:

it violates the source- destination/left-right logic of many Linux text commands As I already stated, I really don't think this has anything to do with left-to-right not working and has everything to do with a window docked on the right side of your screen being borked since this issue can even occur within a single window docked on the right side of the screen with files dragged downwards from the top of the window. I'm starting to feel like a bit of a broken record with pointing out the video demonstration I made that, as far as I can tell, exactly identifies the problematic behavior in question in an extremely repeatable manner. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

mtwebster commented 1 year ago

This is a problem with the dnd region in the xserver (not muffin) not being updated correctly when a window is tiled without being resized.

A quick workaround is to resize the tiled windows slightly (grab the common window edge and drag). This updates the region.

Besides the technical problem here, nemo should not be saving the tiled window size when you close it. This causes subsequent windows to spawn in an odd state depending on how it was tiled - in the case of left/right or top/bottom, the window will start already the size of the monitor in one direction. And unlike starting maximized, you cannot launch nemo 'tiled' - no matter what, the steps to tile the window are the same whether it starts out tiled size or not.

I've addressed this in nemo: https://github.com/linuxmint/nemo/commit/88da3336946922b3f433871fdbda595945b97032 - these builds include that fix if anyone is interested. Otherwise I suggest the workaround mentioned above, or un-tiling the last nemo window before closing it.

The actual dnd issue in muffin is proving more difficult to track down.

IfGremlinThen commented 8 months ago

Bump because this is still my biggest issue with Linux Mint at the moment. The last two versions of Mint have released with this bug and it really should have been squashed by the 6.0 release of Cinnamon.

I can now confirm this bug is still present as of LM 21.3, LMDE 6, w/ Cinnamon 6.0.4, Muffin 6.0.1, & Nemo 6.0.2.

Everything I've mentioned before about the cursor effect being offset has been borne out many times through daily usage. I was able to demonstrate it again while typing this:

https://github.com/linuxmint/muffin/assets/81646252/bb5c910d-9792-4c11-813c-e226e6ffb54b