Text editor haiku under gsoc 2020

Hello everyone I’m trying to understand this idea listed in gsoc 2020 .

"The current solution for text editing in Haiku is the BTextView. It is a rather simple view providing basic text editing features and limited styling. This is, however, not powerful enough for most serious uses. The goal of this project is to design a complete replacement for BTexView, which should be designed to cover more use cases.

The edit view design should be modular and extensible to make it easy to implement e.g. following features:

● spell checker
● line numbers, ruler, 80 character limit line, hyper links
●working on an input stream rather than on a input file e.g. to be able to open files ~100Mb without loading them into memory in one go
● Including pictures in the text flow
● Sourcecode editor: syntax highlighting, code completion
● Ability to load and save data in different formats (using the Translation Kit)

●●●●Existing work

The HaikuDepot application includes preliminary work on a rich text view, which it uses to provide the description of packages. This could be used as a starting point for this work."

I compiled the source code and ran on virtual machine there was no problem in it.However i was not able to understand much after going through docs related to Btexview(this).Can you suggest where to start and clearly understand the above problem statement .



Well, the idea description seems pretty clear to me. We need a “text view” control where we can show complex text. I would put aside all the ideas related to sourcecode: line numbers, ruler, 80 character limit line, syntax highlighting, code completion. These are already handled in the Koder editor.

However, we still need all the other things: spell checker, input stream system (for editing very large files without loading them completely to memory), inserting pictures, and more complex layout than what BTextView currently allows (text flowing around pictures, bullet points, …)

Imagine that you would want to write a word processor for Haiku. If you tried to use BTextView, you could not get much further than what StyledEdit does, and no one would consider that a serious word processor.

Source code editor (monospace font, word wrap modes like in Pe, syntax highlighting, error highlighting, autocomplete, support large texts etc.) and rich text editor (support of complex styles, layout, objects embedding etc.) require different features and I think that having 2 different editors is the best solution.

1 Like

I think this is an interesting area to work on because a generalized text engine that is able to deal with a reasonable range of situations would be a significant asset to the platform. The current BTextView is not able to handle complex text layout required by some languages and is also not able to handle more complex structured text such as bullets, tabs etc… To support those features a more sophisticated text engine needs to be designed and implemented.

An important dimension to this area is thinking through the data structures for storing and managing structured text. Consider representing a Markdown document in objects and being able to edit that document efficiently over a large piece of data. For some background understanding, consider a study of the Pango data model or the data model used in the Cocoa text engine (NSTextContainer, NSLayoutManager, NSTextStorage, …).

A real-world example in HaikuDepot that might benefit from the presence of a text engine is [the rendering of usage conditions.

There is now Scintilla for Haiku, as used by Koder (which may be good enough we should just replace Pe in the default install with it; at least I’ve been using it for a while and it is much better) which already handles this.l


The HaikuDepot Textview supports this already… but it needs features like changing bullet points and enable number support … but this should be pretty straight forward to implement.
There is also support for inset of a paragraph and so on … its quite advanced :smiley:

Yes, it’s a good start and I think it is mentionned in the project idea. But, I think it does not currently supports editing? Which will surely make things a bit more complex.

It already support editing… -> Some important features are missing … like “exit” a bullet list (pressing two times enter on a empty bullet and so on)
but undo redo is not supported yet.
the basic implementation is prepared… but from my point of view this could be done better :-), because its implemented this way, that it stores the difference between the previous document and the new document - which makes it more diffcult to implemnt new things like inserting Pictures… i preffer a commando design pattern there (where the commando nows how to undo the changes he did)… but i guess this depens on my personal prefferences :slight_smile:
Also seeking (from what i rember) isnt support so well.

Actually i thought about the possibility that the new TextView could accept Replicants which would it make possible to instantly have a lot more features in a textdocument :-D. That could also be a way to support picutres, Clocks and so on…
Just think about the possibility to add sum-it as a replicant… that would be so cool :smiley:

Koder has lack of important features compared to Pe:

  1. No function list.
  2. No header list and it is not possible to open header file referenced in source.
  3. No execute command feature.
  4. No compiler error listing feature.
  5. Can’t edit same file in multiple views. Pe supports editor vertical splitting.

It also has some minor issues:

  1. Auto-scrolling while mouse is down is not working properly. Pe is working fine.
  2. Context menu appear at strange position.
  3. Indent with Alt+[, Alt+] is not working.
  4. Search in backward direction is not working.
  5. Tool bar is too big compared to Pe. Note that BMenuBar can be used for toolbar, see https://github.com/X547/HaikuUtils/tree/master/Services.
1 Like

There are clearly at least two feature sets represented there: text (or code ) editing and word processing.

Spell-checking (and possibly rudimentary grammar), rulers, pictures in the flow, and hyperlinks strike me as really only useful in word processing.

Similarly line numbers, arbitrary line length limits besides wrapping and non-printing characters, and word completion/syntax highlighting aren’t really needed for taking notes or word processing.

Some basic lexical analysis is needed to do syntax highlighting and auto-complete, but underlined misspellings are mostly a distraction in a text editor. OTOH a word processor without spellcheck would be like a car with three wheels.

Dealing with files as input streams and loading and saving files to/from different format sound potentially useful in all kinds of cases.

1 Like