Unsolved QTreeWidget & jump to parent element behavior on Mac OS X vs. Linux & Windows?

[tdiaz]

I'm checking here based on what I've derived from another forum. I've never done anything with Qt yet, and have barely cracked into Python as it is. So please excuse my amateur / improper use of terminology. :)

But while trying to figure out why Musicbrainz Picard does not recognize the Left Arrow key to jump to the Parent Element in a TreeView listing on OS X but it does on the other platforms.

Is there any reason why when working with TreeView lists that QTreeWidget does not behave the same on Mac OS X as it does n Windows or Linux?

On OS X, with the selection bar at the current location above, when I press the Left Arrow it should jump up to the parent item as shown below.

and then pressing it again would close the child view.

Perhaps there is some setting, flag, argument, etc. that needs to be set during building, or a Qt configuration option?

I've found several references to this across various open source projects and the consensus seems to point back to Qt as there is nothing specific being done at the Python level to capture that key event. The Left / Right Arrow inputs will expand / collapse the child view if the line is selected, but the selection will not jump up to that point otherwise.

[SGaist]

Hi and welcome to devnet,

What version of Qt are you using ?
On what version of macOS ?

[tdiaz]

That would be 5.13 for Qt and 10.14.1 for macOS.

[SGaist]

Would you mind providing a minimal example showing this so we are all looking at the thing to check that ?

You noted python several times. Are you using PyQt5 or PySide2 to develop your application ?

[mpergand]

I can confirm what @tdiaz describes on my old config (Qt 5.6, OSX 10.9) too.
As a note: if you open a native File Dialog under Qt, the behavior of the left arrow is effective (as it works in the finder)
So, it looks like a Qt issue ...

[tdiaz]

From a couple other forums, and both agree with @mpergand as well.

Here is a reply from the MB Picard forum where I started with this issue:
(When I started with this I had no idea what libraries were being used for the GUI until I read more on the subject, Python development, and the Picard source code.)

https://community.metabrainz.org/t/ui-keyboard-input-code-question-arrow-key-input-tkinter-gtk/453139/2?u=tdiaz

Here is a similar thread from FreeCAD.

https://forum.freecadweb.org/viewtopic.php?f=8&t=24389

They're both confirming similar behavior where the Left Arrow input works from the GetFile Dialog but not within the application functions.

The Linux & Windows builds of the same application do not have this problem, only macOS. My first thought was "it's not doing it because .. it needs to be made to do it", so I asked on the way I did on the MB Forum, and based on that reply, I found the other on FreeCAD forum, came here, where it all makes a lot more sense now. Hence, the query about a possible flag, option, etc. during build, otherwise the behavior isn't consistent across platforms where it seems like it should be.

[Christian Ehrlicher]

@tdiaz As @SGaist already asked - please provide a minimal example so we can reproduce the issue. The collapsing normally happens when the scrollbar is at the top, no matter if it is linux, windows or mac: https://code.woboq.org/qt5/qtbase/src/widgets/itemviews/qtreeview.cpp.html#2229

[J.Hilk]

@tdiaz

Interesting, I never noticed that. Quite a different behavior compared to, for example, Finder

@Christian-Ehrlicher @SGaist
As example you can use DirView - Example in direct comparison to Finder in TreeView Mode.

In Finder if you press left arrow anywhere in the "subtree" you jump to the top node, with Qt, it does nothing.
🤷‍♂️

In Windows this behaves like Finder on Mac

[tdiaz]

@J-Hilk
Thanks for the reference.
Yes, that's exactly it. The node will collapse/expand only if the selection line is already on that line, otherwise it will not jump up to it as it does on the host's OS, in the case macOS.

When I started looking into it I realized that Linux and Windows work as expected and that it's only macOS where the behavior is not consistent.

The code in question is here:

https://github.com/metabrainz/picard/blob/master/picard/ui/itemviews.py

Open a node, place the highlighted line on any position in the list, press Left Arrow and on Linux, Windows, it will jump up to the parent item. On macOS it stays put.

If you are using the host OS 's dialogs then it works, but anything within the application build does not work the same way.

[tdiaz]

In further discussing this issue, mnemonics being disabled by default on OS X came up.

QtGui.qt_set_sequence_auto_mnemonic(True)

Enabling that didn't change anything related to the arrow key behavior. While the movement keys are not mnemonics I could see the behavior being wrapped up that thought process as for why they're disabled on macOS by default.

Behavior parity would be nice.

[tdiaz]

@Christian-Ehrlicher , @SGaist

The collapsing happens when the scrollbar is at the top. That is not the problem.

On Windows & Linux, when the scrollbar is -not- at the top, pressing Left Arrow will cause it to jump to the top first. Then a second left arrow key input will collapse the list.

On macOS you've got to use the Up Arrow as many times as needed to get to the parent item first.

Except if it's built with Qt5 and running on macOS.

"Please provide an example".

On Windows & Linux, if you were on this screen, pressing Left Arrow at this point would cause the selection bar to move up to 'proc'. Pressing it again would close 'proc'.

To do the same thing on macOS, you can press Left Arrow, it does nothing. Press Up Arrow 9 times, then press Left Arrow.

The key here is from -WITHIN- the built application. Download Musicbrainz Picard.

Here is a silent video example.

In this example I start out with a macOS Finder window.
Using the arrow keys I open 3 directories.
At the 3rd entry in the 3rd directory down, I press the Left Arrow key.
The selection bar will jump up to the parent directory. Pressing Left Arrow again will close it, pressing again will jump up to the next, and so on...

Then I'm going to do a similar thing within an application built using Qt5.

When moving within MusicBrainz Picard you see the selection bar advancing upwards one line at a time because pressing the Left Arrow does nothing. This behavior is NOT happening within of applications built with Qt5.

Using the host OS the behavior is as expected.
But within the built application it is -NOT- happening.

On Linux and Windows, pressing Left Arrow from within a list will make the selection bar go to the next highest parent if it's not already there. If it is, it will close the list. Pressing it again after that will again go straight to the next parent item in the list.

https://youtu.be/YfVlySQXXEE

The code performing that is linked to above, as is the reply from @J-Hilk

If this is by design, like the mnemonics functions, is there a way to enable it? If not, why is it not doing it? Enabling mnemonics support does not enable the Left Arrow behavior.

[tdiaz]

This issue has been going on for quite a few years now - and it used to work. In computer years, 2012 is a century ago. But. It used to work.

https://bugreports.qt.io/browse/QTBUG-32617

" P3: Somewhat important " <-- Maybe it's an indicator of real world use of Qt5 on macOS, that it's 'somewhat' important and still outstanding.

..another place where it got mentioned with no resolution ever noted.

https://forums.perforce.com/index.php?/topic/3504-p4v-collapse-workspace-tree-node-with-left-arrow-key/

[tdiaz]

Guess there's no love for this issue..
Since it used to work in Qt4, maybe I might get lucky and see if something in source that changed can be 'un-done' and moved up to the current build.

I have a keyboard wedge that will do things automatically but it depends on the left arrow key working as expected. Works on Windows and Linux.

[SGaist]

The bug report mentions Qt 4.8.5, can you check whether that's the case and whether it is still the case with Qt 4.8.6 and 4.8.7 ?

[tdiaz]

This is an old thread, sorry. But it's still an issue. As far as I know, it does not work with those versions of Qt 4 either, but it did work properly with earlier versions.

I've looked at the source code and as far as I can tell, that portion of the code, at least what I think it is, looks the same to me in the current releases as what I see in early 4.x

The frustrating this is that it works on Linux, and to me that's a lot closer to macOS than Windows is. There are comments in the Qt source and reference documentation that say things about Mac differences and keyboard input.

[SGaist]

The Linux graphics stack and the one from macOS have nothing in common. They share a Unix heritage but it's rather in the backend side of things.

Anyway, you say that it worked in earlier versions, which one is it ?

You can use that one to compare the code and see what may have broken since.

[tdiaz]

@SGaist QT4 less than 4.8.5 works .. and while I'm not anything near fluent with ECMA/JavaScript I can follow along in the code. Anything past that point through the current release does not behave the same. My findings have been that .. that whole section is different. So nothing to compare to. There are comments about OS X key input vs. Linux/Windows that don't seem to be in 4.x and anything I try with flags during build doesn't change anything. The behavior is broken. The second left arrow input does not advance the line selection to the parent object in the list.

..and it's just a big finger pointing deal at each others side

What I don't get is then why if it's built and generating three builds at the same time, why one of them acts differently than the other two .. and then if I find something to change is that going to affect where it works properly.

Though I suppose the if something needs to be set differently then 'is osx' in proper syntax can be used during the build.

[SGaist]

The macOS specific behaviour was implemented in QTreeView directly be there's indeed some stuff that have disappeared/changed with Qt 5.

You should check the bug report system to see if there's something already there. If so, please comment on it and if not, please open a new ticket.

[JamesKelly]

Hi, I thought I'd reply to this as it's likely the first post anyone will see when facing the same bug.

Here's a fix/workaround I made to solve this issue. Feel free to use yourselves. I promoted the QTreeView to a custom widget and implemented my own moveCursor function:

QModelIndex AudioTree::moveCursor(CursorAction cursorAction, Qt::KeyboardModifiers modifiers)
{
#if defined (Q_OS_MAC)
    QModelIndex current = currentIndex();
    bool currentIsExpanded = isExpanded(current);
    QModelIndex newIndex = QTreeView::moveCursor(cursorAction, modifiers);

    if (current == newIndex && !currentIsExpanded && cursorAction == MoveLeft)
    {
        return current.parent();
    }
    return newIndex;

#endif
    return QTreeView::moveCursor(cursorAction, modifiers);
}