Visual Cue in Add Semantics dialogue box?

[BKh]

I just want to share my appreciation for the folks still working on/talking about this. Only yesterday I came across the issue again in an old book I was working on. Thanks!!

[KevinH]

For the record, I have just pushed changes to master to colour the current semantic in red (if any set) in the Add Semantics dialog.

For those who build from source you can pull from master and rebuild to get this change asap. Otherwise this change will be included for the upcoming final (non-beta) release of Sigil.

[BeckyEbook]

Thank you for this improvement.

One note:
The red color is probably not visible with the dark theme, because you can not add style only for current semantic element. It would be worth building a version and checking on a dark theme in Mojave.
Using the QSS style – the red color disappears.
The solution would be simply to add a checkmark suggested by BetterRed here.

QString added_checkmark = name + " ✓";
item->setText(added_checkmark);

[KevinH]

No the name itself is used in a dictionary lookup, so modifying the name itself is out.
Why can't red be seen on a Dark motif? It is a foreground colour and not a background colour for the text. Red should show up on a dark or light background. That is why I chose it.

[BeckyEbook]

Originally Posted by KevinH

No the name itself is used in a dictionary lookup, so modifying the name itself is out.

I'm sorry, I do not know. It works for me.
Screen shots were real.

Originally Posted by KevinH

Why can't red be seen on a Dark motif? It is a foreground colour and not a background colour for the text. Red should show up on a dark or light background. That is why I chose it.

Yes, for REAL dark theme (like as Mojave).
But for QSS style if the current semantics does not have any css / qss class or id that can be individually configured - it looks like this: dark background and black text. The red color among black foreground on a dark background looks unattractive.
If I write style:

QListView::item {
  color: #d8d8d8;
}

...this style will overwrite the red color.
That's what I meant when I suggested a checkmark that always works.

[DiapDealer]

It's always going to be possible for a user's custom qss and Sigil defaults to be at odds with each other. And "unattractive" is always going to be in the eye of the beholder. People wanted to be able to SEE if a semantic is already applied to a file in the semantics dialog. This accomplishes that without adding extra columns to an already crowded dialog.

[KevinH]

The name string itself is used in a dictionary lookup. If you append a check char to the end, looking up the name will fail, which means you will not be able to toggle the previously set semantic in one step.

So adding chars to the name is *not* what I want to do. I would have to collect the selected names and check if already appended with space check and then remove it before looking it the name in the dictionary.

BTW, any user could set their own qss and make any Sigil dialog pretty unusable.

[BeckyEbook]

Originally Posted by KevinH

The name string itself is used in a dictionary lookup. If you append a check char to the end, looking up the name will fail, which means you will not be able to toggle the previously set semantic in one step.

You're right. name + checkmark does not allow to deselect already assigned semantics.

Originally Posted by DiapDealer

It's always going to be possible for a user's custom qss and Sigil defaults to be at odds with each other. And "unattractive" is always going to be in the eye of the beholder.

Originally Posted by KevinH

BTW, any user could set their own qss and make any Sigil dialog pretty unusable.

You are right. But in this case the point is that creating the correct qss style in which this red color will be visible is IMHO impossible.

Originally Posted by DiapDealer

People wanted to be able to SEE if a semantic is already applied to a file in the semantics dialog. This accomplishes that without adding extra columns to an already crowded dialog.

I really appreciate this solution, because it significantly facilitates the work on e-books. I am sure that all users will welcome this feature.

I can handle it.

[KevinH]

I could either set the foreground and background colour independent of theme, or use a text decoration like an underline. Would an underline be better than a vibrant red colour? I find underlines are harder to detect than a foreground colour like red.

[KevinH]

Another possibility is to add checked versions of the names to the dictionary as well. Or even just the current name with check to the dictionary... that would work.

[DiapDealer]

Could we somehow let QPalette choose a thematic color? I don't know the first thing about it, but I think we're supposed to be able to use things like:

QPalette::BrightText
QPalette::AlternateBase
QPalette::Midlight

[KevinH]

Yes this sounds like a good idea.

It will take some study and work.

So until then I have just pushed the space checkmark idea where we load the checked version of the name into the dictionary to prevent issues.

That should keep everyone happy for the upcoming release until we figure out how to do our own themes or at least figure out how to make theme-appropriate choices.

Thanks,

Kevin

Originally Posted by DiapDealer

Could we somehow let QPalette choose a thematic color? I don't know the first thing about it, but I think we're supposed to be able to use things like:

QPalette::BrightText
QPalette::AlternateBase
QPalette::Midlight

[BeckyEbook]

Double thank you for your understanding of users who use their own themes.
I confirm that it works great now (build on Win10).

[BetterRed]

FTR - my original idea was to have a checkmark on the file name in the Book Browser, to indicate the files that have a semantic tag.

This would help identify files that a) might have been spuriously tagged - e.g. I would not expect chapter3.xhtml to have a semantic tag, and b) might have missed being tagged - e.g. I would expect dedication.xhtml to have a semantic tag. My thinking was that the presence and/or absence of questionable checkmarks would be a trigger for me to take a closer look at Reports->All Files.

That's not at odds with using a checkmark (or colour) in the Add Semantics dialogue against the tag assigned to a given file. But it is not equivalent.

BR

[DiapDealer]

Originally Posted by BetterRed

That's not at odds with using a checkmark (or colour) in the Add Semantics dialogue against the tag assigned to a given file. But it is not equivalent.

It's not equivalent. But it's what we're getting. I'm simply not in favor of adding extra visual indicators to the Book Browser (or changing the existing Book Browser icons). Especially when those indicators won't give you the level of detail you'd actually need to make any changes. Look at the OPF or the NAV if you need a quick, detailed overview of which files have which semantics assigned to them, and use the new visual indication in the semantics dialog to make sure you're not toggling off something you meant to turn on.