Visual Content Editor for Sigil?

[KevinH]

The "crutch" as you call it works just fine for final proofing and simple edits followed by cleanups in Sigil's CodeView if needed. And in that role its interface is fine. Therefore, it will never be more integrated with Sigil.

Too many newbies created too much broken html with it and kept complaining about the mess THEY made with it and filing too many "bug" reports to make it worthwhile in any other fashion.

As for using the OPF, if people understood anything about epubs, they would understand that the OPF is exactly the core file of the epub. Without it, the epub is just a bunch of unrelated html.

So "no". This change was for the best and well thought through by the dev team. It had been in the plans for years. You can disagree and argue otherwise but you do not have to deal with the bug reports and craziness BookView produced. So reversing it is not going to happen. Newbies can still visually edit as long as they know enough html to clean up any messes they make in Sigil.

Originally Posted by un_pogaz

It always comes down to this:
PageEdit/Sigil has powerful but not intuitive functionality (who would use an XHTML visual editor on an XML file containing no text?).

A problem with the WYSIWYG alternative is that none of them accept ePub as the main format. Possibly as a source file, but it is converted to another format.

And above all: None of them allow to alternate easily between code editing and WYSIWYG.
This was the great strength of Sigil "Book view".

The more I think about it, the more the synergy of PageEdit/Sigil is a bad idea.
The real problem isn't that you wanted to get away from a WYSIWYG editor, it's a choice, but that you're maintaining a weird crutch.
Merge them. Find a way to merge them and cohabitate them in the same software.


I thank you for the voluntary development of Sigil, but really, I find that you're blinded yourself any think posibility because "I don't want to think about it" and that your policy is "walk or die" on YOUR choices.

[phillipgessert]

Originally Posted by BrowncoatCat

People in the real world who want to visually lay out a visual product like a book do not want to learn reams of complex coding. They just want to get the job done.

Describing an ebook as a visual product is kind of a perfect crystallization of what's wrong with WYSIWYG. With WYSIWYG, you get folks doing all sorts of arbitrary things that are semantically meaningless but "look right." You have to properly describe the structure of your document, something that is nearly never done by folks using WYSIWYG.

That's why most of the most lauded WYSIWYG apps find success mainly by kneecapping customization options, something that ironically usually causes their users to cry about their exclusion. Can't have it both ways.

[DiapDealer]

Originally Posted by phillipgessert

That's why most of the most lauded WYSIWYG apps find success mainly by kneecapping customization options, something that ironically usually causes their users to cry about their exclusion. Can't have it both ways.

We ran into that as well. People not only wanted Book View to create the code for them automatically, they also wanted to complain that BV wasn't generating the code they way they WANTED it to be generated. I can't count how many complaints we got about people not liking the perfectly valid/compliant code that was being generated by Book View!

[Hitch]

Originally Posted by phillipgessert

Describing an ebook as a visual product is kind of a perfect crystallization of what's wrong with WYSIWYG. With WYSIWYG, you get folks doing all sorts of arbitrary things that are semantically meaningless but "look right." You have to properly describe the structure of your document, something that is nearly never done by folks using WYSIWYG.

That's why most of the most lauded WYSIWYG apps find success mainly by kneecapping customization options, something that ironically usually causes their users to cry about their exclusion. Can't have it both ways.

AMEN! This is exactly the problem with so-called WYSIWYG apps, whether it's Word or iAuthor. Either the developers ensure that the product "infers" what the user wants and then applies it (Word) or they crud it up with so much godawful code that the end result is unreliably usable later (iAuthor's incredibly bad ePUBs, which only work in the Appleverse of iBooks. I mean, iAuthor is being d/c'ed, by Apple. That should tell you everything you ever wanted to know about this very type of app.)

Originally Posted by DiapDealer

We ran into that as well. People not only wanted Book View to create the code for them automatically, they also wanted to complain that BV wasn't generating the code they way they WANTED it to be generated. I can't count how many complaints we got about people not liking the perfectly valid/compliant code that was being generated by Book View!

Yes, that too.

It's true that you can't open ePUBs in AWP, or Jutoh, et al. Perhaps, given that all these products are aimed directly AT the "WYSIWYG" customer, people should stop and ask themselves why that is; why something that they think is perfectly simple should be apparently so tricky.

I would point out for those whingeing, that if the ability to open ePUB A in an editor that's also WYSIWYG is so crucial--open the ePUB with Calibre, save it as docx and then open that in Jutoh or AWP or whatever. In AWP, you don't open the resulting ePUB and edit it, if you aren't happy; you simply revise the source document and build another ePUB.

AWP and Jutoh, in fact, have taken the "the writer/editor doesn't know bupkus about writing code" view, to the nth degree, assuming that all edits can and will be done, in the word-processing file. Which seems the obvious method, given what's been said here. Right? I mean, if learning to edit the code is such a problem, then they have taken the correct path. If you don't like the ebook result, from your file, you don't get your hands dirty in that file; you simply go back to your source, make your changes and then export a new eBook. That makes perfect sense to me, given the apparent unwillingness of the user to learn HTML/CSS. Why would it work any other way?

Or, pay for Blue Griffon, amirite? Doesn't that have the functionality that used to be something like BookView? For only 195 EU? (The user manual is only another 7.95 EU,too.) Such a deal. It has exactly--exactly--what's being requested here, yes? So...happiness is! They even have a downloadable trial version, for those of you that are so distressed over losing Sigil's BV and, for some reason, want to constantly complain about it instead of simply downloading one of the older versions WITH Bookview and using that.

OR...here's a shocking idea--open it with Sigil and then learn to use and love PageEdit.

The options are pretty extensive, really.

Hitch

[hobnail]

Originally Posted by phillipgessert

With WYSIWYG, you get folks doing all sorts of arbitrary things that are semantically meaningless but "look right." You have to properly describe the structure of your document, something that is nearly never done by folks using WYSIWYG.

Dern pesky ebooks and their tiresome "semantics" and "structure". Back in the good old days of printed books we didn't have to worry about things like the difference between <i> and <em> or having to use h tags instead of larger bold text.

[DNSB]

Originally Posted by hobnail

Dern pesky ebooks and their tiresome "semantics" and "structure". Back in the good old days of printed books we didn't have to worry about things like the difference between <i> and <em> or having to use h tags instead of larger bold text.

Advocating a move back to the good old days of hot metal typesetting? Been there, done that, still have the scars and em ruler to show for it.

[phillipgessert]

Originally Posted by hobnail

Dern pesky ebooks and their tiresome "semantics" and "structure". Back in the good old days of printed books we didn't have to worry about things like the difference between <i> and <em> or having to use h tags instead of larger bold text.

Lol. I remember stripping negatives and doing weird pasteups and "semantics" for me had no definition outside of being a term applied to sticklers for words. Halcyon days!

[theducks]

Originally Posted by DNSB

Advocating a move back to the good old days of hot metal typesetting? Been there, done that, still have the scars and em ruler to show for it.

You were supposed to pick up your feet fast when the bell dinged.
Squirt alert.
(My High School had 2 Linotypes. I got to use and clean one)

[exaltedwombat]

Originally Posted by DNSB

Advocating a move back to the good old days of hot metal typesetting? Been there, done that, still have the scars and em ruler to show for it.

My grandfather worked on a hot metal Linotype machine up to the 1970s. The company kept just one going for wedding invitations and the like. In his last year before retirement he managed, somehow, to put a finger into the pot.

It was a very clean amputation. All the doctor had to do was trim it a little and fold a flap of skin over the end. Apparently it didn't hurt at the time. The doctor said 'It will in a few days'. And it did.