Improvements? New Features? post sigil 2.7.6

[DiapDealer]

Originally Posted by KevinH

7. fix issues related to dark mode and Sigil's native dark mode theme on windows
when trying to identify the active tab (without needing qss styling)
(this is still open and waiting to see how it resolves with Windows users)

I'm still not comfortable with applying the blue highlights to the active tabs. Any changes I make to our various stacked styles seems to adversely affect the widget highlighting applied in main.cpp. I'm still leaning toward simply making the active tab slightly darker. Or just making the active tab's text a light blue that would work for both dark and light themes. Windows only at this point. The other option is to do nothing, since most of those who seem to want/need it have already adopted some sort of custom .qss to handle it themselves. I just don't see this as something that significant number of users would benefit from.

[KevinH]

Originally Posted by jugaor

Hi.


Thanks, a fantastic improvement!
One question/suggestion (aka suquestion): is there any way to configure prettyprint.xml to wrap lines at <br / > tags? (like it used to do in pre-Gumbo Sigil).
Often, especially with third-party epubs/imports from word processors/copy-pasted content from websites, these tags appear, and it would be visually easier if they were clearly marked in code view.
(Fingers crossed)


Since this was initially my request, with my limited qss skills (enhanced by BeckyEbook’s suggestions), I've already solved it.
If it's still open because of me, please feel free to close it.

Have you tried removing the br tag from this list of inline tags in prettyprint.xml found in your Sigil Preferences folder, then restarting Sigil 2.8.0 test build?

" <!-- Inline tags have no added space nor newlines -->\n"
" <inline_tags>\n"
" a, abbr, acronym, b, bdo, big, br, button, cite, code, del, dfn, em,\n"
" font, i, image, img, input, ins, kbd, label, map, mark, mbp:nu, mi,\n"
" mn, mo, ms, mspace, mtext, msub, msup, msubsup, nobr, object, q,\n"
" ruby, rp, rt, s, samp, select, small, span, strike, strong, sub,\n"
" sup, textarea, tt, u, var, wbr\n"
" </inline_tags>\n"

Does that do what you want?

Even if it does, forcing a newline after a br tag and then indenting means you have force-added a single-space immediately before the text that comes after the br, which can change things. So not a safe change in many cases.

Perhaps a saved search you control to inject a newline after the br would be safer choice then trying to treat inline tags as non-inline.

[Neilcole]

Great to see continued updates on Sigil 👍
Real-time EPUB validation and better error highlighting would really help users.
Also, a bit smoother navigation and preview would improve the overall experience.

[KevinH]

Originally Posted by Neilcole

Great to see continued updates on Sigil ��
Real-time EPUB validation and better error highlighting would really help users.
Also, a bit smoother navigation and preview would improve the overall experience.

But you have said nothing specific? Just "generalities" that could be said about any software project. That does not really help. But I see you are a new user with only a single post here on Mobileread (this one) so I will try to explain more - assuming you are not just an AI generated post as initial posts filled with only generalities is quite typical of AIs.

For example, exactly when, how, and what should be added to do real-time epub validation understanding that the epubcheck plugin exists for that reason. Broken code shows up immediately in Preview and always has. What exactly do you want validated that can not be done with the epubcheck plugin?

FWIW, well-formed errors are immediately highlighted right in Preview and other errors are presented in the validation pane when running css validators, well formed checks, or epubcheck plugins.

Again, "smoother navigation" is not helpful. Be specific about what you want to change when navigating inside Sigil, remembering that over the last 15 years of use people have developed muscle memories for using Sigil. So change for the sake of change is not desirable. There are already user assignable shortcut keys for those users preferring keyboard based navigation, and normal gui and menus for gui users. Sigil already has user controllable dockable Windows, tabs, etc.

And Preview already exists and is built in. And there are already 3 e-reader plugins for Sigil that can show you how your epub looks in a e-reader but testing using standalone e-readers is always required before you publish your epub.

Please make specific clear suggestions for improvements and they will be considered, vague general ones will not.

So please give your suggestions some thought and make them as specific as possible showing clearly what you want to change, and justify why that change would help a majority of users. And also make sure you have considered what is available via our Sigil plugins as duplicating what already exists in plugins is off the table (as was clearly explained in the leading post in this thread).

[avidcoder]

Hello, Kevin. A huge thanks to you and the other developers who have created and maintain Sigil. The only improvement I can think of at this point would be to rectify the following issue:

Within the primary content pane (between the Book Browser and Preview panes), when multiple pages are displayed, they have tabs on top of each, organized horizontally and labeled with the file names. As expected, each page can be accessed by clicking its tab, or by pressing the Control key and then tapping Page Up or Page Down. Unfortunately, when the user does Ctrl + Page Up (or Page Down), the focus shifts to the window to the right of the current window (or the one to the left). This is the opposite of the directions seen in every other software application I have ever encountered. For instance, in all worksheet programs, such as Excel, pressing Ctrl + Page Up switches focus to the worksheet just to the left of the current one, and pressing Ctrl + Page Down goes to the worksheet to the right. The same behavior is seen in all web browsers' tabs. It would be wonderful to change the direction of Ctrl + Page Up/Down within Sigil to match what users have learned to expect from likely all of their other programs that have tabs.

[KevinH]

You actually control the keyboard Shortcuts that perform the Next Tab and Previous Tab functions.

Go to Sigil's menubar and select Preferences and then open the Shortcut Preferences and swap those key assignments for Next Tab and Previous Tab (or assign other shortcut keys).

Given it has been 15 years with the current assignments, I am loathe to change the defaults, but once you have set your preferred shortcut keys they will always be remembered as they are stored in ini files in your Sigil Preferences folder.

FWIW, I never actually use either Next or Previous Tab to select a tab, I just double click in BookBrowser and if that file has a tab it is brought to the centre, if not a new tab is properly opened.

Hope this helps.

Update:

Since the settings ini files store this setting, changing the default will only impact completely new users (or users who manually delete the entire Sigil settings folder). So I went ahead and swapped those two shortcuts default settings. Current users who want that change will have to use Sigil's shortcut Preferences to change those shortcuts if they so desire. Thank you for the head's up!

Originally Posted by avidcoder

Hello, Kevin. A huge thanks to you and the other developers who have created and maintain Sigil. The only improvement I can think of at this point would be to rectify the following issue:

Within the primary content pane (between the Book Browser and Preview panes), when multiple pages are displayed, they have tabs on top of each, organized horizontally and labeled with the file names. As expected, each page can be accessed by clicking its tab, or by pressing the Control key and then tapping Page Up or Page Down. Unfortunately, when the user does Ctrl + Page Up (or Page Down), the focus shifts to the window to the right of the current window (or the one to the left). This is the opposite of the directions seen in every other software application I have ever encountered. For instance, in all worksheet programs, such as Excel, pressing Ctrl + Page Up switches focus to the worksheet just to the left of the current one, and pressing Ctrl + Page Down goes to the worksheet to the right. The same behavior is seen in all web browsers' tabs. It would be wonderful to change the direction of Ctrl + Page Up/Down within Sigil to match what users have learned to expect from likely all of their other programs that have tabs.

[DNSB]

Link deleted

[User_Z]

Thank you.
I've corrected a few things.

[KevinH]

Originally Posted by User_Z

Thank you.
I've corrected a few things.

At least one more round of translation updates is coming.

[BeckyEbook]

Two points:
1. I'm wondering about the usefulness of coordinates in the image tab. They might be somewhat helpful when cropping, of course, but in my opinion, coordinates only make sense when the scale is set to 100%.

Sure, they can stay there, but I'm just wondering how they might be useful to me.



2. I’ve written about this before and we added if (cp == -1) return QString("EOF");. However, when I jump to the very end of an XHTML file in the CodeView window, I get the U+-001 code for EOF.
In that case, should we just remove the U+XXXX code entirely?
I know it’s just a minor aesthetic issue, but when I’m at the end of the file, my eyes always see that -001.
I know this is yet another string to translate, but since there’s going to be one more round…

Spoiler:

void MainWindow::UpdateCursorPositionLabel(int line, int column, int codepoint)
{
    QString name = "";
    if (line > 0 && column > 0) {
        QString name = CodepointNames::instance()->GetName(codepoint);
        const QString l = QString::number(line);
        const QString c = QString::number(column);

        QString text;

        if (codepoint > 0) {
            const QString cp = QString("U+%1").arg(codepoint, 4, 16, QLatin1Char('0')).toUpper();
            text = tr("%1 (%2) - Line: %3, Col: %4").arg(name).arg(cp).arg(l).arg(c);
        } else {
            // EOF
            text = tr("%1 - Line: %2, Col: %3").arg(name).arg(l).arg(c);
        }

        m_lbCursorPosition->setText(text);
        m_lbCursorPosition->show();
    } else {
        m_lbCursorPosition->clear();
        m_lbCursorPosition->hide();
    }
}

[KevinH]

Based on a recent Sigil bug report, Sigil's decision to keep the nav in the spine with linear="no" is not what some epub dev's want. Other options are to remove the nav from the spine completely (assuming you have an normal xhtml toc and have no links to anything from the nav itself). Or style the nav so it can be used as the xhtml TOC to present to the reader which means removing the linear="no" from the nav item in the spine.

If you understand the OPF, you can easily make this change directly by editing the OPF directly in CodeView. They are simple changes.

But many people who edit their epubs are not as experienced in the epub OPF format or do not feel comfortable hand editing the OPF.

To make things worse, using Sigil's tools which update the OPF like renaming, removing, moving, adding files, adding covers will happily add back the nav to the spine to prevent "errors" (with linear="no").

So should Sigil add 2 new epub3 tool menu items?

1. Save epub with Nav not in the Reading Order
2. Save epub with Nav replacing the reader's Table of Contents

Alternatively we could easily create a Sigil output plugin for each of these options.

I am leaning toward the plugin approach as most experienced users know what the OPF is for and know how to edit the OPF spine to achieve what they want without need for new epub3 menu items. They can also choose to not install the plugins.

But new users could easily add the plugins to do what they want without ever having to direct edit the OPF before their final save.

Thoughts?

[KevinH]

Originally Posted by BeckyEbook

Two points:
1. I'm wondering about the usefulness of coordinates in the image tab. They might be somewhat helpful when cropping, of course, but in my opinion, coordinates only make sense when the scale is set to 100%.

Sure, they can stay there, but I'm just wondering how they might be useful to me.

Zooming in and out should still show unscaled coordinates which are useful for cropping. The coordinates should represent pixels in the actual image not impacted by zooming in or out.

If you officially scale the image the coordinates should be updated automatically.

2. I’ve written about this before and we added if (cp == -1) return QString("EOF");. However, when I jump to the very end of an XHTML file in the CodeView window, I get the U+-001 code for EOF.
In that case, should we just remove the U+XXXX code entirely?
I know it’s just a minor aesthetic issue, but when I’m at the end of the file, my eyes always see that -001.
I know this is yet another string to translate, but since there’s going to be one more round…

Spoiler:

void MainWindow::UpdateCursorPositionLabel(int line, int column, int codepoint)
{
    QString name = "";
    if (line > 0 && column > 0) {
        QString name = CodepointNames::instance()->GetName(codepoint);
        const QString l = QString::number(line);
        const QString c = QString::number(column);

        QString text;

        if (codepoint > 0) {
            const QString cp = QString("U+%1").arg(codepoint, 4, 16, QLatin1Char('0')).toUpper();
            text = tr("%1 (%2) - Line: %3, Col: %4").arg(name).arg(cp).arg(l).arg(c);
        } else {
            // EOF
            text = tr("%1 - Line: %2, Col: %3").arg(name).arg(l).arg(c);
        }

        m_lbCursorPosition->setText(text);
        m_lbCursorPosition->show();
    } else {
        m_lbCursorPosition->clear();
        m_lbCursorPosition->hide();
    }
}

Seeing the U-001 is just fine with me. I really do not see the issue given we have said it is EOF.

Not sure why this bothers anyone as it is an edge case that indicates no legal Unicode char is available. I am fine leaving it as is, but if it bothers enough people, we can change it but ...

[BeckyEbook]

Ad 1.

Zooming in and out should still show unscaled coordinates

Hmmm…
Perhaps I have a different understanding of "unscaled coordinates."



Ad 2.
OK.

[KevinH]

Actually I can't read your image where the red arrow points. I will double check on my machine that the coordinate x, and y positions are unzoomed when zoom is being used. I probably just missed a divide by zoom factor there. When cropping the unzoomed coordinates are properly used, just the status bar seems to need to be unzoomed..

[KevinH]

Okay, I have just pushed to master a fix so that the x,y image coordinates are always adjusted for the zoom scale factor.

This makes zooming before cropping more useful as does knowning where you are in any image (from a pixel basis), no matter the zoom level.