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.
So I’ve got Paige compilable, with a Haiku frontend, and in C++. I have also had my team port Eudoramail to Haiku, with the result to be called Hemera. Just bumping the thread if anyone wants to do anything else to/with it.
Yes, it still uses an integer co-ordinate system, though that may soon change.
As for the 5a54bf9 change set, keep in mind I’m not the principal committer here, no matter what the Git logs might say; there were employees and contractors who simply weren’t familiar with the Git SCM (one used Hg, one used something by Perforce…) and I co-ordinated with those people over mail. I am almost certain that the great part of that change set was essentially writing the Haiku part of lhe library.
Licensing, as reiterated multiple times, would be permissive (MIT).
The library is, effectively, 64-bit.
Also @leavengood wanted C++ rather than C. We’ve done him a solid and incremented it. Wait, did I already say that? No matter, saying it again.
So in general, my thoughts about this library have now crystallised to the point that I’m thinking about who owns it. My preferred solution, whether short or long-term, is to give all of it to Haiku to manage. Not only do we write software with this library, but anyone else can, too. It makes sense that Haiku’s primary rich-edit control would be the Paige control. And we have demonstrated that it is relevant by producing a Haiku app that depends on Paige.
There is a truly tiny part of it that’s inapplicable to Haiku, and that’s the Windows adapter. Obviously, we can’t ask that you develop that part—Windows is a direct competitor to Haiku—but then again for-profit business logic doesn’t really apply here, even though common sense dictates that you develop for Haiku first and foremost.
So at most we’d be developing the Windows adapter, we can fork that for ourselves while you take on the management of the rest of the thing.
Why me? My plate is already full, I maintain the web browser, several drivers, and a bunch of other things, in addition to a full-time job not related to Haiku, and many other sideprojects.
If you can wait a few dozen years until I’m done with all that, then yes, I can add it to my TODO list. But that doesn’t seem like the best strategy?
Yes, it still uses an integer co-ordinate system, though that may soon change.
Are you able to elaborate on this “may soon change” a bit further?
My preferred solution, whether short or long-term, is to give all of it to Haiku to manage. … So at most we’d be developing the Windows adapter, we can fork that for ourselves while you take on the management of the rest of the thing.
Do I understand correctly that your suggestion is that the library’s code and documentation would no longer be located at https://github.com/nmatavka/Hermes-Paige and instead, the library would be moved to within the Haiku mono-repo (presume under /src/libs/paige for example) swapping the LGPL license for an MIT license and would presumably be adopted into the Haiku Jam-based build system?
In a hypothetical future where the Haiku mono-repo became the primary location for the library, it would no longer be possible for you to arbitrarily make changes to the library. It may be that changes you are requesting to make are rejected on review. Review may take a long time; especially if there is no reviewer available who is familiar. It could even be that other people are making changes or refactorings to the library that may conflict with your own use such as breaking builds on Windows. The library may also not be updated for a long period of time. Are these sorts of aspects likely to be problematic for you and your interests?
My suggestion is that the library’s code and documentation be forked into the Haiku mono-repo, under an MIT licence (leaving our GitHub-hosted copy licensed under LGPL for other users, but yours may use MIT, and anyone who wishes to can in turn fork your copy). This is essentially a modified/Open Source version of DataPak’s former business strategy. We do ask that you rename your copy to something like openpaige just for the sake of clarity.
The rest of it isn’t problematic at all for us; it’s more important to us that a shared richedit control exists on Haiku than that we are exposed to “loss-of-agency” type scenarios (which is effectively what you’re driving at). If the worst does happen, we’ll either fix it on our end or use the version that we’ll continue to maintain.
Thanks for the clarification. You had also hinted that something may change with regard to the library using an integer coordinate system; are you looking at migrating it to use floating point coordinates?
I believe, nmatavka was simply asking Pulkomandy about his opinion on Paige’s development and maintenance strategies, and not that Pulkomandy handles the library himself.
I have no valuable opinions to offer on what other people do with their code, as long as I don’t end up maintaining it.
So, my only opinion here is I don’t see why this should be hosted in the Haiku repository, it can be handled as any 3rd party library we use (ffmpeg, openssl, …) by packaging it in haikuports. Unless someone from Haiku development team wants to integrate it.
I don’t really know what we would do with it in Haiku. Wouldn’t it be more appropriate to adopt as part of a native word processor project? (or note taking application or more general “office suite” thing).
Are floating point coordinates really needed? 32 bit coordnates would allow to represent documents 5 meters wide, with an accuracy of a micrometer. That seems good enough for a layout engine?
Not with any certainty. Mostly a shrug. That may (or may not) change in the future.
It does what we need it to do just fine. Personally, I’m happier with it as a shared object that we can pull from, if we ever need it to do subpixel coords—but I’d rather have it as a shared object than an external dependency, everything else be damned.
The number of Windows apps that will ever use a Paige-type control is vanishingly small, because Windows has CRichEditCtrl (a Microsoft Foundation Classes component), and CRichEditCtrl handles virtually every operation that Paige does (but in a different way… which is why we can’t just give up and use CRichEditCtrl ourselves). The number of Haiku apps that may hypothetically use it is much bigger—because Haiku has far fewer practical alternatives and no “everything control”.
Pinging @stippi and @nephele - this should answer your own thoughts about licensing (MIT-license a fork, as stated above)
I was also wondering about that option. I’m trying to read jam/RepositoryRules; are the HPKGs for things like ffmpeg downloaded at build-time and unpacked (even on non-native build) for the headers and then assumed to be available on a Haiku system at runtime?
As you know, there’s a mini text engine in HD today, but a full text engine to better support for links, bullets, right-to-left etc… would be a much larger job. It might be possible to integrate Paige library in instead and avoid needing to do that work.
I’d be keen to at least test this, but as with you, time is in short supply and there are things needing to be dealt with on HDS as well. Let’s see how things go.
And THAT’S why I’m saying it belongs in the monorepo. Because this needs to be replicable. Not just in Haiku Depot but in every application. Identically.
Otherwise, we get apps that each implement some form of text engine, according to what they need, ad hoc, and all mutually incompatible.
Don’t get me wrong. I’m not saying the current approach is not tenable. But I do believe that, for an operating system, bundling a text engine makes more technical and operational sense than not bundling it. And this is something all apps can benefit from: we make practical use of it in our eMail client, it could power a Markdown editor, maybe a lightweight Web browser, a thicker-than-average code editor…
I’m not saying Microsoft always makes the right call (we all know they don’t), but the Microsoft Foundation Classes take broadly the right approach in standardising a set of controls (combo boxes, tick boxes, tabs, etc.) as quasi-native—and Haiku improves mightily on them with its version of views.
Yes. The headers and libraries can be depended on and that will trigger the download and extraction of the hpkg files as needed.
Not at all.
If it gets packaged in haikudepot, every app that wants to use it can use it just the same. We could even ship it in the standard install if needed (as we already do with doznes of other 3rd party libraries: ffmpeg, libpng, libjpeg, … possibly wrapped into convenient “native” APIs when appropriate). I don’t see why this one should be any different?
And, it then becomes possible to update and bugfix it independently of Haiku releases. If you put it in the monorepo, you only get updates whenever Haiku makes a new release, and experience shows that this is less than once every few years.
It also raises the question of how ports to other platforms will be maintained, with headaches in synchronizing Haiku’s version with everyone else’s. As far as I understand, this is supposed to be a cross platform library.
