Book Browser issue - Page 3

KevinH · 11-02-2026, 04:27 PM

We inherited that snippet from just before Sigil 0.6.0. So it is over 14 years old.

https://github.com/Sigil-Ebook/Sigil...62fc9fa722863c

Prior to that Sigil at some point started Centering all the time which would make selection a bit too "nervous". But that was back in the Qt 4.X days I think.

I think we are safe to change this to EnsureVisible now in Qt 6.x

Do you want me to push this change now in time for the release?

DiapDealer · 11-02-2026, 04:56 PM

Don't go to too much trouble to track it down. EnsureVisible seems the much more reasonable approach (to me) anyway.

EDIT: Whoops! missed your latest post. And unless you foresee any potential pitfalls, I say yes... push the change in time for our upcoming release.

KevinH · 11-02-2026, 05:41 PM

Will push it tonight.

Update:

This change has now been pushed to master.

No translation changes are needed so we should be good to go.

DNSB · Yesterday, 12:36 AM

My latest test build for Windows can be downloaded from the link in the Downloading Sigil test builds for Windows thread.

I killed about 30 minutes after unsetting the SIGIL_DRAG_DISTANCE_TWEAK by opening several omnibuses and no unwanted file movements were seen when double-clicking.

KevinH · Yesterday, 09:55 AM

Thank you!

BeckyEbook · Yesterday, 09:58 AM

That centering never really bothered me much, but now it's actually a little better, because when you're analyzing files one by one, the list doesn't suddenly shift to center the current file.
Thx!

This also proves that sometimes it's useful to solve a problem that doesn't exist until someone writes about it

KevinH · Yesterday, 02:18 PM

It does. Now if the OP had just provided more info, or at least answered direct questions, it would have sped the fix up considerably.

philja · Today, 04:23 AM

Looking forward to seeing this change in the next release. I never experienced the problem the OP had but when lists shift, it does 'complicate' life.

A similar problem is bugging me at the moment. I have to change a load of illustrations in an epub and every time, I have to suffer a shift in the book browser's display.

My method is to delete the old image by using the right-click on the image's name in the book browser. This alone involves some lengthy scrolling because there are about 100 images.

Next, I click the + icon (using the right-click menu in the browser does exactly the same) and import the replacement image file. The focus in the book browser immediately zaps a 100 miles upwards to the xhtml file I was working on and I have to scroll a 100 miles back down to find the imported image and check/modify its name.

I would much prefer the book browser display stay put as I had it within the images rather than shifting to a text file. This shift becomes annoying when the file numbers are high.

I don't suppose the change made in this thread will improve my case - or will it?

KevinH · Today, 09:23 AM

You really should just use the AddExisting feature, that adding identically named image files will overwrite their namesake.

You are prompted to allow this when adding images. That way there is no need to delete an image first. Just add the new version of the image with the exact same file name.

I will often use FolderOut to get access to all image files, run them through an optimizer or convert from gif to png or png to jpeg in batches, then drag and drop all of them in one go on the Drop Target, then when prompted say Replace to All. No delete needed.

No broken links or even worrying about links that way.

philja · Today, 10:31 AM

Thanks, Kevin. That's given me food for thought.

I had become set in my ways. I'd never seen the prompt to allow replacement because I'd always deleted prior to adding the new file.

So I tried just adding the replacement - I got the prompt and the new overwrote the old just fine.

Just one minor annoyance. If I'm not quick to click the 'yes' button to overwrite, another little s.o.b pops up which won't go away when I click the little 'x'. I can slide it away and continue - so not a problem.

Glad to have learned a new trick.

KevinH · Today, 11:48 AM

Wow, that's a new one. I have never had that happen to me nor even seen it before.

AFAICT it is not part of Sigil's codebase. So either it is something generated by your OS or something Qt is generating. Not sure which. Or maybe it repsents the progress dialog popping up in some distorted way (that is part of the Sigil codebase).

Are you using stock Sigil-2.8.1 or one of the testing builds on Windows that DNSB has built and posted for people? Do you see the same thing on other platforms?

Thanks

Quote:

Originally Posted by philja

Thanks, Kevin. That's given me food for thought.

I had become set in my ways. I'd never seen the prompt to allow replacement because I'd always deleted prior to adding the new file.

So I tried just adding the replacement - I got the prompt and the new overwrote the old just fine.

Just one minor annoyance. If I'm not quick to click the 'yes' button to overwrite, another little s.o.b pops up which won't go away when I click the little 'x'. I can slide it away and continue - so not a problem.

Glad to have learned a new trick.

KevinH · Today, 11:59 AM

Okay, I tried recreating this extra window.

If I use Add Existing ... menu item or Dialog, I get the prompt to replace and I waited 30 seconds and still no extra dialog. So it is not part of the AddExisting Code that itself.

If I instead use the Drop Target, I get the prompt to replace and then if I wait about 15 seconds of no activity, then I finally get that little dialog to pop up but it is always underneath the prompt and so does not interfere or need to be moved to make a choice. And as soon as I make a choice it goes away on its own.

So my **guess** is Qt's Drag and Drop has a built-in timer that is somehow opening this extra information window. Not sure where in the Qt code this is happening. And as far as I know, there is no way to prevent it. But 15 seconds does seem like a reasonable time to make a choice in.

Strange.

11-02-2026, 04:27 PM	#31
KevinH Sigil Developer Posts: 10,179 Karma: 7640000 Join Date: Nov 2009 Device: many	We inherited that snippet from just before Sigil 0.6.0. So it is over 14 years old. https://github.com/Sigil-Ebook/Sigil...62fc9fa722863c Prior to that Sigil at some point started Centering all the time which would make selection a bit too "nervous". But that was back in the Qt 4.X days I think. I think we are safe to change this to EnsureVisible now in Qt 6.x Do you want me to push this change now in time for the release? Last edited by KevinH; 11-02-2026 at 04:31 PM.

11-02-2026, 04:56 PM	#32
DiapDealer Grand Sorcerer Posts: 29,901 Karma: 212736631 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Don't go to too much trouble to track it down. EnsureVisible seems the much more reasonable approach (to me) anyway. EDIT: Whoops! missed your latest post. And unless you foresee any potential pitfalls, I say yes... push the change in time for our upcoming release. Last edited by DiapDealer; 11-02-2026 at 04:59 PM.

11-02-2026, 05:41 PM	#33
KevinH Sigil Developer Posts: 10,179 Karma: 7640000 Join Date: Nov 2009 Device: many	Will push it tonight. Update: This change has now been pushed to master. No translation changes are needed so we should be good to go. Last edited by KevinH; 11-02-2026 at 06:23 PM.

Today, 10:31 AM	#40
philja Evangelist Posts: 448 Karma: 100100 Join Date: Nov 2015 Location: Europe EEC Device: Kindle Fire HD6 & HD8	Thanks, Kevin. That's given me food for thought. I had become set in my ways. I'd never seen the prompt to allow replacement because I'd always deleted prior to adding the new file. So I tried just adding the replacement - I got the prompt and the new overwrote the old just fine. Just one minor annoyance. If I'm not quick to click the 'yes' button to overwrite, another little s.o.b pops up which won't go away when I click the little 'x'. I can slide it away and continue - so not a problem. Glad to have learned a new trick. Attached Thumbnails

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Issue with Browser	Skyde	Amazon Fire	2	12-21-2011 05:16 AM
Browser issue with PB 903	Edria	PocketBook	0	06-29-2011 03:51 AM
Firmware Update Let's get this new window browser issue fixed	nrobertson	Amazon Kindle	14	01-28-2011 03:27 PM
Browser File Download Issue	casualt	enTourage Archive	11	09-15-2010 06:00 PM
Browser issue	niceguyeddy	enTourage Archive	4	04-30-2010 08:23 PM

Yesterday, 12:36 AM	#34
DNSB Bibliophagist Posts: 55,557 Karma: 182544312 Join Date: Jul 2010 Location: Vancouver Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos	My latest test build for Windows can be downloaded from the link in the Downloading Sigil test builds for Windows thread. I killed about 30 minutes after unsetting the SIGIL_DRAG_DISTANCE_TWEAK by opening several omnibuses and no unwanted file movements were seen when double-clicking.

Yesterday, 09:55 AM	#35
KevinH Sigil Developer Posts: 10,179 Karma: 7640000 Join Date: Nov 2009 Device: many	Thank you!

Yesterday, 09:58 AM	#36
BeckyEbook Wizard Posts: 1,086 Karma: 4000129 Join Date: Jan 2017 Location: Poland Device: Various	That centering never really bothered me much, but now it's actually a little better, because when you're analyzing files one by one, the list doesn't suddenly shift to center the current file. Thx! This also proves that sometimes it's useful to solve a problem that doesn't exist until someone writes about it

Yesterday, 02:18 PM	#37
KevinH Sigil Developer Posts: 10,179 Karma: 7640000 Join Date: Nov 2009 Device: many	It does. Now if the OP had just provided more info, or at least answered direct questions, it would have sped the fix up considerably.

Today, 04:23 AM	#38
philja Evangelist Posts: 448 Karma: 100100 Join Date: Nov 2015 Location: Europe EEC Device: Kindle Fire HD6 & HD8	Looking forward to seeing this change in the next release. I never experienced the problem the OP had but when lists shift, it does 'complicate' life. A similar problem is bugging me at the moment. I have to change a load of illustrations in an epub and every time, I have to suffer a shift in the book browser's display. My method is to delete the old image by using the right-click on the image's name in the book browser. This alone involves some lengthy scrolling because there are about 100 images. Next, I click the + icon (using the right-click menu in the browser does exactly the same) and import the replacement image file. The focus in the book browser immediately zaps a 100 miles upwards to the xhtml file I was working on and I have to scroll a 100 miles back down to find the imported image and check/modify its name. I would much prefer the book browser display stay put as I had it within the images rather than shifting to a text file. This shift becomes annoying when the file numbers are high. I don't suppose the change made in this thread will improve my case - or will it?

Today, 09:23 AM	#39
KevinH Sigil Developer Posts: 10,179 Karma: 7640000 Join Date: Nov 2009 Device: many	You really should just use the AddExisting feature, that adding identically named image files will overwrite their namesake. You are prompted to allow this when adding images. That way there is no need to delete an image first. Just add the new version of the image with the exact same file name. I will often use FolderOut to get access to all image files, run them through an optimizer or convert from gif to png or png to jpeg in batches, then drag and drop all of them in one go on the Drop Target, then when prompted say Replace to All. No delete needed. No broken links or even worrying about links that way.

Today, 11:59 AM	#42
KevinH Sigil Developer Posts: 10,179 Karma: 7640000 Join Date: Nov 2009 Device: many	Okay, I tried recreating this extra window. If I use Add Existing ... menu item or Dialog, I get the prompt to replace and I waited 30 seconds and still no extra dialog. So it is not part of the AddExisting Code that itself. If I instead use the Drop Target, I get the prompt to replace and then if I wait about 15 seconds of no activity, then I finally get that little dialog to pop up but it is always underneath the prompt and so does not interfere or need to be moved to make a choice. And as soon as I make a choice it goes away on its own. So my guess is Qt's Drag and Drop has a built-in timer that is somehow opening this extra information window. Not sure where in the Qt code this is happening. And as far as I know, there is no way to prevent it. But 15 seconds does seem like a reasonable time to make a choice in. Strange.