The scenarios seen in HaikuDepot are a class of usage worth considering. Display of Markdown-like layout for;
User usage conditions
Change logs
User ratings
Package summary etc…
Single-flow, rectangular, styled or un-styled layout + editing. If you need this as a part of an application then having it available from the core libraries is useful; I would say expected.
In the case of HaikuDepot, this would be useful in a straight BView but would also be useful for composition of rectangles of text-flow as part of the drawing of a BView. For example the “Featured Packages” tab has a single BView for the contents of that tab and it would be nice to be able to compose rectangles of text for the packages’ summaries. In this case it is not clear how hard it would be to drop to an API like that provided by Paige; probably this is reasonable to expect.
There are two somewhat independant problems here: layouting the various areas of the page, and then flowing the text into the remaining space. What I understand from Paige docs (but I have not read it very deeply) is that you can give it a list of rectangles it should avoid (in our case this would be a BRegion) and then it will flow the text in the remaining space.
The API seems well designed to isolate it from everything else except for a few interaction points like this, which means it can be developed as a separate library.
Yes, from the API usage point of view this may make sense. But it can still be packaged as a separate HPKG file, maybe with a BeAPI-ish wrapper on top of it. Of course, if it ends up used in HaikuDepot, we will have it as an Haiku build dependency, and then we have to see how to handle that, either as a 3rd party library, or fully integrated in Haiku. I would say it makes sense to keep the multiplatform aspect of Paige, and so develop it outside of Haiku. It would be sad to have a Haiku-specific fork of it and then have to sync it with other versions, but that is also an option, importing it all into Haiku git repository and start hacking there (making it build with Jamfiles, etc).
Well, how would a Haiku developer go about creating a native Markdown editor? Obviously he wants to understand a workspace (i.e. file) as composed of runs of text, some of which are bold, some italic, some hyperlinks, some text needs to flow over and/or around images, and so on.
Paige includes, for example, a class that amounts to, “this text flows around an object/image”. The developer of the Markdown editor doesn’t want to deal with the nitty-gritty of drawing to screen, pixel coördinates, etc. any more than he has to. Even dealing with TrueType rendering may be too much of a hassle.
Such a developer wants to deal with the semantic rules of the Markdown markup language, as in, “double asterisks signify strong emphasis”, plus style sheets, as in, “for this document, the concept of ‘strong emphasis’ is to be symbolised by the use of Monaspace Xenon 600 upright, ‘emphasis’ to be symbolised by Monaspace Argon 400 italic”. In other words, he wants to deal with his application.
Let’s say that, later on, he wants to use his Markdown editor in an e-Mail app. As in, you type the mail in Markdown and it gets sent out as MHTML (i.e. an *.eml or *.mht file, as standard for styled e-Mail). Perhaps he wants to implement mail merge as well (i.e. parametric variables from a spreadsheet or CSV),
With Paige, he can do this quite easily, as the “core” of a Paige-dependent editor is portable; he can even write a Haiku-native editor and have it compile on Windows quite easily.
As mentioned already, Paige is the rough equivalent of the CRichEdit control on Windows, which is used by essentially the majority of apps that deal with text (not just your typical text editor, but programmer’s editors, Markdown editors, HTML editors)
Importing this into a Haiku kit would be the option that I, personally, would endorse. I offer this as an OS-level stand-in for CRichEdit, which comes with Windows, as system default. Whatever we do with Paige (essentially, use it as the back-end of our e-Mail client editing window) can either be done with Haiku Paige, if serious incompatibility isn’t introduced, or it can be done with our crufty old one.
I don’t think there’s a problem with maintaining different versions. If and when the time comes to release the next version of our mail client, we can pull from Haiku if serious incompatibilities aren’t introduced (i.e. if the library still compiles on Windows and still follows the Paige API guide). After all, the library would be far more useful to you than it is to us: we have one app that relies on it, while for you, the sky is quite literally the limit.
How about most of the above (minus the HTML renderer)? CRichEditCtrl has been a core feature of Microsoft Visual C++, i.e. included at the IDE level, since 1992. Most of the “smaller” (i.e. by disc space) text apps use it as the edit control of choice; their implementations of it differ, but the same control is bundled with, oh, roughly every single MFC app in existence.
“Way too complex” is a matter of opinion. My “code editor” of choice happens to be Evil Mode on Emacs. As in, a fully-loaded, turing complete Lisp Machine running in an emulated window that comes with its own editor called “Evil” (Emulated Vi Layer). And its own Web browser. And its own e-Mail client. And its own Tetris game. And its own FTP client. The words “turing complete” should tell you all you need to know about complexity.
Well, I do use another code editor if I need something to load quicker—Lisp Machines are infamously slow—but that editor is called TECO (used to come as default on PDP’s and Vax boxes). I’ll leave you to brush up on how complex TECO can be.
I agree with you.
But then I also agree with you.
That’s kind-of why it comes as two halves. Having the platform-independent portion of Paige developed as a separate library makes sense: obviously, you’re going to depend on that for Haiku, we’re going to depend on that for Eudoramail, team number three could need it for something else… that’s kind of the raison-d’être for a portable richedit control.
But likewise, having the Haiku-specific portion of Paige hosted by Haiku itself makes sense, and pull the rest of it from our Git at regular intervals. That way it can be leveraged as the default richedit control on Haiku, rather than every single app having to pull it from us.
