Beta Testers for Sigil-2.3.0 Needed

[retiredbiker]

Originally Posted by KevinH

If you can recreate a sample epub (single page) that shows the issue that would help.

- flashing

- Your previously compiled PageEdit with system Qt should continue to work,

So I tried to make a small epub that would do the preview text-->left thing with a big image; I could not repeat it with a new book. Preview worked perfectly with even huge un-coded images: text properly displayed and put the image off to the right and scrollable.. (I was originally testing on an old, old book that I knew was a mess, so something else likely was wrong. Hardly worth chasing.)

Turned off hardware acceleration and the flashing is gone. Not much acceleration needed in an editor anyway!

PageEdit will not start from within Sigil 2.3...it just ignores clicking on the X. I checked the path and it is OK, and of course I can run PageEdit from the CL.

Cheers!

[DiapDealer]

Originally Posted by retiredbiker

Yep, I turned that off and all the flicker stuff goes away.

The funny start-up screen is still there.

Any debug output when starting Sigil from a terminal? You may see some WebEngine DIR_APP_DICTIONARIES noise, but it can be safely ignored.

I'm assuming you're using the kernel's built-in AMD Radeon drivers? It is my understanding that most people don't resort to proprietary drivers for Radeon like they do for Nvidia.

[DiapDealer]

Originally Posted by retiredbiker

PageEdit will not start from within Sigil 2.3...it just ignores clicking on the X. I checked the path and it is OK, and of course I can run PageEdit from the CL.

This doesn't surprise me now that I think about it. If both were using the system Qt, this would just work. But the Sigil launch script diddles $LD_LIBRARY_PATH in order to force the usage of the Qt that sigil was built with. In this case that's 6.7.2. But PageEdit was built against 6.2.4 and is being forced to abide by the current $LD_LIBRARY_PATH that Sigil set.

Let me look at how Sigil launches PageEdit.

[retiredbiker]

Originally Posted by DiapDealer

Any debug output when starting Sigil from a terminal? You may see some WebEngine DIR_APP_DICTIONARIES noise, but it can be safely ignored.

I'm assuming you're using the kernel's built-in AMD Radeon drivers? It is my understanding that most people don't resort to proprietary drivers for Radeon like they do for Nvidia.

No, all the terminal gives is

Debug: initial styleHints colorScheme:  Qt::ColorScheme::Light
Warning: Path override failed for key base::DIR_APP_DICTIONARIES and path '/usr/local/lib/sigil/qtwebengine_dictionaries'
Path override failed for key base::DIR_APP_DICTIONARIES and path '/opt/qt6/6.7.2/gcc_64/libexec/qtwebengine_dictionaries'
Path override failed for key base::DIR_APP_DICTIONARIES and path '/opt/qt6/6.7.2/gcc_64/libexec/qtwebengine_dictionaries'

No, I never touch the video drivers. This box is from System76 and less than a year old, so I can't see the video becoming obsolete...but who knows in this world!

I do have a non-standard monitor: it is a 42-inch TCL 4K television, run through the hdmi port. It has never given any problems, though.

[DiapDealer]

Originally Posted by DiapDealer

This doesn't surprise me now that I think about it. If both were using the system Qt, this would just work. But the Sigil launch script diddles $LD_LIBRARY_PATH in order to force the usage of the Qt that sigil was built with. In this case that's 6.7.2. But PageEdit was built against 6.2.4 and is being forced to abide by the current $LD_LIBRARY_PATH that Sigil set.

Let me look at how Sigil launches PageEdit.

Yeah... I need to probably change how Sigil launches the external xhtml editor on Linux. With PageEdit, it will be simple enough to pop the LD_LIBRARY_PATH that Sigil adds to the environment before launching, but I'm not sure that will be a great idea for all externally-launched xhtml editors. Have to do some thinking.

In the meantime, a simple workaround (without needing to rebuild PageEdit with 6.7.2) is to create a bash script named pageedit.sh (the pageedit basename is important) with the following contents:

#!/bin/sh

# Unset LD_LIBRARY_PATH so PageEdit can use its own Qt
unset LD_LIBRARY_PATH

exec pageedit "$@"

Save it somewhere and mark it as executable. Then use Sigil's preferences to choose it as the external xhtml editor (rather than PageEdit's binary).

If you do end up rebuilding pageedit with the alternate Qt6.7.2 version. You'll need to go back to calling the pageedit binary directly, because this workaround script won't work.

[retiredbiker]

Originally Posted by DiapDealer

In the meantime, a simple workaround (without needing to rebuild PageEdit with 6.7.2) is to create a bash script named pageedit.sh (the pageedit basename is important) with the

If you do end up rebuilding pageedit with the alternate Qt6.7.2 version. You'll need to go back to calling the pageedit binary directly, because this workaround script won't work.

Thank you, this works perfectly. How to remember it at some later date is more problematic...!

[DiapDealer]

Originally Posted by retiredbiker

How to remember it at some later date is more problematic...!

Notes. Copious notes that fade, get lost, and become pointless.

[DNSB]

I've ended up with notes that are much larger than the code and source code files that 75% comments so I can have a chance to figure out just what was I doing when I wrote this a few years back.

[theducks]

My coding days were long before things like GITHUB.
I also started many coding tasks by writing basic comments (pseudo code), then making code to get the job done.

I remember looking at some of my early code and remarking 'I wrote that mess!' We made progress toward more 'Elegant' code.

[philja]

I've downloaded the .exe of 2.3 beta for my W10 (up-to-date) box and it appears to work fine with the first couple of ePubs I've tried.

One little thing surprised me: it takes a double-click on a file in the Book Browser pane to open that file for editing. I checked back on my Sigil 2.2.1 on my linux box and there it is a single click. This may be an OS thing but I do have my W10 box set to open all files with a single click (have done so for years).

I rarely use the W10 box so Sigil may always have been like that in Windows. I haven't had time to try to build 2.3 on linux yet.

[DiapDealer]

I've never enabled single click in Windows, so I wouldn't know past behavior. I do know that the single-click feature of KDE used to cause nasty problems with Sigil years ago. I just can't remember what they were. It may have been resolved since.

[KevinH]

And nothing changed in that regard. To use BookBrowser to open a CodeView Tab always required a double click otherwise there is no way to select sets of files in BookBrowser for Find and Replace, renaming, specifying which are selected to pass to the Plugins, etc.

[DiapDealer]

Originally Posted by KevinH

To use BookBrowser to open a CodeView Tab always required a double click otherwise there is no way to select sets of files in BookBrowser for Find and Replace, renaming, specifying which are selected to pass to the Plugins, etc.

THAT was the issue I remember. Too many things relied upon clicking without opening.

[KevinH]

Yes all throughout Sigil.

[philja]

I've found another weird behaviour with the Sigil 2.3.0 version on W10 Pro. It's a display problem.

My W10 and linux boxes share a single display, keyboard and trackball. I pass from one to the other by a click on a KVM switch and this has worked nicely for a long time with occasional changes in hardware.

The present combination of switch, screen, keyboard and trackball has been working smoothly for a couple of years. I left Sigil 2.3 running in the W10 to go back to linux Sigil 2.2.1 to check the shortcuts for changing focus between the panes to achieve commonality between the 2 builds.

[ I also removed the attribution of F2 to launch the external HTML editor as recommended in this thread: https://www.mobileread.com/forums/sh...=357198&page=4
because the behaviour was the same as previously noted in linux ]

When I switched back to W10, Sigil had lost its menu bar. I could still access the items by starting with Ctrl+F and using the arrow keys. It was just the display that was affected.

It makes no difference whether the Sigil window is full screen or not. And the time out from W10 to linux seems not to be important. It happens systematically every time I move back and forth between machines.

To get the menu bar back, I just need to provoke the system to redraw by sticking the cursor in the title bar and dragging or by clicking the minimise, full screen icons.

Over the years, I've never seen this with any other application. Would you think it's a Qt problem?