Sigil-1.5.0 Beta Released

[un_pogaz]

Originally Posted by DiapDealer

In my tests, the same 10 files with illegal & entities in the href attributes of the opf manifest give the exact same warning using both Sigil 1.4 and 1.5. Both versions (1.4.and 1.5) also discard the same 10 improperly manifested files in my testing.

Ah, okay.
I swear it works without a problem on mine 1.4.
The first version of this ePub dates back to at least 0.8, it's super old, maybe something survived from that period...

Anyway, it's clearly out of scope of Sigil. I'll fix it to be comply with the standard.

PS: For info, the bugged entries are referred as such:

<item id="Brian_Herbert___Kevin_J._Anderson.html" href="Text/Brian Herbert &amp; Kevin J. Anderson.html" media-type="application/xhtml+xml"/>

Bug closed

Originally Posted by DiapDealer

Sorry. I missed your retraction of #2. I'll look at #1 with regard to the provided & amp.epub

What an idiot I am, it is the 1 (the escape character) from which I retract, the 2 is "always" valid

[KevinH]

For your 4., yes, that is a bug. Custom elements need to be able to be specified once but making names editable in general is not a good idea as it would allow novice users to mess up things completely by changing names they should not be changing. That is why we locked down the names to begin with.

I will look into adding a small dialog prompt to query for a Custom metadata element (name) before adding it in table as once there, editing the name will not be possible but editing the value will of-course be.

Thanks,

[DiapDealer]

Originally Posted by un_pogaz

The ePub "& amp" is the one with the 1) element
I want to specify that this ePub was perfectly valid in the 1.4, Sigil authorized me perfectly this character. The 1.5 failed to load this.

Again... using your test epub, I can see no difference in how Sigil 1.4's ToC editor deals with the ampersands than Sigil 1.5.0 does. Both display the % encoded file names, and I can enter the ampersand character in either version and it is properly % encoded in the ncx (as well as the toc editor next time I open it).

You're going to need to be more specific about what you're experiencing with regard to ampersands that's different from the Sigil 1.4 series compared to the 1.5 beta. Step by step instructions of what you're doing and how version of Sigil differs when performing those steps. "Failed to load this" is sufficient. I see nothing that's failing to load in either version with regard to ampersands and Sigil's ToC editor.

I don't doubt there's SOME difference you're experiencing between the two versions, but I need much more in the way of particulars if I'm going to be able to recreate it.

[un_pogaz]

@DiapDealer
No, no it's my fault.

I invert the number of the problem 1 and 2
The character escapement is done correctly in the ToC.

And after all, the 2 "problems" as solved.

[DiapDealer]

Originally Posted by un_pogaz

@DiapDealer
No, no it's my fault.

I invert the number of the problem 1 and 2
The character escapement is done correctly in the ToC.

And after all, the 2 "probleme" as be solve.

OK, thanks. Just wanted to be sure.

[eschwartz]

Originally Posted by DiapDealer

Sigil-1.5.0 Beta

Sigil-1.5.0 Beta represents a mix of bug fixes and new features for both epub2 and epub3 users.
Due to large internal changes in the Sigil codebase, this release should be considered Beta (non-production) ready.

This build of Sigil has passed all of our primary tests and appears to be stable but the feature set of Sigil has grown so large that no single person uses it the same way nor exercises all of the code.

I have skipped packaging this for now... I assume there will be a 1.5.1 soon that I should package instead?

[DiapDealer]

Originally Posted by eschwartz

I have skipped packaging this for now... I assume there will be a 1.5.1 soon that I should package instead?

That's the plan, yes. If no huge, deal-breaking bugs rear their ugly heads, 1.5.1 will be out before long. Currently, 1.5.0 isn't even triggering the built-in "update available" notice.

[KevinH]

So to sum up ...

1. and 2.- Not a bug as & is not allowed in a url such as manifest href. Think about making the ImportEPUB more robust to mistakes like these for Sigil-1.6.X.

3. You will need to hand edit the opf to add truly custom identifier schemes in epub2. Such dc:identifier schemes are no longer used in epub3.

4. This is a bug. It is now fixed in my local tree that will prompt to input your custom element name before adding it into the MetaEditor. This fix could appear in a Sigil-1.5.1 but also since so rarely used, saved until Sigil-1.6.x.

5. This is really an enhancement request and not a bug - but one we should be able to squeeze into a future Sigil 1.6.x release

6. Editing huge blocks of unneeded JSON in Metadata elements will not be supported by the Metadata Editor. It will just treat it like any other text field.. Most of that info is unrelated to the book itself and is more saving state within the book. You will need to hand edit the opf if this is what you are looking for.

7. Yes, the ability to double-click on an attribute name or value inside a tag to select it is overridden by the select tag/ select tag contents ability we just added. The only way to deal with this is to reassign the newly added Double-Click in a tag to select its contents, and Shift Double-Click in a tag to select the tag itself and all its contents to some other modifier along with Double-Click. To select a name or an attribute inside a tag, you will have to click and drag.
Double clicking on a word outside of a tag still works just fine.

We could consider changing that for Sigil-1.6.x but we must then get some agreement from the people who wanted the select tag and select tag contents to either give up one of those two new selection modes up or decide on a new modifier for one. Straight double-clicking for selecting words can then be restored (anyplace).

Thanks for your bug reports! And thanks for testing our beta release!

Bug repport:
1) Display the characters escapes directly in the ToC editor (%20, %5B, %5D...)

2) Files with "&" in their name are excluded and deleted

3) ePub2 the property "Scheme" can not be customized (fixed and defined list) [image 1].

4) ePub2 impossible to change the value of a name attribute for the custom elements

5) ePub3 adding the metadata "Belongs to a Collection" should preemptively put the property "Type of collection" and "Position in the group" to facilitate editing (and preferably 2 metadata: one for the series and one for the collection/set)

6) ePub3 the very long custom element (several lines like those created by Calibre) are unreadable and impossible to modify [image 2]

7) impossible to select tag name, a attribute or the value of an attribute with double-click (over-ride by "select tag content" behavior)
I propose to reduce the behavior only when you Maj-Double-Click

[odamizu]

Originally Posted by KevinH

...

7. Yes, the ability to double-click on an attribute name or value inside a tag to select it is overridden by the select tag/ select tag contents ability we just added. The only way to deal with this is to reassign the newly added Double-Click in a tag to select its contents, and Shift Double-Click in a tag to select the tag itself and all its contents to some other modifier along with Double-Click. To select a name or an attribute inside a tag, you will have to click and drag.
Double clicking on a word outside of a tag still works just fine.

We could consider changing that for Sigil-1.6.x but we must then get some agreement from the people who wanted the select tag and select tag contents to either give up one of those two new selection modes up or decide on a new modifier for one. Straight double-clicking for selecting words can then be restored (anyplace).

My preference would be for consistency as I keep forgetting that double-clicking to select words doesn't work inside tags (whereas it's pretty universal everywhere else, not just in Sigil but other programs as well).

If people could be persuaded to use a new, different modifier for selecting tag contents, I would be in favor and much appreciative.

[un_pogaz]

Thanks everyone for taking the time to respond to my feedback somewhat... raw.
All as been solved...
But in the continuity of Odamizu, I insist on the over-ride of the double-click.
Personally, it breaks my editing habits and is a gap from the conventions of selection behavior in other software.

I suggest the use of the following shortcuts:
Maj+Double-click for select the tag content
Maj+Alt+Double-click for select the all tag

[DiapDealer]

What's Maj?

[KevinH]

Yes, I assumed that was Shift? Is it Shift?

[un_pogaz]

Maj, what ? it' obv... Oh crap, I'm french, what is the English name already?!
Shift ! It's Shift.

Shift+Double-click for select the tag content
Shift+Alt+Double-click for select the all tag

[KevinH]

I will restore the use of Double-click to select word under cursor for Sigil-1.5.1 and explore using other modifiers.

Edit: But that was easier said than done.

It seems Sigil's CV uses Ctrl-Doubleclick to follow styles and images to their source.
so using Control is Out.

It seems Alt is used to launch right click menus on macOS at the system level since not all mac's have their mice set to know the difference between left click and right click. So ALT is out.

If we are going to restore double-clcik to always select the word under the cursor no matter if in a tab or not ....

Then we can only support ONE of the following:

A. Use Shift Double-Click to select the just contents of the tag (not the tag code itself)

OR

B. Use Shift DoubleClick to select both the contents of the tag and the tag code itself

Which is more useful? In a future version we could make this an option but for Sigil-1.5.1 I do not want to have to add menus and preferences which would mean another translation pass would be needed.

[KevinH]

Okay, after some more testing (and macOS is crazy here):

On macOS:
- Qt META modifier is tied to the Ctrl key and will be equivalent to a right click
- Qt Ctrl modifier is tied to the Command/Apple Key - and it searches for style/img source
- The Qt Shift modifier acts like normal
- The Qt Alt Modifier is tied to the macOS Option key

So on macOS I can use both the shift key and the alt (option on the mac keyboard) without messing anything up.

So if an alt key works on Windows as a modifier then we should be good to go and no need to drop anything.