Suggestions for Sigil Improvements or New Features

[DiapDealer]

Originally Posted by KevinH

I did look at the code and there is a QStyle Hint that seems to be platform specific that may impact this. Not sure if I can change it for the Qt Windows theme without moving to Fusion.

Windows Sigil already uses the Fusion theme as its base:

https://github.com/Sigil-Ebook/Sigil.../main.cpp#L598

Or did you mean something else?

[KevinH]

Originally Posted by DiapDealer

Windows Sigil already uses the Fusion theme as its base:

https://github.com/Sigil-Ebook/Sigil.../main.cpp#L598

Or did you mean something else?

Even Fusion always descends on right arrow.

It is so silly. Deep inside QTreeView in a routine called moveCursor there is the following stylehint:

bool descend = style()->styleHint(QStyle::SH_ItemView_ArrowKeysNavigateIn toChildren, nullptr, this);

We need that style to always return false for the MetaEditor QTreeView but not for any other one in a different class.

I am just not sure how to go about it as the moveCursor routine can be overridden but the damn thing uses too many Qt private methods and I can not replicate its logic so I can not easily override it with our own MetaEditorTreeView::moveCursor routine.

So we can force a stylehint for Windows and some Linux (but we already do that at times and it leads to a mess especially on Windows with all the astyles and bstyles and stuff) but that would not be correct for all tree views.

I can not override the damn QTreeView::moveCursor routine since it uses a bunch of Qt private methods, handles visibility and updates the viewport when collapsing or expanding an entry. I do not know how to do all of that without using Qt private header routines.

This is just so stupid.

Update: It turns out the moveCursor routine is invoked from the keyPressEvent routine, so I will try overriding it there. Why on earth Qt defaults to the right and left arrow keys doing strange things here is beyond me. At least MacOS is sane here.

[BeckyEbook]

@KevinH: I would like to return to the issue SIGIL_ONLY_USE_LANGCODES described in post #120.
The current implementation has a side effect, which is that the UI language list is missing information, because when we limit the list of languages, it is done globally – for the entire Sigil.

Screenshot:


So I suggest partially incorporating Doitsu's latest suggestion from post #6 and meeting halfway: let's add at least those languages that have translations for the Sigil interface to the list of languages declared in the environment variable.

I have a working solution that you can certainly optimize.
The result is an expanded list of languages, which of course also appears in the metadata editing window:



I already have an updated EnvVarEditor plugin that supports the new environment variable, but I want to test it a little more before the official release. The language validation function will not allow duplicates or incorrectly written language codes. IMVHO – it works great and really makes my life easier.

[KevinH]

Yes I noticed that too but ...

-what happens if Sigil's list of UI languages gets longer aren't we back to the original problem?

- anyone advanced enough to use this environment var to restrict language codes should include their ui language code, shouldn't they? None of the others ui codes should matter as their code is there just not the translations..

And fwiw instead of merging, a simpler solution might be to check if a data item is in ui language list codes OR in the user code when user codes are specified. That saves building a merged list and that extra routine.

So I am not sure this is something to worry about, but if you feel strongly, then please create a PR using the OR approach and I will merge it.

Thanks!

Originally Posted by BeckyEbook

@KevinH: I would like to return to the issue SIGIL_ONLY_USE_LANGCODES described in post #120.
The current implementation has a side effect, which is that the UI language list is missing information, because when we limit the list of languages, it is done globally – for the entire Sigil.

Screenshot:
Attachment 218666

So I suggest partially incorporating Doitsu's latest suggestion from post #6 and meeting halfway: let's add at least those languages that have translations for the Sigil interface to the list of languages declared in the environment variable.

I have a working solution that you can certainly optimize.
The result is an expanded list of languages, which of course also appears in the metadata editing window:
Attachment 218667
Attachment 218668

I already have an updated EnvVarEditor plugin that supports the new environment variable, but I want to test it a little more before the official release. The language validation function will not allow duplicates or incorrectly written language codes. IMVHO – it works great and really makes my life easier.
Attachment 218669

[BeckyEbook]

I agree with that, of course. If someone consciously uses environmental variables, they should be aware of their impact on various Sigil functions.
A worse situation also occurs when the main language of the EPUB file itself is not on the list of codes, because then the only option is to edit the OPF file directly.
Let's leave it as it is for now, and let my post serve as a reminder for posterity that we are aware of this minor imperfection.

[BetterRed]

Originally Posted by KevinH

Okay I will take a shot at a Context Menu.

Thanks.

Originally Posted by KevinH

As for the "irritant" behaviour is built directly into the QTreeView class so it will take some work to subclass QTreeView and try to control how it work. Work that only seems to need to be done for Windows. I will see if that damn QStyleHint change will work.

Don't worry about it - working through it slowly to take the screen shots has given me an insight into what is happening and why… now I have that, the 'apparently' odd behaviour won't bother me.

Instead I'll probably waste my time looking for discussion on navigating a GUI representation of a hierarchical table with the keyboard - maybe ChatGPT knows

BR

[BetterRed]

Originally Posted by KevinH

@BetterRed
I took a shot at adding a short context menu to the Metadata Editor entire QTreeView.

See the screenshot below.

Perfect.

Originally Posted by KevinH

As for your "irritant" it appears to be an real "irritant" to me too as there is no easy way to make Windows work like MaOS without changing its theme.

So fixing this irritant may take some work, and might not be part of the next release.

See previous post.

BR

[KevinH]

Okay I have pushed to normal Sigil master the following changes:

1. Add context menu for MetaEditor

2. Add 2 new conditional Automation commands:
- OnFailedRunSavedSearchReplaceAll
- OnSuccessRunSavedSearchReplaceAll

3. Add a MetaEditorTreeView (subclass of QTreeView) so that right and left arrow keys function uniformly and as expected on all platforms inside MetaEditor (ie. fix the irritant)

This should finish all new feature requests that were accepted. Assuming all goes well, I will be posting Beta builds of Sigil 2.7.0 for people to try.

If you were a requestor or supporter of one of these new features, please do test and report back any issues you encounter.

From here on out work for the next release will be limited to testing and bug fixes as we do not want any of the new features to introduce any bugs.

I will add a link to this thread when all of the Beta builds are ready and posted to my BuildSigilOnMac release site.

[KevinH]

Okay, the CI Beta builds with all of the new features can be found here:

https://github.com/kevinhendricks/Bu...nMac/releases/

The files are named:

Sigil-2.7.0-Beta-Windows-x64-Setup.exe

Sigil-2.7.0-Beta-x86_64.AppImage

Sigil.app-2.7.0-Beta-Mac-arm64.tar.xz

Sigil.app-2.7.0-Beta-Mac-x86_64.tar.xz

Please note, the two MacOS builds are fully signed BUT are *not* notarized since these are not final release builds.

Please help test things. Aside from the new features, these should be rock solid.

[BeckyEbook]

Along with Sigil version 2.7.0 beta, you can also test plugin EnvVarEditor version 1.9.0 beta, which supports the new environment variable SIGIL_ONLY_USE_LANGCODES.

[philja]

I've loaded the 2.7.0 beta for Mac arm and all's good so far. I had to reread the thread to see where the Automate feature had vanished to, but I've got it working.

I made a new automation to run 2 saved searches:
1. for un-prettifying tables
2. h4 to h3, from the saved search examples.

My un-prettifying saved search ran ok but the automation couldn't recognise the name of the heading change search, even when it was copy/pasted from saved searches.

RunSavedSearchReplaceAll h4 to h3 running
Missing or unknown Saved Search name: RunSavedSearchReplaceAll h4 to h3
RunSavedSearchReplaceAll h4 to h3 failed
Automation List Failed

'h4 to h3' worked fine outside the automation when directly loaded from saved searches.

[KevinH]

When ever you run a saved search in automation you must use it full name path including any groups it is in. And all saved search groups names end with a / whereas a single search is just a name.

You can always look in your saved search v6 ini file to see the exact full name.

My guess is your h4 to h3 is in the examples saved search group so its full name is probably "examples/h4 to h3" whereas your unprettify one is not. You can of course use the saved search editor to change groups of individual search and replaces.

[philja]

Originally Posted by KevinH

When ever you run a saved search in automation you must use it full name path including any groups it is in. And all saved search groups names end with a / whereas a single search is just a name.

You can always look in your saved search v6 ini file to see the exact full name.

My guess is your h4 to h3 is in the examples saved search group so its full name is probably "examples/h4 to h3" whereas your unprettify one is not. You can of course use the saved search editor to change groups of individual search and replaces.

My bad then. I guessed it would be something of that nature.