Suggestions before releasing version 1.0

[BeckyEbook]

Kevin suggested that I write a new post on this topic.

I have been observing Sigil's development for years. I run it almost every day. I like to adapt tools to my needs.
There are a few small things that may be worth changing before launching a milestone in the development of Sigil – version 1.0.
Write what you think about these suggestions under this post. If something seems pointless – just write. And if something is neutral or seems acceptable – write also.

All proposals are purely aesthetic and may be of low priority, but life is made of little things.

1. Question mark in dialog boxes

Since Sigil does not use QWhatsThis – I suggest to disable the question mark globally. Many of you will ask "what's going on?"
Well, the question mark is in the title bar in Windows in most windows that pop up in Sigil (eg About, Settings ...).

It's about that question mark:

#ifdef Q_OS_WIN32
QApplication::setAttribute(Qt::AA_DisableWindowContextHelpButton);
#endif

Why?
Find "Qt::AA_DisableWindowContextHelpButton" on page: https://doc.qt.io/qt-5/qt.html


2. Change link color

Standard link colors have been used for years: blue for the standard link, purple for the visited link and red for the active link. These colors can of course vary depending on the web browser and even the specific version of the browser.
Throughout the Sigil code, the link only appears three times (all in the About box), so I hope this is not a revolutionary suggestion.

But why?
The blue color of the link is very legible on a white background, but with darker themes this color does not look good because it is too blue.



The change is simple, just cover these three links with the SPAN tag with the appropriate blue color – I suggest:

<span style=\"text-decoration: underline; color:#039be5;\">…</span>

3. Optional turning off the border around the code view.

The gray frame around the main window is hardcoded and cannot be styled in any way by an external QSS file. Over the past year I have used Sigil without this frame and I don't miss it, but maybe in MacOS or Linux systems the frame matters.

The frame is defined in this way:

static const QString TAB_STYLE_SHEET = "#managerframe {border-top: 0px solid white;"
        "border-left: 1px solid gray;"
        "border-right: 1px solid gray;"
        "border-bottom: 1px solid gray;}";

It is easy to turn it off by commenting on the line that instructs you to turn on hair styling:

frame-> setStyleSheet (TAB_STYLE_SHEET);

The suggestion is to add a parameter with the example name SIGIL_DISABLE_BORDER_STYLING and then the main window would not be styled. Or – maybe – this frame is not so important. Then the interface is more like "flat" style.

Image: sigil-border.png
Image: sigil-dark-border-on.png
Image: sigil-dark-border-off.png


4. Default empty files – a layout more similar to that after mending

It's really a small thing.
Two extra spaces (in two places) and one new line.
Then the empty file before and after mending will be identical.

Separate change for epub2 and epub3.

Image: sigil-suggestion-4.png


5. Fix format case icon

IMHO the text icon is not cool.
When resizing icons on the toolbar, this icon is either too big or too small.

Image: sigil-format-case-icon.png


6. Non-standard semantics (other.) in tooltips

Epub2 files may have non-standard semantics (not in the main list) and then have the prefix "other." (e.g., other.footnotes).
Sigil does not display tooltips for such xhtml files.

Change in\src\Misc\GuideItems.cpp file:

     return rel.name;

to

     if (rel.name != "") {
         return rel.name;
     } else {
         return code;
     }

[DiapDealer]

#1 is reasonable enough, but we'd need to remember to ifdef it conditionally. AA_DisableWindowContextHelpButton was only introduced in Qt5.10, and we try to ensure that Sigil will build and function with at least limited functionality back to Qt5.9.4 on Linux.

#2. I'm for anything that helps with moving Sigil toward better supporting a dark mode (however it's accomplished).

#3. The frame is quite important. It's the central widget. It's visibility or appearance, however, is not vital. I've no real feelings (good or bad) on this particular suggestion.

#4 Again, no strong feelings one way or another.

#5 HOW DARE YOU! I slaved for minutes creating THAT icon! But seriously... I hate icon work, I'd entertain reasonable replacement suggestions (as long as all three necessary sizes were supplied). To be honest, I'm not sure if I did that one or not (or if it's even an icon). I think I did the h* icon.

#6 I can live with or without this change.

[KevinH]

I do not have strong feelings against any of these.

But it would certainly make things easier if we had a set of separate pull request for each the change you proposed so we can merge the ones people have no trouble with more easily. After everyone who wants to speaks up.

Thanks,

KevinH

[odamizu]

#3 - Just so I'm clear, this would be an optional, user-customizable thing? If so, I always like the idea of user-customizable options, though I'm not sure I would make use of the option as the default has always been fine for me.

#5 - I have never felt this icon was too big or too small and am therefore a little leery of changing it, but I don't feel strongly about this.

Everything else I don't have much opinion for or against.

[Tex2002ans]

Originally Posted by BeckyEbook

1. Question mark in dialog boxes

I just noticed the ? a few days ago. I clicked to see what it actually did, and it looked like it did absolutely nothing.

Just thought it was one of those things that was always there and I just never noticed.

Originally Posted by BeckyEbook

2. Change link color

Against this. That specific color (#039BE5) looks quite hard to read on white background, and even inserting it into:

https://webaim.org/resources/contrastchecker/

gives a Contrast Ratio 3.07:1, and fails WCAG on nearly all background levels.

I assume the vast majority has white background and leaves the colors on defaults. If someone goes out of their way to create a darker theme, is this link color not user-adjustable?

Originally Posted by BeckyEbook

3. Optional turning off the border around the code view.

Either seems fine to me.

3 more pixels of screen real estate seems like a plus!

Originally Posted by BeckyEbook

4. Default empty files – a layout more similar to that after mending

I was also thinking this exact same thing. First thing I always do when I create a new file is Prettify it.

Originally Posted by BeckyEbook

5. Fix format case icon

Consistency is probably good.

Originally Posted by BeckyEbook

6. Non-standard semantics (other.) in tooltips

Seems like the change wouldn't hurt.

But do you have an example of a book using this in the wild?

[najgori]

After regex search and replace in Calibre you can compare before and after code in 2 windows side by side.
It would be cool to add this to Sigil.

[RbnJrg]

Maybe you can implement something like this:

[The_book]

Originally Posted by najgori

After regex search and replace in Calibre you can compare before and after code in 2 windows side by side.
It would be cool to add this to Sigil.

I want to know will Sigil add regex function replacement like Calibre? Or will some design a plugin like this?

[DiapDealer]

Lets not turn this thread into a general wishlist, please. Everyone is free to create their own thread, but this one should be about @Becky's suggestions.

[DiapDealer]

Originally Posted by Tex2002ans

Against this. That specific color (#039BE5) looks quite hard to read on white background, and even inserting it into:

https://webaim.org/resources/contrastchecker/

gives a Contrast Ratio 3.07:1, and fails WCAG on nearly all background levels.

Keep in mind that @BeckyEbook's request is for three specific (and unchanging) links in the Sigil About box (only two of them are actually working links in fact). I just wanted to be certain that everyone understands that this is not a request to make a blanket change to the color of all links rendered by Sigil.

We will try to look for colors that will strike a reasonable compromise RE contrast in Light and Dark Themes with regard to accessibility standards. A triple-A contrast-rating for both modes from WCAG is not very likely to happen, though.

Dark Theme compromises RE Sigil's default colors/icons are going to eventually happen across the board, though; just to be clear. Many OSes already offer High Contrast themes (Windows 10 1909 included) for those who have accessibility needs.

[BeckyEbook]

I will try to reply to comments later, I need to think about it.

I still have an additional idea.

7. Colors in Validation Results

Image: sigil-validation-results-colors.png

System variables are cool, but an even better section would be in the sigil_tweaks.ini file (if the file does not exist – default settings are used).

[tweaks]
border=false
link_color=#3333FF
validation=foreground
info_color=#72A5D4
warning_color=#D4A572
error_color=#DE5E5E

border (#3) – true/false
link_color (#2) – do not like blue or is illegible? enter your color for links
validation (#7) – foreground/background. Whether the color in the Validation Results window is to be set for text or for the background
info_color, warning_color, error_color – own colors in Validation Results

[DiapDealer]

I'd rather not come up with a lot of individual tweaks to address dark theme aspects of various sigil widgets. If at all possible, I'd like to use QPalette generic "darkColor", "lightColor", "disabledColor" for the various ui elements that can then be styled or themed appropriately. One ini tweak file for the validation widget alone seems a bit messy to me.

[BeckyEbook]

If only an optional solution is possible – it will definitely be better than coming up with workarounds/tweaks.

Dark theme can be thought of after release 1.0.
I wanted to gather in one place those elements that are an obstacle. I hope that users can have their opinion and then developers will have an easier task in the future.
Sometimes something bothers for years, but when a new option/functionality appears, he thinks "How could I live without it?"

Just the ini file with tweaks would cover all aspects that go beyond the default (light) theme and hardcoded elements.
Please note that border (described in the first post) and link_color (these blue links in the About window) are just an attempt to collect changes in one place.
The list is open and would allow you to add other "tweaks" in the future.

And if one day it is possible without tweaks – even better.

[BeckyEbook]

Originally Posted by KevinH

But it would certainly make things easier if we had a set of separate pull request for each the change you proposed so we can merge the ones people have no trouble with more easily. After everyone who wants to speaks up.

I will try to prepare a separate pull request for all proposals.

Originally Posted by DiapDealer

#1 is reasonable enough, but we'd need to remember to ifdef it conditionally. AA_DisableWindowContextHelpButton was only introduced in Qt5.10, and we try to ensure that Sigil will build and function with at least limited functionality back to Qt5.9.4 on Linux.

Sure.

Originally Posted by DiapDealer

#5 HOW DARE YOU! I slaved for minutes creating THAT icon! But seriously... I hate icon work, I'd entertain reasonable replacement suggestions (as long as all three necessary sizes were supplied). To be honest, I'm not sure if I did that one or not (or if it's even an icon). I think I did the h* icon.

Even now, h* doesn't work perfectly (depending on what state Sigil was closed in). If it was a 16px icon – it incorrectly switches to larger icon sizes when moving the slider. If it was a 22px or 48px icon – it should be fine.

Originally Posted by odamizu

#3 - Just so I'm clear, this would be an optional, user-customizable thing? If so, I always like the idea of user-customizable options, though I'm not sure I would make use of the option as the default has always been fine for me.

Sure. The frame stays by default + optional borderlessness.

Originally Posted by Tex2002ans

If someone goes out of their way to create a darker theme, is this link color not user-adjustable?

Qt unfortunately doesn't allow links to be styled
I have thoroughly analyzed the guidelines regarding contrast and visibility for people with sight diseases. Since there is no perfect solution (and perfect blue for links), I have to accept that adjustment for the disabled is more important than subjective aesthetics.
On the other hand, people with impaired eyesight would probably prefer not to use a dark theme, but a high contrast theme. Then the links are often yellow on a black background or similarly highly contrasting.

Originally Posted by Tex2002ans

#6
Seems like the change wouldn't hurt.
But do you have an example of a book using this in the wild?

Of course.
I have 769 e-books bought from Polish bookstores. 83 of them (10.8%) was used semantics of "other." in the guide section.

[BetterRed]

Originally Posted by BeckyEbook

On the other hand, people with impaired eyesight would probably prefer not to use a dark theme, but a high contrast theme. Then the links are often yellow on a black background or similarly highly contrasting.

Not sure that's always true, I have poor eyesight and I really dislike high contrast themes. When available I always choose a dark theme (but not bright white on shiny black) - light silver on charcoal grey is my preference, a'la :



BTW that's an upcoming calibre enhancement, as I understand the change, it's what Windows users can (will ?) get if they have selected Dark in Windows->Settings->Personalisation->Colours.

BR