'gnome connection manager' and 'midnight commander'

[Gintarelis]

There is a problem running 'midnight commander' (mc) inside on 'gnome connection manager' (gcm). gcm opens new tab (instead of executing command in mc), when i click twice anywhere on the right panel of mc. Left panel works ok. Tested with the latest 'gnome connection manager' version on Ubuntu 20.04, 20.10, 21.04, Manjaro 21.

[jimklimov]

Just as a data point, can't reproduce with GCM 1.2.1 and MC 4.8.27 in OpenIndiana 2021.10.

[Gintarelis]

How it looks:
https://youtu.be/gpw1n-UtZiU

[jimklimov]

UPDATE: Can confirm on same system with current Git HEAD of GCM (from 2021-04-20)

Experimentally, it seems that the critical spot is the size of tab bar - when I double-click in MC under currently rendered GCM tabs, it works as expected (dir change, dir sorting change, file open - wherever the mouse lands). But when I click just to the right of the imaginary vertical column from the rightmost GCM tab, it opens another tab indeed. When the new tab appears, I can go back to the one with MC and safely double-click right where it just opened the GCM tab, and the new end of tab line counts for "dangerous" doubleclicks.

Checked this did not happen in 1.2.1 release, and does not happen in plain shell terminal (without MC).

Notably, some commits after 1.2.1 did fix an issue I had in #5 with mad refreshes of git less, git diff, multi-line command lines in shell, etc. In history I see a number of Gtk related fixes that might resolve those issues, no idea if any (or rather which) of them introduced the new one :\

[jimklimov]

Using some hit-tech sys.stderr.write("...") again, I found that this seemingly happens in https://github.com/kuthulux/gnome-connection-manager/blob/master/gnome_connection_manager.py#L2033 - without MC running this somehow is not hit at all (at least, does not match the first "if"; but enters it when MC is running).

In this context, "toolbar" is where the menu and buttons are; "notebook" is the terminal and tabs.

I don't see any height (or "y" coord) check here, upon cursory reading (so not sure how/whether it differentiates the terminal and tabs); but this code area did not change since v1.2.1 tag which worked - so maybe it was decided elsewhere. This block does end with an addTab() however, if earlier checks did not bail out...

[jimklimov]

With a bit more tracing, it seems that when MC is running in the new GCM, double-clicks into its terminal and into the tab bar have two independent "notebooks" each with its "height" position looking at posY = event.y + widget.get_allocation().y - one relative to the terminal, another relative to tab bar.

Code probably assumes this if-claused situation only happens for clicks near tabs, and opens a new one; there was no need to consider heights etc. : with older GCM, an MC running did not hit the "if" inner logic...

[jimklimov]

A quick test showed that reverting PR #54 b23683e "fixes" this behavior, but breaks back the rendering I complained about in #5 - so I guess we need to keep it and to somehow discern which "notebook" we look at...

[jimklimov]

ugh... somehow this is still the same GdkNotebook object instance (same address when str() reports it), so it is something about posY coord then... allocation?

Update: no, something else. Double-clicks in tab bar and in MC windows (including MC over SSH to another host), report widget same width/height and x=y=0 :\ So with our coords maths, the "event" has different points of reference somehow, while the widget is the same.

[jimklimov]

At least, str(event.get_window()) reports different GdkX11Window objects for the buttons, tab bar, terminal with MC...

[jimklimov]

One quick hack I can suggest is to look at the size.height vs. posY defined above - if we clicked beyond the label-tab height, we certainly did not click the tab but the MC terminal. If we double-click the top 30 pixels of MC, out of luck then.

I am currently at a loss for "proper" solution though, would rather defer to experts like @kuthulux :)