New Features or Improvements post Sigil 2.8.1

[KevinH]

Just like last time, I am opening a thread to collect ideas for improvements and/or new features for Sigil.

The same caveats still exist:

- not something better done in a Sigil plugin

- only things that will help the majority of users

- no "super editor" features better handled with "Open With" and your favourite editor

- no vague generalities. Please be as specific as possible with what you want, and the reasons it would be useful to others.

So if you have a suggestion that meets these criteria then please add it to this thread and make an argument for its usefullness.

Not all suggestions will be accepted, if fact many will be rejected for technical or user interface reasons, but if we accept your suggestion, I will work on adding it to Sigil for an upcoming future release.

Also please feel free to comment on the merits or issues associated with any suggestion made here so that everybody is informed.

Thank you.

[icearch]

Advanced TOC manipulation as in:

https://www.mobileread.com/forums/sh...d.php?t=373669

this thread.

[KevinH]

And here was my reply:

But to be clear, I can not see it as something most users would need or want.

Plus making the changes in the xhtml source using regex and then regenerating the TOC from the headers is generally the right thing for producing epubs for Accessibility and semantics.

So I am not personally in favour of adding that feature.

But as promised, let's wait to hear what others think before coming to any definitive conclusion.

[icearch]

sure thing

[DNSB]

For me personally, part of my editing workflow is to either to correct mis-used headers or to add the code needed to use headers. This allows me to generate clean navigation documents and saves me from causing myself issues by accidentally hitting the generate ToC button.

I feel the request made would simply be slapping a coat of makeup on to hide the issue and not have the ToC setup fixed. One tool that might help some with doing this is the ReworkChapterHeaders plugin.

[philja]

Here is a suggestion for MacOs only, which I believe will save time for users by enabling them to open a recent file directly in Sigil from the Dock.

When you right-click an icon in the MacOs Dock, some applications expose a list of recently opened files. Clicking on a selected file will open it directly in the application. This saves the need to hunt the file in a browser window and then double-click to open it.

See the attached image for examples in LibreOffice Writer and Scrivener applications. You will notice an entry in the bubbles, 'Show Recent'. This is not, in my opinion, useful because if no files are shown in the top part, no files will be shown if you select 'Show Recent'. If files are shown in the top part of the bubble, clicking on the 'Show Recent' produces a horizontal display of larger icons just above the Dock, with the same files that were listed in the bubble.

At present, Sigil does not expose any recent files, and I suggest that it should.

[KevinH]

One question:

if LibreOffice or Scrivener app is completely shutdown (not open and operating in the background) does this feature still work? If so, it is a operating system feature keeping track of what files you used recently not an application feature that keeps track of recent files it loaded.

That macOS feature would not be part of Qt cross-platform support as Qt does not use macOS os system calls to load files so tracking by the OS would not be done.

However if this open recent file feature only works once the program has been initially launched by the user when it shows up in the active part of the dock, then it is an application based feature and that we may be able to recreate.

Unless there is a hidden macOS way to register files an App opens after the fact so they are somehow available to the OS when the actual application is not running.

Either way this feature would not be cross platform at all.

[KevinH]

Update.

Yes this list is maintained at the MacOS level and not the application level. It requires some objective-c interface code and people have to by willing to have their application file usage be tracked by the OS.

I will have to think about this. It would be easier to interface our own recent files to the empty app window as is already done in each MainWindow and not allow macOS to track things. Not sure.

[philja]

Originally Posted by KevinH

One question:

if LibreOffice or Scrivener app is completely shutdown (not open and operating in the background) does this feature still work? If so, it is a operating system feature keeping track of what files you used recently not an application feature that keeps track of recent files it loaded.

That macOS feature would not be part of Qt cross-platform support as Qt does not use macOS os system calls to load files so tracking by the OS would not be done.

However if this open recent file feature only works once the program has been initially launched by the user when it shows up in the active part of the dock, then it is an application based feature and that we may be able to recreate.

Unless there is a hidden macOS way to register files an App opens after the fact so they are somehow available to the OS when the actual application is not running.

Either way, this feature would not be cross platform at all.

Yes the same recent files are exposed by the Dock icon whether or not the application is open. If the application is open, the Dock icon stays in the same place but has a small dot beneath it - in this case, the bubble does not show a clickable 'Show Recents' item but still exposes the file names in the upper part.

I systematically quit creative applications because the files I use are inevitably up in Dropbox with all the risks of having a file open in two places at once.

Of all the applications I use, the only two which support this feature are LO and Scriv. LO holds a list of 19 recent files but MacOs only exposes 10. My Scrivener only has 4 recent files and they are all exposed by MacOs.

How can they do so?

EDIT: your additional info crossed with my post. Aren't we accustomed to being tracked all over these days?

[democrite]

I vote too for icearch's suggestion of TOC editing. I think there might be perhaps some mis-understanding. Perhaps for various reasons one might have any number of consecutive headings that need simultanous changing of heading level.

- his converting of something I forgot, creates a book with all H1.
- commercial EPUBs might have a flat TOC where section 1, 2, 3, etc. plus all chapters within each section or part are all H1 (maybe this is also exactly his issue)
- other times front matter might be all H2 under a H1 "Front matter".

In this case one can select any number of consecutively listed headings and merely drag and drop on top of another heading to make it one level below, or drag differently to move them up a level such as to H1. Keyboard controls for such I don't know if that'd work. Being able to select multiple conseutive bookmarks or TOC entries and drag somewhere to change level or position, that is how most PDF app TOC editors work. Acrobat, various others, maybe all PDF apps that support TOC editing work that way. So in that sense, I think that's what he's asking for.

[KevinH]

Yes, but the point is for Accessibility you should instead use regular expressions to change the actual h1-h6 tags to be correct headings and then simply recreate the TOC and not just change the TOC.

I think the difference in philosophy is based on people who use Sigil to create professional grade epubs for publishing versus people who just like to edit the epubs they buy for their own reading use.

I will look into this to see what it might take.

[KevinH]

Originally Posted by philja

Yes the same recent files are exposed by the Dock icon whether or not the application is open. If the application is open, the Dock icon stays in the same place but has a small dot beneath it - in this case, the bubble does not show a clickable 'Show Recents' item but still exposes the file names in the upper part.

I systematically quit creative applications because the files I use are inevitably up in Dropbox with all the risks of having a file open in two places at once.

Of all the applications I use, the only two which support this feature are LO and Scriv. LO holds a list of 19 recent files but MacOs only exposes 10. My Scrivener only has 4 recent files and they are all exposed by MacOs.

How can they do so?

EDIT: your additional info crossed with my post. Aren't we accustomed to being tracked all over these days?

I have found an objective-c code snippet that might be workable. I will run some tests to see how doable this is. But be aware, that the App specific recent files will be inconsistent with any macOS generates until enough time has passed for the history to "catch up", if we do decide to include this.

[icearch]

Originally Posted by KevinH

Yes, but the point is for Accessibility you should instead use regular expressions to change the actual h1-h6 tags to be correct headings and then simply recreate the TOC and not just change the TOC.

I think the difference in philosophy is based on people who use Sigil to create professional grade epubs for publishing versus people who just like to edit the epubs they but for their own reading use.

I will look into this to see what it might take.

I totally get your opinion, and admit it is the correct and morally good way to do to perfectly.

But just as I mentioned in the thread, It is just not feasible to correct every mistake on the Internet as we only have limited time and effort, sometimes adequate is enough.

Maybe you are concerning this will encourage formatters to behave badly? That does not work, since with or without this advanced function, bad epubs still floating around the Internet. Making this feature only allows those with good intent but poorly skilled ones to do more right things, even if not perfect, more easliy and safer.

If you just didn't want to do it because you perfer this way or it contradict your value, it's fine, like nobody can force you to do something, we are only suggesting.

The core reason I want this feature is that coding in nav or toc is highly risky and tends to cause errors. It better be handled by professionals and behind the curtain.

Accessbility is definitely an important thing, but people without the need still deserve some handy feature to boost their efficiency right? Damage has already been done by those bad formatters and auto-conversions, it can only go upwards, and it's helpful if we can have something handy right?

You may come up with better solutions, like have an option that not just change the nav, but back-link it in the text and change it's heading levels as well, so it's accessiblity correct.

As to regex text to make it correct, it does not always work, it can have no useable patterns, or even doesn't have h* tags at all, just p with a link, there will only be more nasty.

[KevinH]

Originally Posted by KevinH

I have found an objective-c code snippet that might be workable. I will run some tests to see how doable this is. But be aware, that the App specific recent files will be inconsistent with any macOS generates until enough time has passed for the history to "catch up", if we do decide to include this.

It was easy enough to try this change on my own Mac as we already have one objective-C .mm file of code used in Sigil on a Mac and so adding that code snippet to it was straightforward.

I then ifdef'd some code in MainWindow.cpp where Sigil keeps track of its own recently opened files to use this snippet but only on a Mac.

If you build your own on MacOS, I have attached a patch and a screenshot showing the dock when *no* Sigil app is running.

Note: I have only opened two epubs in the Sigil version built with this patch, so its recent files in the dock is not as complete as the Sigil recent files menu, but they will sync over longer term use.

So unless these changes cause side-effects, this should be doable.

[KevinH]

Originally Posted by icearch

As to regex text to make it correct, it does not always work, it can have no useable patterns, or even doesn't have h* tags at all, just p with a link, there will only be more nasty.

There is already a plugin I wrote a long time ago that will save an existing TOC into the code that will add the approriate heading tags as used in the TOC.

But it would still have an issue with an incorrect TOC to begin with.

Again, as I said earlier, I will look into seeing how doable this is. If this does *not* require lots of changes to our existing TOC editor, then I will go ahead and add it, but I still think its use is very broken. I can only see using it for personal use, not professional epub creation as Accessibility is key to modern epubs publishing philosophy, especially in Europe and elsewhere.

So no promises.