In the word processing thread, the possibility of an abstract class for doing text editing. Child classes could include an htmlview and pdfview gadget. Is this possible or desirable?
-
As a htmlview you could use the webview from Webkit this should not be a problem
-
As TextView We do have already a TextView Class wich is not so complex (e.g. only supports one undo and redostep no lists and so one) A more advanced one is the one from haikudepot it offers marging settings for paragrahs, bullet list and so on. There is still a lot to do (like implementing setting a style…) but it would be a really good base
-
for the pdfview … could maybe reused from one of hte projects document viewer or so…
Here is one:
http://pdfview.sourceforge.net/
http://skim-app.sourceforge.net/
It is possible to make such a class (or group of classes), that program will not only be able to display the PDF but also to write it as a word processor?
I think we should replace/augment the TextView with the HtmlView, because, unfortunately, Haiku (and BeOS) TextView is not compatible with other systems.
Maybe even additionly necessary for Haiku simple txtview (without styles)?
TxtView
|–TextView (for compatibility with old programs)
|–HtmlView
I think a good idea to have in Haiku such a Writer:
which could create html documents.
That the editor would be able to create and open the archived HTML document, for example:
aaaaa.html.zip, bbbbb.html.7z…
Other file formats can be produced by data translators if necessary.
So we are looking at a Rich Text Editor rather than a Word Processor? It’s a start, but writing is what I do for a living and I, for one, won’t be able to remove all those “other” operating systems and go Haiku-only until I have a word processor with
- auto-updating footnotes
- auto-updating endnotes
- auto-updating cross-references
- an auto-updating reference manager
- ToC and index generation (those can be manual update)
- different levels of page numbering in the same document (i…xii, 1…200)
- multiple languages within the same document for spell- and grammar-checking.
- Track changes/merge documents
That is asking for a lot, I know. It is like hard-core spreadsheet users asking for pivot tables in Sum-It.My point is, though, that this is asking a lot from HTML, which really is a display technology, not an editing technology. A decision taken at this stage will limit us later. RTF is probably too old now, but if you designed your gadget around a subset of ODT, you would be able to expand it later. And OpenOffice isn’t going anywhere, so your documents would be readable by other people for a long time.
Anyway, having Rich Text Editor and Word Processor gadgets are not mutually exclusive. You could do the one now, and then later use the experience gained to do the other. Good luck!
1 Like
Well, there are two parts to a word processor. One is managing the document model (with all auto-updating and complex layouting), and the other is getting it shown on screen.
The text view is only a view, so it only handles the latter. To do this, it needs a rather low-level view of the things to render. It is up to the word processor application to process your document and provide the view with some pre-layouted rendering instructions.
If the text view design starts with “HTML” or “PDF”, I think things have already gone wrong. What we need is a view with an API to drive it. Parsing and rendering specific document formats is not something to be handled on that side, but on the side of applications wanting to use the view.
For HTML, we are mostly covered with WebKit. There is a little work to be done to clean up the APIs for BWebView, but it’s already there in WebKit sources and could be exposed for apps to use it. However, it is not designed to be an editor for HTML documents, more a viewer/browser.
1 Like
Using a web browser style document object model is probably a good idea. There are JavaScript gadgets that do WYSIWYG text editing within the HTML5/CSS3 DOM so translating that into C++ would be one way to do it.
One in progress now is https://github.com/Voog/wysihtml if helps the discussion.
“HTML5, CSS3, and DOM Performance”:
Html5 / javascript does not help at all with a implementation of a nativ (and therefore c++) textview. If you just take a look into the webkit code form haiku
if as you can see even the smallest version of the sourcode (ok it includes also icons and data) but still… is about 600 MB!!!
And this is only to render / paint Html5, css and interpreted Javascript.
Then you still dont have a Documentmanagent and so on.
I think WebKit must to be fully integrated into Haiku. Probably it would be sufficient alone in HTML5 limits. Everything else: addons.
Nowadays, webkit is no less important than gamekit or mediakit. Programmers must have direct access to it.
I am sorry, I too vaguely imagine these matters. How all this would be wise to realize in Haiku system. But, I think HTML5 standard could become a haiku document standard. Especially in these times of paper documents are less and less important than the virtual ones. With the spread of electronic paper, they will play an even smaller role.
1 Like
this is all super beyond me but texlive exists in haiku already and seems much better suited to document management than a web browser
Aren’t the foundation codes of WebKit written in static language such as C++? Don’t JIT compilers map to static machine language?
Once the text gadget is implemented in Haiku it can be used to simplify WebKit.
I like HTML 5 but I think WebAssembly’s bytecode will improve WebKit and other browsers based on it to the next level.
WebKit needs some rather low-level primitives from the OS. On the graphics side, it needs good 2D drawing support which is provided by BView. On other systems it uses cairo or similar APIs. And that’s it, none of the native widgets are actually used (but BControlLook is used to imitate them).
So, it could be the other way around: WebKit could be used as a base for a view able to render a complex document described with html+css. This is what the BWebView is about. I don’t know if it is a suitable tool for building a text editor, however.
For on-screen gadgets a WebAssembly based web engine would be better than a JavaScript engine since WebAssembly compiles statically.