bugs in book browser

[st_albert]

Originally Posted by DiapDealer

For what it's worth, the single-click-to-open nature of KDE means that when a new tab is opened (or takes focus) because of single-clicking on a file in Book Browser, the cursor is immediately going to the the BV/CV editor and the TreeView items are losing focus as a result.

The only reason I've never noticed this behavior before whenever testing in KDE, is because turning off single-click-to-open is almost always the first thing I do on a KDE system. It's the only way I can keep my sanity.

I concur that the single-click setting is the problem. Too bad; I like single-click for some things (I'm lazy like that), but I agree it's a PITA for other things. Maybe I'll keep it set to double-click for a while...

I never did have the crash on dragging files around in the book browser, so I don't know if it helps with that problem. Does it?

Albert

[DiapDealer]

Originally Posted by st_albert

I concur that the single-click setting is the problem. Too bad; I like single-click for some things (I'm lazy like that), but I agree it's a PITA for other things. Maybe I'll keep it set to double-click for a while...

Oh, I hear you on the lazy thing. There's times when single-click-to-launch is handy as heck. But when you're purposefully blurring the line between "highlight me" and "launch me," there's bound to be some problem areas.

Originally Posted by st_albert

I never did have the crash on dragging files around in the book browser, so I don't know if it helps with that problem. Does it?

I can't say for sure. I never got it to crash dragging files around, either. But I certainly wouldn't rule it out. Sid isn't called DebianUnstable for no reason.

With Qt essentially being tricked into thinking that items in QTreeView are being double-clicked, that means there's a heck of a lot more signals being emitted when attempting to drag around files in Sigil's Book Browser (on KDE with single-click-to-open enabled), than on systems where the exact same action doesn't result in any new BV/CV tabs being opened (nor does it cause any already open tabs to take focus).

[Reinhard]

The single click was the culprit for the multiple select issue. Selecting double click enabled the multipe selection. But the crash is still there.

[Reinhard]

If I use the command "ssh -X localhost" then sigil works as expected.
Multiple selections are OK, no crash when reordering.
I suppose there are less interactions with KDE.
So I have a workaround if I need these commands.

Thank for your help.

Reinhard

[DiapDealer]

Thanks for reporting back. I'll keep digging in the meantime. Please do let us know if Qt 5.11 changes anything RE the crash if you think about it.

[Reinhard]

Originally Posted by DiapDealer

Thanks for reporting back. I'll keep digging in the meantime. Please do let us know if Qt 5.11 changes anything RE the crash if you think about it.

No change with Qt 5.11. As the problem is with sigil and KDE, I expected that.

[DiapDealer]

This boils down to the "activated" signal of QTreeView (inherited from QAbstractItemView). "activated" can mean many things depending on the Platform -- single-click, double-click, hitting the enter key on a highlighted item, etc.

So clearly, KDE's "single-click to open files" setting alters the activated signal of QAbstractItemView in its system Qt5.

We could change to using the "doubleClick" signal of QAbstractItemView rather than "activated" (since I don't know of any special double-click functionality that Sigil reserves in Book View). That would likely fix most--if not all--of the issues with KDE (multi-selection and reordering crashes), but I'm loathe to use that solution. Mainly because it wouldn't take into account hitting the Enter/Return key when an item in Book View was highlighted (which works on at least two of the platforms Sigil supports). And doing so would affect those who favor keyboard input over mouse.

The only other solution might be to subclass QAbstractItemView to create new signals/slots that would behave consistently across all platforms (double-click and enter/return). But that could get complicated.

Will have to think more on it.

@KevinH: Are editor tabs opened/focused with single-clicks on Book View items with OS X or double-clicks? What about hitting the enter/return key when a Book View item is highlighted?

[KevinH]

Highlighting and hitting return will activate the link on OSX in BookBiew and now Preview.
Single clicking on Tab in Tab Bar will make that Tab active (bring it to front)

[DiapDealer]

Originally Posted by KevinH

Highlighting and hitting return will activate the link on OSX in BookBiew and now Preview.
Single clicking on Tab in Tab Bar will make that Tab active (bring it to front)

I'm not really concerned with Book View/Preview/links, here. This about clicking on entries in Sigil's Book Browser (QTreeView) DockWidget.

On Windows and Most Linux desktops, you have to double-click on an entry in the Book Browser to open its tab. It's KDE's single-click to open setting that's adversely affecting multiple selection in Book Browser. I was curious if it was similar on OS X (and if hitting enter when a file is highlighted in the Book Browser will open its tab).

[KevinH]

Mac is double click in bookbrowser to launch a tab. A single-click would interfere with just highlighting.

[DiapDealer]

Originally Posted by KevinH

Mac is double click in bookbrowser to launch a tab. A single-click would interfere with just highlighting.

That's what I thought. And that's exactly what's happening on KDE. Its single-click-to-open feature is essentially changing the "activated" signal of QTreeView into a single-click event.

I'm wondering what would happen if we connected Book View's m_TreeView "doubleClicked" signal to EmitResourceActivated in MainUI/BookBrowser.cpp instead of using the clearly platform-variable "activated" signal that we now use. We'd lose the ability to use Enter/Return to open the resource when it was highlighted, but I'm not certain that works on all Platforms as it is. That's why I was asking what hitting Enter on OS X did when a resource was highlighted in Book Browser.

If using doubleClicked solves the problem on KDE (and everybody else is already used to using double-clicks to open resources from the Book Browser any way), then perhaps we can add a platform independent signal/slot to MainUI/BookBrowser.cpp that will capture the Enter keystroke and launch the resource highlighted in m_TreeView (if the selected entry has a valid index, of course).

Just spit-balling really.