if you open a new directory in a file-manager, is it pcmanfm-qt or dolphin, then the home-key will not work right away;
only if an other file is marked, then the home-key works, else one need to press the space-key to mark the first file;
it would be better if the home-key would work at any time, instead of the home-key and space-key
don’t work at any time;
What I know: the problem is not the file-manager;
I think it is because a no-current-item does not exist in Qt;
I think that at the moment there are only 3 values, current-item, onmouseover-item and selected-item.
If no-currennt-item would exist, and if it is default, then when a new directory will be opened,
the home-key should work right away
now my questions to you:
Because I can’t program a software: Are my thoughts correct?
Is qt.io the right place to report the issue?
From what I can tell, you have already reported this in LXQt and they told you that essentially this is a behavior of Qt. I recognize that LXDE does something different. I’m not sure that’s because of its own code or because of GTK. Either way, it might not be something either Qt or LXQt care to implement, so I wouldn’t get your hopes up too high.
I thought that this was a Qt-bug, but due to the comments on that bug, it seems to be that this is the behavior of Dolphin and PCManFM-Qt; in other words: Dolphin and PCManFM-Qt could be programed that the home key works at any time, but the programer of Dolphin and PCManFM-Qt decided to use an other behavior
Unfortunately, I can’t tell you who is right and who is wrong here. However, when it comes to this sort of thing where people point fingers at each other, it’s important to display to them the opposite side so they can come together for some sort of resolution.
That said, as was said in one of the comments on the Qt bug:
we just have some widgets that could be used in a file manager, like QListView and QTreeView
Those are indeed the widgets that PCManFM-Qt uses. So it certainly seems that if anywhere, the problem exists in Qt, but I don’t know.
The problem with reporting something on Qt is exactly as you found: you need to show a problem with the way their code works, not how an application that uses it works, although it may be applicable. The best way to do this (although this is probably asking for more than you’re willing to do) would be to create a very simple program using those widgets and showing how its behavior is problematic.
Even if you can show that, all you would be showing is that it responds in a way that is different than alternatives. Different doesn’t mean that it’s wrong or bad. In fact, it may be entirely intentional that it function that way.
One thing to consider is that PCManFM-Qt should not be considered a 1:1 alternative to PCManFM anymore than LXQt should be considered a 1:1 alternative to LXDE. Though PCMan was instrumental in the initial porting, there was a wholly separate and unique team of people that put LXQt together relative to LXDE. They are completely different things and they use completely different toolkits that themselves have their own behaviors and requirements. The fact that LXQt does not work exactly like LXDE is not necessarily a bug. In most cases, it’s a feature.
Respectfully, I find this to be of such minor value that were I you, I’d just use Space and stop wasting my time. Think of how many times you have used it just trying to write about this so-called problem!
