Having difficulty moving .html files in Book Browser in 1.1.0

Gregg Bell · 02-11-2020, 10:01 PM

It used to be easy to adjust the .html files order in the Book Browser by left clicking and dragging on the file. Now it works like only 10% of the time. Is there a different/better way of adjusting their order?

KevinH · 02-11-2020, 10:38 PM

Click on them and start to drag. Wait momentarily for the drag animation to start. Move to where you want in the spine order and release. This works just fine in my machine (a mac). What platform are you using?

DNSB · 02-12-2020, 12:16 AM

Quote:

Originally Posted by Gregg Bell

It used to be easy to adjust the .html files order in the Book Browser by left clicking and dragging on the file. Now it works like only 10% of the time. Is there a different/better way of adjusting their order?

I've noticed that I might have to move the file a couple of positions before it looks as if it is starting to move (the divider line appears). I.e., I want to swap last two files Section0009 and Section0010, I grab Section0010, drag it up past Section0007 and then back down until the divider positions between Section0008 and Section0009.

OS is Windows 10, x64. Sigil is 1.1.0 x64

BetterRed · 02-12-2020, 03:09 AM

Interesting, I thought it was just me… becoming even more mouse averse.

In recent times its been my perception that dragging things around in the calibre ToC tree and CSV catalogue column list has become more difficult - possibly since version 4.0 - so I've stopped doing it. The ToC tree also has move up/down arrows, so I use those to reorder items. For the CSV catalogue, I defer the column reordering until I get the CSV into CSVFileView.

Now I'm wondering if it's a Qt effect.

Window 10 Pro 64 bit 1909

BR

theducks · 02-12-2020, 04:43 AM

I also noted that trying to move to the #1 slot was a pain (can't go above easily).
My work around: Move to #2 slot, then drag #1 down to #2 slot

DiapDealer · 02-12-2020, 07:50 AM

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.

Turtle91 · 02-12-2020, 07:52 AM

Quote:

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.

Awesome!

DiapDealer · 02-12-2020, 08:28 AM

I'm thinking the best plan might be to give users the ability to turn off tab reordering on the main tab manager widget, as well as having the option to tweak the startDragDistance.

I never reorder the tabManager tabs myself, and even though the startDragDistance is a teensy bit off-putting on my Linux system (in Book Browser with our current setting), the Tabs are still pretty touchy. I have to be careful so as not to go flinging them around when I'm trying to quickly close them.

Being able to turn off tab reordering should theoretically allow me to be able to set a much more comfortable startDragDistance for the Book Browser.

Those who need/want both will just have to choose whatever happy medium the current version of Qt will allow them to choose.

KevinH · 02-12-2020, 08:51 AM

If you decide to go that way, please ifdef it so macOS users are left alone. I do not think the drag distance requirement impacts tab reordering that much as it seems to pretty well ignore it.

DiapDealer · 02-12-2020, 08:56 AM

Quote:

Originally Posted by KevinH

If you decide to go that way, please ifdef it so macOS users are left alone. I do not think the drag distance requirement impacts tab reordering that much as it seems to pretty well ignore it.

Will do, thanks!

DiapDealer · 02-12-2020, 10:10 AM

It's actually the inactive tabs that act very twitchy for me. When I try to click on one to activate it (Windows or Linux) I have to be extremely careful about not moving the mouse even one tiny little bit, or they will jump to the left or the right. Grabbing the active tab and dragging it seems to honor the startDragDistance quite nicely. So maybe this is something else entirely.

DiapDealer · 02-12-2020, 11:16 AM

@KevinH: got a spur-of-the-moment (not-very-well-thought-out) what-if for you.

In my mind, there is no need to be able to reorder any tab other than the one that is currently active. If one had to first activate a tab and then grab it again in order to move it in relation to the others, this whole twitchy inactive tabs thing wouldn't be an issue.

Since we already subclass QTabBar and reimplement a few things, is there any way could reimplement something that could prevent moves for any tab that wasn't already active when first clicked?

I know that's vague as heck, but I don't have any of Qt's QTabBar source in front of me.

KevinH · 02-12-2020, 11:57 AM

Interesting idea.

I will look into it when I get home from work tonight. There should be a way to handle that but we may to to overload the original QTabBar drag and drop routines with our own code that screens tabs our if not the current tab.

KevinH

Quote:

Originally Posted by DiapDealer

@KevinH: got a spur-of-the-moment (not-very-well-thought-out) what-if for you.

In my mind, there is no need to be able to reorder any tab other than the one that is currently active. If one had to first activate a tab and then grab it again in order to move it in relation to the others, this whole twitchy inactive tabs thing wouldn't be an issue.

Since we already subclass QTabBar and reimplement a few things, is there any way could reimplement something that could prevent moves for any tab that wasn't already active when first clicked?

I know that's vague as heck, but I don't have any of Qt's QTabBar source in front of me.

KevinH · 02-12-2020, 12:02 PM

From the Qt QTabBar docs, this looks interesting:

Code:

changeCurrentOnDrag : bool

If true, then the current tab is automatically changed when dragging over the tabbar.

Note: You should also set acceptDrops property to true to make this feature work.

By default, this property is false.

This property was introduced in Qt 5.4.

Access functions:

bool	changeCurrentOnDrag() const
void	setChangeCurrentOnDrag(bool change)

So if you start to drag a non-current tab, it will make it the current tab automoatically. Not sure if this will help but it would be an easy change to make and test. If so, we should be good to go.

DiapDealer · 02-12-2020, 12:13 PM

I saw that, but was (perhaps mistakenly) thinking it would need to be false to help us (which it already is by default). Making it true never occurred to me. It already becomes active whenever I accidentally "twitch" one anyway, but perhaps there's some internal timing at play which enabling changeCurrentOnDrag would affect.

I was also interpreting that description a little differently when I first read it. I was assuming that it was talking about dragging another object over top of a QTabBar.

Easy enough to test, though.

02-12-2020, 12:02 PM	#14
KevinH Sigil Developer Posts: 8,735 Karma: 5703586 Join Date: Nov 2009 Device: many	From the Qt QTabBar docs, this looks interesting: Code: changeCurrentOnDrag : bool If true, then the current tab is automatically changed when dragging over the tabbar. Note: You should also set acceptDrops property to true to make this feature work. By default, this property is false. This property was introduced in Qt 5.4. Access functions: bool changeCurrentOnDrag() const void setChangeCurrentOnDrag(bool change) So if you start to drag a non-current tab, it will make it the current tab automoatically. Not sure if this will help but it would be an easy change to make and test. If so, we should be good to go.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Hacks Kindle browser to read html files	l1n1234	Amazon Kindle	23	01-28-2012 11:00 PM
PRS-950 Can PRS-950 web browser view local HTML files?	roc	Sony Reader	3	04-02-2011 10:58 AM
Browser doesn't load local HTML files?	kenjennings	enTourage Archive	1	02-19-2011 09:52 AM
Difficulty with conversion of HTML	ficbot	Calibre	8	03-23-2009 09:34 AM

02-11-2020, 10:01 PM	#1
Gregg Bell Gregg Bell Posts: 2,266 Karma: 3917598 Join Date: Jan 2013 Location: Itasca, Illinois Device: Kindle Touch 7, Sony PRS300, Fire HD8 Tablet	Having difficulty moving .html files in Book Browser in 1.1.0 It used to be easy to adjust the .html files order in the Book Browser by left clicking and dragging on the file. Now it works like only 10% of the time. Is there a different/better way of adjusting their order?

02-11-2020, 10:38 PM	#2
KevinH Sigil Developer Posts: 8,735 Karma: 5703586 Join Date: Nov 2009 Device: many	Click on them and start to drag. Wait momentarily for the drag animation to start. Move to where you want in the spine order and release. This works just fine in my machine (a mac). What platform are you using?

02-12-2020, 03:09 AM	#4
BetterRed null operator (he/him) Posts: 21,707 Karma: 29711016 Join Date: Mar 2012 Location: Sydney Australia Device: none	Interesting, I thought it was just me… becoming even more mouse averse. In recent times its been my perception that dragging things around in the calibre ToC tree and CSV catalogue column list has become more difficult - possibly since version 4.0 - so I've stopped doing it. The ToC tree also has move up/down arrows, so I use those to reorder items. For the CSV catalogue, I defer the column reordering until I get the CSV into CSVFileView. Now I'm wondering if it's a Qt effect. Window 10 Pro 64 bit 1909 BR

02-12-2020, 04:43 AM	#5
theducks Well trained by Cats Posts: 31,021 Karma: 60358908 Join Date: Aug 2009 Location: The Central Coast of California Device: Kobo Libra2,Kobo Aura2v1, K4NT(Fixed: New Bat.), Galaxy Tab A	I also noted that trying to move to the #1 slot was a pain (can't go above easily). My work around: Move to #2 slot, then drag #1 down to #2 slot

02-12-2020, 07:50 AM	#6
DiapDealer Grand Sorcerer Posts: 28,548 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	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.

02-12-2020, 08:28 AM	#8
DiapDealer Grand Sorcerer Posts: 28,548 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I'm thinking the best plan might be to give users the ability to turn off tab reordering on the main tab manager widget, as well as having the option to tweak the startDragDistance. I never reorder the tabManager tabs myself, and even though the startDragDistance is a teensy bit off-putting on my Linux system (in Book Browser with our current setting), the Tabs are still pretty touchy. I have to be careful so as not to go flinging them around when I'm trying to quickly close them. Being able to turn off tab reordering should theoretically allow me to be able to set a much more comfortable startDragDistance for the Book Browser. Those who need/want both will just have to choose whatever happy medium the current version of Qt will allow them to choose.

02-12-2020, 08:51 AM	#9
KevinH Sigil Developer Posts: 8,735 Karma: 5703586 Join Date: Nov 2009 Device: many	If you decide to go that way, please ifdef it so macOS users are left alone. I do not think the drag distance requirement impacts tab reordering that much as it seems to pretty well ignore it.

02-12-2020, 10:10 AM	#11
DiapDealer Grand Sorcerer Posts: 28,548 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	It's actually the inactive tabs that act very twitchy for me. When I try to click on one to activate it (Windows or Linux) I have to be extremely careful about not moving the mouse even one tiny little bit, or they will jump to the left or the right. Grabbing the active tab and dragging it seems to honor the startDragDistance quite nicely. So maybe this is something else entirely.

02-12-2020, 11:16 AM	#12
DiapDealer Grand Sorcerer Posts: 28,548 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	@KevinH: got a spur-of-the-moment (not-very-well-thought-out) what-if for you. In my mind, there is no need to be able to reorder any tab other than the one that is currently active. If one had to first activate a tab and then grab it again in order to move it in relation to the others, this whole twitchy inactive tabs thing wouldn't be an issue. Since we already subclass QTabBar and reimplement a few things, is there any way could reimplement something that could prevent moves for any tab that wasn't already active when first clicked? I know that's vague as heck, but I don't have any of Qt's QTabBar source in front of me.

02-12-2020, 12:13 PM	#15
DiapDealer Grand Sorcerer Posts: 28,548 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I saw that, but was (perhaps mistakenly) thinking it would need to be false to help us (which it already is by default). Making it true never occurred to me. It already becomes active whenever I accidentally "twitch" one anyway, but perhaps there's some internal timing at play which enabling changeCurrentOnDrag would affect. I was also interpreting that description a little differently when I first read it. I was assuming that it was talking about dragging another object over top of a QTabBar. Easy enough to test, though.

Advert

Advert