Dueling dual Mouse pointers on drag'n'drop

Help
1

The following issue might be an artifact of my Fedora OS. (I don’t recall seeing it before when I was running Windoze.) So I’m asking if the other Linux flavors, macOS, or Windows have the same problem.

Normally, the mouse pointer changes to indicate the current action. When dragging an object, the normal arrow pointer changes to a tiny hand pointer.

When grabbing an object from a category view and dragging it to the clipboard, Gramps adds context by underlaying a 24x24 icon of the grabbed Object type immediately below the ‘hand’ mouse pointer. (This is also normal behavior.)

BUT… when dragging one of the 2ndry objects from the table list Tabs of a spawned Object editor dialog (or from the clipboard), the underlying object icon is offset… badly offset. And the mouse has a obfuscated hotspot. And the horizontal offset worsens the further you grab from the 1st column of the table. (The vertical offset seems to stay about 1 row height.)

So, if you drag a Personal Event from the Edit Person dialog and grab the Event row in the “Main Participants” column, the mouse’s hand pointer and the ‘underlying’ object icon are half a screen away from each other.

image
image784×289 16.1 KB

(Gramps 5.1.5 on Linux, Fedora 37)

Several other pointer oddities occur with drag’n’drop. (And are different in Windows from these Fedora examples. On Windows, the arrow pointer disappeared but the object/swatch dragged visually.)
Sometimes when dragging from the view, the pointer obscured the object
image
Sometimes when dragging from the view, when the pointer was lightly offset from the object
image
Sometimes when dragging from the clipboard, the pointer had a plus
personimage | image bookmark
Sometimes when dragging from the clipboard, the pointer had an arrow
image
and as originally mentioned: dragging from the clipboard, you have to be careful to grab from the 1st column or there will be excessive offset.
image

2

No, I don’t see that behavior on my Mac.

1 Like
3

I don’t see it here either, on LMDE 5 (Linux Mint Debian Edition), with Cinnamon desktop.

I will try it on my laptop later. It has Linux Mint 21 MATE, and Fedora 37 (?) running in a VM, with Gnome and Cinnamon desktop options.

1 Like
4

OK, I saw it here too, and it seems to be a Gnome thing. I don’t see it when I log in with the Cinnamon desktop on that same Fedora 37.

Can you try adding the Cinnamon desktop on your system? Instructions are here, and the process is very simple, involving only two steps, installing the thing, and reboot. Then, next time you log in, you can click the gear icon to select Cinnamon, as is also shown on that page. You can ignore the lines about the server edition, I think.

Note that on Fedora 37 the gear icon is not where it’s shown here, but at the bottom right of the screen.

On MATE, everything is OK too.

It would be nice to find out whether others see this with Ubuntu, where Gnome is standard too, since the demise of the Unity desktop.

1 Like
5

I just installed ubuntu in a new VM, this time inside Windows 11, because I ran out of disk space on my Mint partition, and the drag and drop problem shows there too, so it’s very likely that it is a Gnome problem.

And then the next question is: How do we report that? Have others seen this and written about it on ubuntu forums, Facebook, or on stackexchange?

6

Check me on this but…

It seems like it is confusing the difference in the (0,0) screen position of tab’s table row origin and the mouse’s absolute screen position.

If so, Gramps might be a unique Gtk GUI implementation: grabbing a table row in a tab of a spawned wndow.

7

About the first: To me it seems like in Gnome the horizontal offset to the window (0,0) is doubled somehow. And I don’t know why this happens, although I can of course make some assumptions. I’m thinking about this doubling, because the effect increases when your click before drag is further away from the left side of the window, and it’s not a stepwise thing. You can check that by clicking on several positions in the 1st column.

What I see is that the extra icon, like the calender shown for events, appears at the moment that the OS detects that my click is a drag, and one possible explanation might be, that there is an OS call that has a parameter to position the drag icon relative to the mouse pointer, which should then be either (0,0) or a small fixed offset, so that it does not overlap. And when that parameter is filled with the relative position inside the child window, the net effect is that the horizontal offset will be doubled. That’s my developer’s mind at work.

And about the 2nd: This may be quite rare, or even unique, but it’s not rare enough to be handled right by the window managers that I use, which are Cinnamon, MATE, and Microsoft’s one, for which I assume that it’s called Windows.

What I mean is, that although one might think that the problem is in Gtk, the truth is, that when I try this with Cinnamon and Gnome on Fedora, it is the same Gtk version talking to the window manager. And that suggests that the problem is not Gtk dealing with a rare situation, but Gnome. And I think that, because it also shows on ubuntu with Gnome, and right now I’m not sure whether the Fedora and Debian/ubuntu distributions of Gramps have the exact same Gtk version. And in fact, I’m not even sure whether the Gnome desktops included with Fedora and ubuntu are the same.

The proof of the pudding might be to try this on other ubuntu distributions like Kubuntu (using KDE), and ubuntu MATE. And if the error is in the Gnome desktop (window manager) you will probably see proper behavior on the other desktops.

If the problem was in Gtk, it would be visible everywhere, also in Windows.

1 Like
8

Ok. I installed Cinnamon and the glitch does not appear. But when selecting Cinnamon during boot, there where other options:

  • Gnome
  • Gnome classic
  • Gnome on Xorg
  • Gnome classic on Xorg

The problem only happens with the 1st two, not on either Xorg option. And since I also had an external monitor so a test with only the laptop screen still only shows the problem for Gnome and Gnome Classic.

9

H’m, this is interesting, because Xorg is a display server, as mentioned here:

https://wiki.archlinux.org/title/xorg

And given the options that you mentioned, it is clear that it is not the default, which is another (unnamed) server. That server is always there, and I have no idea what that default version actually is.

Have you tried other forums already, like on the Fedora site?

12

There was a similar problem described on the Ubuntu forum about 7 years ago. I’m too much of a Linux tenderfoot to understand their suggested Gnome solution.

13

Well, if that’s the case, I suggest that you just try the gsettings commands given there, to get those tender feet a bit wet. There’s not much that you can do wrong there, so you will learn from it anyway.

1 Like
14

Nope. Can’t afford the time right now. Losing my Linux innocence means weeks of experiments. I now know how Gnome does the dual pointers on my system and compensate… or can fallback to Cinnamon. If people have more serious drag’n’drop issues on other systems, maybe noting the Gnome similarities will narrow the possibilities.

The recent accelleration of PRs being approved means the window of opportunity for inclusion in 5.2 changes is closing. I don’t want to miss it.

Rather than endure more years of brow-beatings from the tire-kicking masses about a perplexing UX during the first hour of use, I think that we can obliterate that complaint with a few simple tweaks. (Changes that have zero reduction in access to the power or that slow the interface.) Staying with the tire-kicking metaphor, if we continue to rely on a hand-crank ignition procedure; it should more obvious that they need to set the points, retard the timing, restrict the choke and avoid breaking wrist or thumb.

1 Like
15

Hehe, yes, I get it. Your Linux life could have been a lot easier if you’d chosen for Mint, with Cinnamon or MATE, depending on your hardware. Your mouse pointer would then behave a lot better, and the Start menu would also be where you’d expect it to be.

1 Like
16

I’m not positive and need to investigate more, but I think this may have something to do with building the gui directly via gtk vs using a glade template. Either that or the specific widgets used but I haven’t looked into that yet. The reason I say this: As far as I can tell the lists of people, citations, etc. are all generated using the gtk python library directly. They do not have the same problem. You can click anywhere and the dragged icon is in the correct location with no issues with offset. The clipboard interface, however, is made from a glade template and does have the issue.

I think the answer to figuring out why Gramps has this weird bug in Gnome lies in figuring out what the key implementation difference is between the list views and the clipboard, whether that be a widget type, a setting in the glade template, or the use of the glade template itself.

1 Like