Having difficulty moving .html files in Book Browser in 1.1.0

[graycyn]

Originally Posted by DiapDealer

The problem is that the tabs are often too touchy on different platforms. The slightest twitch of the mouse when clicking on a tab will often result in tabs being moved/reordered. So we increased the distance necessary for a drag event to be registered as a drag. We did that back when crashes related to tab reordering was common. Unfortunately that's an app-level setting. It affects all drag distances. And it's often a different default on different platforms. I'll look into making it a user preference so people can choose their own happy-medium.

Speak up folks! Don't suffer in silence. The worst that can happen is I'll tell you to get stuffed.

That would be nice!

I have to say, I noticed this too (Windows 10), but I thought it might just be me or my machine. Or the fact I use a trackball. It is annoying, but like others, I figured out a workaround, so I didn't say anything, as so far, it has been my ONLY annoyance.

[DiapDealer]

Originally Posted by KevinH

Just finished building the version before your revert and I could not perceive any differences at all.

Do you want me try coding up the disable/enable movement by a ContentTab to see if that is workable?

KevinH

Do you experience the finicky nature of clicking on the inactive tabs on Mac in general, though? I'm curious if you're exempt from the phenomenon.

It's up to you if want to try try modifying the ContentTab. I'm certainly willing to give anything that you come up with a whirl, but I don't want to create a huge project for you either!

[KevinH]

Yes, if I try to click on a non-current tab with any even slight horizontal velocity the drag process starts almost immediately. It is very touchy. This only seems to happen with non-current tabs. It does not bother me that much but I can unintentionally move a tab by accident.

Let me at least add the code to enable and disable drag and drop of individual tabs as it can not hurt to add it. I will take a shot at this tomorrow.

It is too bad that ContentTabs do not know if they are the current tab or not, which would make this even easier.

[snarkophilus]

Originally Posted by graycyn

I have to say, I noticed this too (Windows 10), but I thought it might just be me or my machine. Or the fact I use a trackball. It is annoying, but like others, I figured out a workaround, so I didn't say anything, as so far, it has been my ONLY annoyance.

Hah, I just thought it was me too! It was one of those only slightly annoying things that may or may not have just been me, so I figured it wasn't worth raising here.

FWIW, I like the "click to enable a tab, click and drag to move the current enabled tab, can't move the inactive tabs" idea.

[DiapDealer]

Originally Posted by snarkophilus

FWIW, I like the "click to enable a tab, click and drag to move the current enabled tab, can't move the inactive tabs" idea.

Thanks. I was hoping it made general sense. Hopefully we can get it to work!

[KevinH]

Well that approach doesn't work either as the ContentTab::dragEnterEvent event handler is NEVER invoked at all (as shown by qDebug() output).

So normally a QWidget can prevent itself from being able to be dragged and dropped but this mechanism seems to be overridden either in the QTabBar or QTabWidget code someplace.

Since the dragEnterEvent event handler is never invoked we can not decide to either accept to ignore it.

So we will need to figure out something else.

By the way with the latest Qt 5.12.7 on macOS, the drag and drop of Tabs is much improved over the Qt 5.12.3 versions. It is not nearly as finicky anymore. So some platform specific changes must have made it into Qt since the Qt 5.12.3.

KevinH

[Notjohn]

>Move to #2 slot, then drag #1 down to #2 slot

I have a calendar software with the same problem (can't go to the top line OR the bottom line), and I work around it in the same way you suggest here.

[DiapDealer]

Originally Posted by KevinH

By the way with the latest Qt 5.12.7 on macOS, the drag and drop of Tabs is much improved over the Qt 5.12.3 versions. It is not nearly as finicky anymore. So some platform specific changes must have made it into Qt since the Qt 5.12.3.

KevinH

It's still pretty finicky on Windows with Qt5.12.6 (for the inactive tabs, anyway), so it must have been improved since then.

Thanks for taking a shot anyway. The problem with the inactive tabs isn't really a deal-breaker anyway. It's more annoying than anything. We can always revisit it if an idea presents itself.

I'll see what I can knock together for a startDragDistance tweak. One with a very narrow acceptable range of values. I'd consider an environment variable tweak, but that's just not very handy for most Windows users. And they're the ones who seem to need the tweak the most. I'll play with some options. Including simply setting a lower value for Windows.

[KevinH]

FYI, I checked the qtabbar.cpp code in qtbase and there really is no easy way to prevent inactive tabs from being dragged and dropped. The tab the mouse press event happens in is made the current tab but you will not see the change until the end. We would have to override the event handler in QTabBar and selectively ignore some mouse move events and in the end it may not help at all.

Btw the event->pos() used to determine if drag distance is enough will be measured in qt window standard pixels and not true resolution pixels, so it will return different values on Windows based on the highdpi settings and environment variables and may feel different on different displays in multi display systems.

So you may want to use different minimum drag distances based on display resolution and highdpi settings for Windows.

This is probably why this is much more stable on macOS as it always uses standard pixels versus device pixels for cursor positions.

I could see changing the minimum drag distance setting to 25 from 50 just to see if it helps at all.

[DiapDealer]

Originally Posted by KevinH

So you may want to use different minimum drag distances based on display resolution and highdpi settings for Windows.

I could see changing the minimum drag distance setting to 25 from 50 just to see if it helps at all.

The Qt platform default value seems fine to me when not on a high dpi monitor. I may change the minimum based on the high dpi setting, or I may just leave it as the platform default and let users tweak upwards if necessary. I won't know until I see how things work on the high dpi monitor at home.

[sherman]

I don't know the internals of QT (thank goodness!!), so not sure if the idea is possible. But I was wondering if an alternative way of dealing with the problem is to have a slight time delay to register drag, rather than a minimum distance? Would that work?

So, don't start dragging unless the mouse down has been active for n milliseconds.

[KevinH]

Unfortunately Qt uses drag distance and we can not change that without redesigning the qt internals. The problem with drag distance is that it can be different depending on screen resolution and seems to take into account acceleration. For example, flicking (clicking and dragging quite rapidly to the right or left in one motion and releasing) really causes Qt nightmares.

[sherman]

Ugh. So much for that idea then. Why did QT get so popular again...? (I know, I know, it's the only real cross platform option available that isn't something like Electron)

[BetterRed]

As a Windows user, who hates using the mouse, I've never yearned for any enhancements to help drag the CV tabs around, except when it was taken away. Maybe its because of the way I have my mouse configured, which is about as vanilla as it comes:



But dragging items up and down the Book Browser is a bit of a PITA. Move Up/Down options in the context menu with user configured shortcuts would suit me better.

BR

[Tex2002ans]

Originally Posted by BetterRed

But dragging items up and down the Book Browser is a bit of a PITA. Move Up/Down options in the context menu with user configured shortcuts would suit me better.

LibreOffice includes something similar for their "Navigator" (TOC):



They already have dedicated buttons for Move Up/Down, Promote/Demote. In 7.0, you'll also be able to Right-Click a heading (and I think Drag/Drop too).

Word 2016 allows you to Drag/Drop (+ Promote/Demote in Right-Click) headings in their Navigation Pane.

* * *

I think another alternate method of moving files up/down in Sigil's Book Browser would be a nice enhancement.

(Dedicated buttons would probably be hideously cluttered.)