sigil 7.4 and maverick crashing crashing crashing

[KevinH]

Hi user_none,

Okay, this should be better. I made all the changes I wanted to make (except for shrinking the List width in the Preferences pane).

So here is an improved patch that implements preserving entities in codeview. It passes the QList< std::pair < ushort, QString > > codenames from settings into the Clean up code and thereby speeds up replacement of codepoints as a hash lookup is no longer needed for each of them each time it is invoked.

I still can't figure out how to use QtCreator.app with the PPreserveEntitiesWidget.ui in any sane way so I am stuck hand editing the damn ui file to try to shrink the list width but failing miserably.

Any hints on how best to create/edit these ui files would be helpful.

Anyway, here is the new patch against trunk.

Please let me know what if anything you would prefer to have changed. Once you are happy, I can grab and install git and play around with github and pulls.

Thanks again for all of your help!

KevinH

[DiapDealer]

And here I just got the old preserve_entities patched version compiled and running on Windows!

Oh well. At least it's fresh in my mind now, so building the new version shouldn't be much trouble.

The Windows nmake makeinstaller target needs a little tlc, but the changes that need made are relatively small, so I'll wait to see when/if your changes are pulled into the main before submitting a patch for the src/Sigil/CMakeLists.txt file. A few of the QtLibs have been added/dropped from the early days of Qt5 (and the icu libs have been updated.)

[KevinH]

Hi DiapDealer,

Glad to hear it. The functionality of both versions is the same. Just the underlying implementation changed slightly. The second version should be faster on large files if you have a large number of entities to preserve. Please let me know if it does what you want and if any changes are needed.

Take care,

Kevin

[DiapDealer]

Ok. So just to verify what behavior I'm looking for ... you're looking to preserve a user-defined list of named entities, right? In order to keep them from being changed to their character equivalents when editing in Book View (which seems to be the default behavior in 0.7.4+) and switching back to Code View. Have I got the gist of it?

If so, as proof of concept, it seems to be working. But it seems to me that it's more or less enforcing that user-defined list of named entities on a document-wide basis. What I mean is: if I have an html page that utilizes typographic single-quote characters (not entities) in abundance and I add &rsquo; to the Preserve Entities list in the preferences ... the next time I make an edit in Book View and come back to Code View, every single closing single quote character will have been converted to the &rsquo; entity.

If that's the way it's intended, that's fine. I was just hoping to be able to pick and choose a bit. To maybe use the character for a closing quote and the entity for an apostrophe.

Also, if I have any &#8217; entities in a document, they will all be converted to the named entity if I add &rsquo; to the list and make a Book View edit.

I'm just giving you the behavior I'm seeing, so that you can determine if it's working the way you expected it to.

I guess I was hoping for more of a "leave all existing entities (in Code View) that are in the Preserve Entities list alone when making changes in Book view" approach. Rather than "change everything to the entity in the preferences when making changes in Book View."

But maybe I'm getting a head of myself.

[KevinH]

Hi DiapDealer,
As I tried to explain earlier in this thread but did not do a good job, anytime you edit the book in Book View, ALL of your entities will be converted to their individual unicode single chars. This is because editing in BookView uses the QWebView widget and it gives you no options to get back *any* entities.

So the only way around that is to convert them back from the single unicode char to the entity so it can be used in editing in CodeView. Unfortunately, this is an all or nothing endeavor.

There is no way to tell which were entities and which were not when in code view, especially if in BookView mode editing changes are made that move or change the code. That is why we allow the user to select which entities they prefer to work with instead of unicode chars.

So yes, what you see (encoding them all) is what was planned. Given extensive editing can be done in BookView, you have to load the current xhtml code into the QWebView widget, let all of the editing happen, and get back the changed code but with no entities at all!

That is the difference between a CodeView only editor with a preview pane, and actual wysiwyg editing. Sorry, all I can do is hope you want to use those preserved entities consistently and always give you those back.

Hope this explains things better. Sorry, but unless we write our own QWebView widget that does not parse entities and auto convert them, I am not sure there is any other solution.

Thanks for trying it!

Take care,

KevinH

Originally Posted by Diapdealer

Ok. So just to verify what behavior I'm looking for ... you're looking to preserve a user-defined list of named entities, right? In order to keep them from being changed to their character equivalents when editing in Book View (which seems to be the default behavior in 0.7.4+) and switching back to Code View. Have I got the gist of it?

If so, as proof of concept, it seems to be working. But it seems to me that it's more or less enforcing that user-defined list of named entities on a document-wide basis. What I mean is: if I have an html page that utilizes typographic single-quote characters (not entities) in abundance and I add &rsquo; to the Preserve Entities list in the preferences ... the next time I make an edit in Book View and come back to Code View, every single closing single quote character will have been converted to the &rsquo; entity.

If that's the way it's intended, that's fine. I was just hoping to be able to pick and choose a bit. To maybe use the character for a closing quote and the entity for an apostrophe.

Also, if I have any &#8217[NOPARSE; entities in a document, they will all be converted to the named entity if I add &[NOPARSE]rsquo; to the list and make a Book View edit.

I'm just giving you the behavior I'm seeing, so that you can determine if it's working the way you expected it to.

I guess I was hoping for more of a "leave all existing entities (in Code View) that are in the Preserve Entities list alone when making changes in Book view" approach. Rather than "change everything to the entity in the preferences when making changes in Book View."

But maybe I'm getting a head of myself.

[DiapDealer]

Ok, I'm on the same page, now.

I'll probably just stick to my "look, but never touch in Book View" rule. It's become ingrained over time. My use of entities is almost non-existent these days (with the exception of nbsp), but I'd still give up the ability to edit in WYSIWYG mode in a heartbeat (considering it's something I've trained myself to never do anyway) if it made this (and other issues) go away and allowed more flexibilty to mix & match chars/named- numeric-entities. I'd be perfectly OK with the Preview Pane, or the Open With feature (or just loading the thing in ADE) when I wanted to check how something rendered.

In all seriousness ... in your opinion, how involved would a flat-out Book View-ectomy be? Is it feasible, or is everything just too intimately entwined?

[KevinH]

Hi DiapDealer,

It is should be quite straightforward but I have never looked that closely. We should be able to simply never read out the code from the QWebView widget family and only set it. There is an attribute with QWebView to make the loaded web page un-editable and you effectively have a visually linked preview pane.

That said the wysiwyg nature seems to be what brings most novice users to Sigil. Perhaps we could do both by allowing the user to select in the Preferences how they want to use Sigil - code editing with live previewing mode vs wysiwyg editing mode.

All that said, user_none would be the one to ask as he understands the entire architecture while I only understand pieces here and there.

Take care,

Kevin

[JSWolf]

Originally Posted by DiapDealer

And here I just got the old preserve_entities patched version compiled and running on Windows!

Oh well. At least it's fresh in my mind now, so building the new version shouldn't be much trouble.

The Windows nmake makeinstaller target needs a little tlc, but the changes that need made are relatively small, so I'll wait to see when/if your changes are pulled into the main before submitting a patch for the src/Sigil/CMakeLists.txt file. A few of the QtLibs have been added/dropped from the early days of Qt5 (and the icu libs have been updated.)

Would you mind posting the Windows build please with these patches? Thanks.

[DiapDealer]

Originally Posted by JSWolf

Would you mind posting the Windows build please with these patches? Thanks.

Sure. If you don't mind an ugly Google Drive Link.

https://drive.google.com/file/d/0B5C...it?usp=sharing

Latest source from git, patched with KevinH's new_preserve_entities patch and compiled with Qt5.3.1

[JSWolf]

Originally Posted by DiapDealer

Sure. If you don't mind an ugly Google Drive Link.

https://drive.google.com/file/d/0B5C...it?usp=sharing

Latest source from git, patched with KevinH's new_preserve_entities patch and compiled with Qt5.3.1

Thank you very much!

[DiapDealer]

Originally Posted by KevinH

That said the wysiwyg nature seems to be what brings most novice users to Sigil. Perhaps we could do both by allowing the user to select in the Preferences how they want to use Sigil - code editing with live previewing mode vs wysiwyg editing mode.

I certainly don't want to take WYSIWYG editing away from anyone who utilizes it. A preference selection would be great, but I wouldn't be opposed to a personal fork of the project either, if it came to that.

Thanks for the hope that it wouldn't be virtually impossible.

[eschwartz]

What is the difference between Sigil-without-WYSIWYG/WYSINWYW-editing, and calibre's ebook-edit? Both offer preview, and honestly I wasn't aware that there was any difference between that and Book View.

[KevinH]

Hi,
For me it's all of the calibre added, overhead, css, new classes names, only metadata meta tags supported that they store internally in calibre, etc ... plus sometimes you just don't want your code played with at all. in any way. This would be doable with a modified Sigil. But in general, you are right, they are very close.

My 2 cents ...


Edit: There is already a linked Preview ability in Sigil that disallows editing that the BookView Editor class actually inherits from. Using only that should prevent any entity replacement at all.


Kevin

Originally Posted by eschwartz

What is the difference between Sigil-without-WYSIWYG/WYSINWYW-editing, and calibre's ebook-edit? Both offer preview, and honestly I wasn't aware that there was any difference between that and Book View.

[PeterT]

I thought that as long as you did not perform conversions in calibre, that you had full control over the CSS / class names etc.

[eschwartz]

Originally Posted by PeterT

I thought that as long as you did not perform conversions in calibre, that you had full control over the CSS / class names etc.

True.