Quote:
|
Originally Posted by DiapDealer
The original source could possibly be utf-16, but at the point the entity substitution happens, Sigil seems to have already homogenized everything to utf-8 (that's an assumption based on the presence of the "QString::fromUtf8" function). Still... it could pose a problem if Sigil does (or chooses to in the future) preserve the underlying utf-8/16-ness of a document. Right now, though, it seems that portion of Sigil's code is confidently expecting utf-8. *shrugs*
|
You're misunderstanding how the QString::fromUtf8 function works. Internally a QString is utf16. ::fromUtf8 takes a utf8 string and converts it into a utf16 string (all QStrings are utf16). Very little assumes or requires utf8 in regard to the text. PCRE included in 0.5.x was utf8 only. With 0.6.0 PCRE has added support for utf16 and Sigil is using it. Spell check does use uft8 but spell check is not required and does not prevent a utf16 document to be loaded or saved.
Quote:
|
Originally Posted by Serpentine
A few of us spoke up against the idea — but there was a lot of "Herpa derp I once edited something... so make the BV nice! XD," while actual users voiced that throwing web-components into something, to replace native ones was a bad idea and would require so many affordances to be forced into being, for little gain at the end of the day.
|
Try listening. I've told you this before. The majority of the old component was written in Javascript. The old component loads and uses JQuery for a number of different operations. Look at all of the [url=http://code.google.com/p/sigil/source/browse/?name=0.5.3#git%2Fsrc%2FSigil%2FResource_Files%2Fj avascript]helpers[/ur] that were used. This is in addition to all of the Javacript
sprinkled throughout the BV source.
Quote:
|
Originally Posted by ondrejandrej
Hi, I installed the version 0.5.902 under Linux and realized, that it sucks. How do I remove it? There are no uninstallation instructions neither in enclosed text files nor in wiki.
|
Sigil is no longer provided as a binary package. If you installed from a binary package ask the author of that package. If you built from source. Learn about building from source because it includes the same uninstaller as pretty much every other source package. None.
---
Syncing:
Syncing the cursor between views isn't supported. The cursor should remember its position within the view.
BookView:
EPUB 3? Yes? The old BV doesn't support outputting HTML5. It actually doesn't even support outputting 100% valid XHTML. Tidy is used to turn the output into something that passes validation.
There is not good WYSIWYG editing component. I'm not willing to spend the time to write one from scratch as that would be the equivalent of creating something similar and even more complex than a browser. So either what's currently available can be used or no BV.
Personally I'd love to drop BV completely. It's the most frustrating piece of Sigil to work on. It doesn't work properly and it never has. It complicates the code base by a large amount. About 60% of the time spent working on every release is spent dealing with BV. That said, I don't think it's a good idea to drop BV from Sigil. A non-Sigil Sigil without BV would be a different story though.
Slotting the old BV back in is possible. It should only take an afternoon worth of work. I'll weigh the advantages of doing so. But don't think that putting the old BV back will solve every issue. For example, the old BV doesn't always produce output that will pass validation. It's actually easier to modify CKEditor's output than the old BV.
The point of the beta is to see what work, what doesn't, what people don't like and what people like. Funny thing about doing a beta is about 25% of the issues reported aren't new. They've been around for quite some time.
The hardest part of developing software is what one person requests as functionality and loves another person hates. So we end up with different parties asking for different things that don't work well together. There are only a few outcomes. One party isn't happy. Neither party is happy. Both parties are somewhat happy. It's pretty much impossible to make both parties completely happy.
At this point I'm thinking I have enough feedback to go back the drawing board for 0.6.0. Put some more work into it and try again at a later date. If something doesn't work there isn't anything wrong with trowing it out. The only drawback is with limited developers and limited resources it delays a new release.