Sigil-2.0.2 Released

[KevinH]

It is a real shame that Windows does not have an os level CrashReporting tool built-in that can provide real backtraces for all threads and libs like macOS does. Makes it very easy for even novice users to provide information useful for determining the cause of the crash and getting that info to developers.

I truly wonder if there exists an open source Windows specific crash reporting backtrace tool we could build into Sigil on Windows.

Doesn't chrome browser on Windows have something like that?

[Vanguard3000]

Hey, found another small multi-display issue - this time pretty trivial compared with the one I had in v2.0.0:

If you minimize a Sigil instance on your secondary display, the reopen it, it'll reopen on the main display.

That's it. That's the bug. As I said it's pretty minor but I felt I'd put it on your radar. Hopefully it's got a common root cause as the issue with context menus showing on the wrong monitor, and a similar adjustment can be applied.

Thanks for everything, fellas!

[KevinH]

That is Qt. I 'll look for an official Qt bug report and solution but I would not hold my breath as this would be a very low priority bug for them.

[Vanguard3000]

That's fine; it's a pretty minor nuisance. I just wanted to let you know. Thanks!

[democrite]

Of some possible new features, as I often edit very long and complex works, I may have EPUBs with hundreds of images, numerous CSS classes, etc., many anchors and links, etc. Perhaps in numerous places such as right click an element, go to source link (maybe that's already there), rename class or id even from a link or element, right click img tag and rename class or image, etc. Maybe some properties panel that is context sensitive that makes such edits possible.

Who knows, For complex works, more contextual aware editing with right click or something would so much significantly reduce effort. At the moment, just as with code there are editors that make refactoring easy, for XHTML if one thinks of it as a project such too would be nice. Perhaps complex yet maybe a few little things along the way here and there.

[KevinH]

Unfortunately, these are too vague to be useful as feature suggestions. Please be very very specific when requesting a new feature and please do not suggest things that can already be done (such as going to class definition in css by Ctrl clicking on class in element in CodeView) or that can be done with just setting a different OpenWith editor.

I can not read minds so explaining exactly what the new feature would do, how it would be launched, and why it is important so that others could comment on the suggestion's merits.

[Turtle91]

I know we’ve talked about this before, but your mention of ctrl-clicking a class reminded me I’m still seeing this problem:

If I ctrl-click on a class in a div (such as the "ack" below) I am taken to the top of the stylesheet, as if it couldn’t find the class. This is most likely due to my use of descendent combinators. I usually have a default <div> style with custom styling for items within the <div>. eg. div.blio p {}

HTML:
<div class="ack">
    <h2>Acknowledgments</h2>

    <p>I have no idea why this isn't working......</p>
    <p>yadda yadda</p>
  </div>


CSS:
/* Division section styles */
/* Default */

div {
	text-indent: 0;
	margin: 2em;
}

/* Custom */

div.ack p {
	margin: 0 0 0.5em;
	font-size: 1.15em;
	text-align: left;
	text-indent: 0;
}

div.copy p {
	margin: 0 0 0.75em;
	font-size: 0.85em;
	text-align: center;
	text-indent: 0;
}

div.blio p {
	margin: 0 0 0.5em;
	font-size: 1em;
	text-align: center;
	font-style: italic;
	text-indent: 0;
}

Is it possible to add another option before defaulting to the top of the sheet?

1) Find the class by itself on stylesheet and go there
2) Find the class as part of a combinator and go to the first instance
3) If unfound, goto top of stylesheet

Edit: Just to be clear - ctrl-click on a class will work properly if/when I explicitly define the class:

HTML:
  <div class="invite">
    <p class="title">Her Royal Majesty Queen Amidalla</p>
    <p>cordially invites you to fix this on 25 Dec 2023.</p>
    <p>If you fail, you will surely be declaring for the dark-side and
       shall be hunted down and squished like a bug!</p> /*get it - a bug - :D*/ 
  </div>

CSS:
div.invite {
	margin: 2em;
	width: fit-content;
	max-width: 95%;
}

div.invite p {
	margin-bottom: 0.5em;
	font-size: 1em;
	text-indent: 0;
	font-family: "Monotype Corsiva", "cursive", serif;
	font-style: italic;
}

[KevinH]

I will look into it but ...

a combinator is technically a css selector and not a css class. Finding classes is one thing that only requires that elements class name. I could add the element name info but as you can have multiple descendants that would be an issue.

So technically, to make this work correctly I would the have to parse the entire xhtml file and try matching it against all linked css selectors and then track their specificity to find the highest one.

Unfortunately, that is not something easily done.

If you right click on the class="ack" on a div it should be able to find the div.ack if no ack exists in the css. That should work now if div.ack is a selector just not when it is only part of a combinator selector.

Perhaps I could extend that to match if just starting a selector? Would that help?

But right clicking in its child p (descendant combinator selector (or child)) and going to its selector would be a real problem.

It looks simple but it is not. That is why we restrict this feature to classes which is the most common case and not to selectors in general.

[Turtle91]

I was thinking something along the lines of a standard "find:ack" with all css stylesheets selected. That only finds the letter combination of “ack” so somehow adding the element type might help?? eg. div. or p.

Of course, that is just my uninformed thought…

[KevinH]

It is not a string search in the css file. Instead the css file is fully parsed and multiple selectors are split to create individual versions and the parser is used to find the line of the source code where that selector is defined.

But I could change the "match a selector" code to either be a full match or to match the first part of a combinator selector - just not later targets in that combinator as that would require a full parsing of the xhtml as well as specificity calculations.

Would that help?

Originally Posted by Turtle91

I was thinking something along the lines of a standard "find:ack" with all css stylesheets selected. That only finds the letter combination of “ack” so somehow adding the element type might help?? eg. div. or p.

Of course, that is just my uninformed thought…

[Turtle91]

Yeeessssss…. That would be helpful.

I’m hoping you understood everything you just said FAR better than me…

[KevinH]

Okay, I will work on adding that ability to look at combinator selectors starting pieces when no general matches are found.

[Turtle91]

Thank you kind sir!

[KevinH]

@Turtle91

Had some free time this evening (being retired is truly wonderful!) so I implemented my approach to this and pushed it to master.

Using your example css file and example xhtml, I tested the results and it does find div.ack now.

This feature will be part of the next release.

Hope this helps. I do not think css combinator use is heavy in epubs but it may be more traction in epub3 e-readers.

Kevin

[Turtle91]

Awesome! Thanks!!