Paige - a free cross-platform RichEdit toolkit/library with 800 pages of docs

Very recently, my company decided to release a cross-platform styled text edit/display library in C called Paige. It was originally written by an outfit called DataPak Software in Washington state, we bought out their IP several years ago as part of some routine yak shaving, but the decision to release this IP only came recently.

Ideally, this library should be fully cross-platform, meaning compatible with UNIXes (Linux and macOS), 32 and 64-bit Windows, Haiku, and the long-dead (but unmourned) Classic Mac. Not sure what it is in fact compatible with; the documentation mentions Windows and Classic Mac, although it was the right age for BeOS and Metrowerks’ C compiler was shared between PowerPC iMacs and the BeBox.

Here’s the GitHub page:

8 Likes

This would satisfy the requirements of my first post on this forum. I need to look into this farther.

edit

LGPL 2.1 license looks really hopeful! I looked into something like this for a forum browser or emailing list frontend using HTML formatting and it looks hopeful for that too!

Going by what you say, yes, it would. @PulkoMandy actually raises a very important point.

This is exactly what Paige provides, in a much more advanced sort of way. If you’re writing a word processor, what format it uses and what features it has are entirely up to you. What Paige gives you is the ability to shift text around and to display it in a pretty fashion; it doesn’t give a $#!+ about whether it’s working with a Markdown, HTML, LaTeX, or ODT file—the plasterwork is your responsibility, Paige just provides the plumbing.

I’ll also invite the curious to Jim (“admin”) Rea’s comment on the ProVUE forums, for a little bit of extra history: More Word Processor SO uses - #6 by admin - Panorama X - Panorama Discussion Forum

1 Like

Hi @nmatavka;

That’s an interesting library although it is using an integer coordinate system. I see you have dropped this into the repository quite recently so there is no commit history. Is anybody actually maintaining it at the current time?

Regards.

That’s actually not the easiest question to answer @apl .

Paige is included/used as part of an active Windows product—in other words, it has to build for us to remain in business (hence the reason we bought DataPak’s assets). Some thought was given to eliminating it as a document viewer but retaining it as an editor/composer, for straightforward engineering reasons: there are simply better options (i.e. EdgeHTML) for our specific task.

The complexity is because, other than for our core product, we frankly don’t have the staffing to keep this maintained, especially not for macOS- or Haiku-native apps. If I put someone on this, it is certain that my actual for-profit product would start lagging behind schedule. On the other hand, reconnecting with some of DataPak’s former clients and re-forging those relationships is logical and desirable for us.

In other words, of course we’d like to have someone maintain it to a higher standard than we currently can (that was the point of LGPL’ing it, after all). But is it currently maintained—well, yes and no (or, more exactly, “only to the extent necessary to keep Upstream happy”).

On the other hand, someone is maintaining the documentation, and there will be Git commits in the coming days and weeks.

Ok so I had a look at this. And well? It’s 32bit
 HARD 32 bit
 there are so many places with bad coding standards, casting a ptr to a long (64bit → 32bit truncation!) and lots of places that cast void* to a struct pointer without the correct static cast.

So while it might be great in it’s original environment it’s not going to be easy to make it work in a modern OS. It’s all very VERY old code.

I mean I tried
 but gave up.

The memory management seems like it’s from the 90’s
 there is references to 16bit compilers. Bro.

3 Likes

It is very old; DataPak went out of business between 1997 and 2004. We acquired the code in 2018, for the simple reason that our core product relied on it as an external dependency, and we wanted to ensure that all of “our” source (including aforementioned dependency) was within our control to the fullest extent possible. Whatever could NOT be put within our control was scrubbed—mercilessly.

The decision to put this out for public consumption was made around the Christmas holidays last year. It took us until last month to turn the trick.

That being said, the simple fact is that Haiku does not have a text manipulation engine even comparable to CRichEditCtrl in Windows. Sure, Qt does. GTK does. I have the sense that LibreOffice uses the text engine in whatever toolkit it’s built on but can’t be arsed to determine which one (I believe GTK).

So from that angle letting the Haiku project have it/a fork of it seems like the right thing to do; sure, the engineering effort needed to deal with a project like this might be Gargantuan, but the benefits of offering this toolkit, and thus allowing developers to build Haiku-native apps with good-to-great text-processing abilities, outweigh the drawbacks (and of course it’ll keep Upstream happy). Having a text toolkit like this in Haiku itself would also be pretty big—not as big as having a web toolkit or a media toolkit, but for those of us that sling text around for work, it’s a real God send.

To be fair, this library did tout Windows 3.1 compatibility in a world where Windows 95, 98, and NT4 put together had overwhelming market dominance. It was written by, basically, three men and a dog (the company directors and EVP’s all had the same surname, if that gives you any idea). So it’s packed with features—but it seriously needs whipping into shape.

I’m hoping someone might pick up from where you left off. Many hands make light work. I’m not going to lie, it’s a big ask for a library like this—but from where I sit, there are compelling reasons to try to make this work in a 64bit system, and even if we can’t, it’ll be in a better state than when we got it.

We actually have an experimental one, used by HaikuDepot to show package descriptions. Sure, it is probably missing some features.

I looked at the documentation a bit, and from the API point of view, this seems reasonable and quite complete. The code is indeed quite old and 32 bit only. At least the platform specific bits seem to be separated in a specific directory and set of sourcefiles, but even then, it’s several thousand lines of code just for that.

So, what is your plan here? I think a “publish the sourcecode and wait for the opensource magic fairy to improve and fix it” may not work very well (this is what Netscape tried and Mozilla early days were not going so well). It will surely need a bit more cleanup and maintenance and porting to modern systems before it starts picking up speed?

4 Likes

The license is incompatible for integrating it into haikus tree. This could only be used as an external library.

This is true; it would be a substantial addition to the platform to have proper text-engine functionality but it does look like the work involved is quite considerable unfortunately. :thinking:

As someone who’s right on the line between an ENTP and an ENTJ
 let me tell you, there is a plan here, though not one I could articulate, even to myself (never mind anything like a company meeting over Signal) until recently.

Of course we don’t and oughtn’t depend on “the magic Open Source fairy” to fix things, especially without some significant investment first and foremost from our side, and certainly not without a plan.

The idea of producing/giving away/selling binary Unicode and 64-bit versions of the Paige code came from two of our developers (one of whom is no longer with us, for cause). The idea of giving away the source is mine, and I allocated the Paige file to one specific employee (the one who’d suggested 64-bit Paige in the first place), but only to the extent necessary to get our core product (which we’re hoping to 64-bitify) out the door. Additional effort would have to come from the community.

Now, in any sane world, I’d be able to order this employee to make himself a GitHub account and regularly push code to Git—but I’m afraid there would be some major blowback if I did that and then had to make some other hard decision (this person is deeply distrustful of the distributed version control paradigm and point-blank refuses to learn Git).

On the other hand, he’s openly told me that he’s OK with letting me merge contributions on his behalf (obviously with credit). So I think we’ve got a pretty solid plan of action.

Given that I own the copyright in right of my company, there is nothing legally preventing me from re-licensing it (either in general or for the use of the Haiku project). As long as I’m kept abreast of which licence(s) are acceptable for Haiku purposes, I would and will happily do this.

I’ll bring in my colleague (or, more likely, act as go-between). This wasn’t meant to be a one-person job anyway.

2 Likes

Ok then, I think for me it makes sense to wait a bit for the 64bit version to get at least a little bit of progress. I don’t really have time to add more projects to my own TODO list :slight_smile:

However, if the plan is to sell binaries, while at the same time accepting (unpaid, I assume) contributions from opensource developers, that may raise some eyebrows from potential contributors. And there is also the risk that someone else decides to provide their own binaries and sell them cheaper, or for free. (You can look what happened to X-Chat a few years ago, the main developer tried this for their Windows build, it didn’t go very well).

There are, however, other ways to make money from open source code, that may be selling support, helping other companies integrate the library in their products, or offering services to develop extensions, improvements, porting to new platforms, etc. Well, I’m not here to write your business model.

The MIT license would be preferred for use in Haiku. That being said, it is not a strict rule, and the project uses code licensed under a variety of licenses already.

Vous vous avez trompĂ©. Je parlait en passĂ©-parfait. À l’époque, on discutait les possibilitĂ©s pour distribuer Paige: en dĂ©but, mon collĂšgue amĂ©ricain (lui qui travaille avec nous toujours) a voulu un modĂšle de distribution propriĂ©taire/binary-only avec recompense financiĂšre, mon collĂšgue danois (qui j’ai virĂ© Ă  cause de sa toxicomanie) a voulu la distribution binary-only gratuit, et moi, j’ai voulu le LGPL.

And all this turned into “we’ll Open Source it, but won’t contribute too much so as not to derail our commercial products”. And now it’s, “we’ll Open Source it, give away the binaries, won’t contribute too much so as not to derail our commercial products, and Nick will act as a Git cut-out for whatever’s going on Upstream.”

There is no plan to monetise Paige. Pas du tout.

There has already been progress on the Unicode-compatible version (it’s complete, just not checked into Git yet). 64-bit is next up.

Frankly, we don’t need either of those for Upstream, but they would be a good fit for Haiku (as in, the operating system, not just our products for Haiku).

1 Like

Not the plan. This is not our core product. This is something we acquired because it was a hard dependency for our core product. The original plan was to sit on it—only later did we come to the idea that, basically, “hey, this would work as a product all on its own”.

We can make money from, you know, our actual products; this is just a part of the toolchaine.

1 Like

If it can be relicensed to a permissive license that are great news.

I‘d like input from @leavengood also, iirc he wanted to build a native text editor when time permits.

At the beginning, I was slightly (but only a bit) wary of allowing our trademarks (not the code, which falls under copyright) to be used—especially because shopping it to a major project like Haiku hadn’t entered my mind yet.

Much less stress about it now.

I want to build a native word processor to be more specific though I think the components could also be useful for a text editor.

Last year I wrote an implementation of a piece table in Zig (which is my favorite new language that seeks to supplant or replace C.) I think a piece table is the best core data structure for a text editor and word processor. All I have is this code with some tests.

I did not yet get to the more important task (for a word processor) of a styling engine though I do think that would be the next part. Or probably more importantly getting some text on screen using my piece table so there is something more end-to-end that works (at least somewhat.)

I haven’t looked at what apl has done for HaikuDepot, and honestly I don’t even know the current BTextView architecture, though I will certainly look into those when I get back on this project.

My first impression of this source code for Paige is it looks old with all the all-caps, truncated file names. I could see getting some inspiration from the design (if that makes sense) but I can’t see myself working on this. I just don’t want to work in C if I can avoid it.

So in general if I was going to use a C-ABI library to implement a Haiku word processor I would rather it be the ABI exported by my Zig code, written in 2023-2024 and beyond. Hopefully integrating modern ideas like seamless HTML and PDF export and maybe peer-to-peer document sharing, etc.

Though at this point it is all theoretical, Zig is still in development and making breaking changes, and I don’t know the state of our Haiku port (getting that better would likely also be needed if I want this project of mine to work well.)

3 Likes

Paige emphasises styled text. It’s of a tribe with Microsoft’s CRichEdit class, where you can use it to build a simple text editor but that’s like using an elephant’s trunk to hold onto a peanut: you’re only using a tiny bit of the available oomph.

In Microsoft terms, Notepad uses TextEdit, while Metapad (also a plain-text editor, written as a drop-in replacement for Notepad) uses CRichEdit.

So now the decision needs to be made: a) continue to build your own, b) adapt whatever you can from Paige, or c) contribute to the root of Paige, making it partly your own in the process of course, share and share alike? That’s not my decision to make, it’s not our decision either (meaning, HERMES-the-company or even the Haiku people as a class), that can only be your decision.

I’ll continue to advocate contributing to the root of Paige’s source tree and then leveraging it, both a) for the sound engineering reason that it includes a ready-made styling engine and b) for the egocentric reason that if we don’t find any interest in contributing to the code we’ll do our best to terminate our own reliance on it, and then cut off support.

That’s one factor weighing against leveraging Paige. It’s an entirely valid factor; developer preference trumps all, and I certainly don’t want to make you feel like your menu of options has narrowed (in the
language of reflexive control theory, to cause you to apply reflex to your filter, i.e. exercise a degree of reflexive control over it).

Don’t worry if you don’t understand that last sentence, by the way. Just thinking out loud, so to speak.

Hi @leavengood;

Actually it was @stippi who implemented the text engine that is used in HaikuDepot rather than myself.

I have had some past experience with a text engine and I was keen at one point to try expand on the work done in HaikuDepot to a more general library but I doubt I will realistically have time for this now unfortunately.

Just a random footnote, though of course this isn’t anything anyone here will give much of a $#!+ about, but Paige has its own internal “styled text” format that was used in quite a few applications in the 90’s (though it can read and write, at the very least, to plain-text,. HTML, and I’m almost certain also RTF).

This is something I attempted to use as a selling point with James Rea over at ProVUE, but word-processing is a little-used feature of his RDBMS product, Panorama (competing with FileMaker), and in any case macOS X has its own rich-edit toolkit.

Of DataPak’s other clients that we managed to trace, most are either acquired or bankrupt (tantamount to the fact that of the people who have ever lived, most are now dead—I know, quelle surprise, /s). Of those that have been acquired, most were bought by blue-chip corporations, and I don’t exactly fancy my chances selling to Oracle, Adobe, or SAP; my small shop would be laughed out of the room.

On top of that, my small shop (which, by our reckoning—no $#!+, we actually went over the list together—would be nearly the sole viable sales prospect, if we didn’t own the whole bloody thing ourselves) is already planning to reduce our Paige load for very sound, practical engineering reasons that go quite a bit deeper than “I don’t like this toolkit, let’s get rid of it”.

And this is what was basically the straw that broke the proprietary camel’s back. It’s pretty much Open Source or bust at this moment; I didn’t rate the chances of “bust”, but that’s now looking like a possibility (though not probable).

At a certain point in the product development lifecycle, the choice of fish-or-cut-bait simply dwindles down to the latter, and, like Old Yeller, it’s best not to prolong the inevitable EoL—something I promised myself. (For the record, this is not a stage Paige has reached IMHO; it’s still perfectly good as a rich-text toolkit for Windows, which is a pretty big remaining chunk of what it was meant to do in 1997, but I would never use it as an HTML viewer, i.e. a browser engine, on any operating system, and I’d also never use it for macOS X.)


In any case, these kinds of strategic dilemmata (particularly the blue-chip thing mentioned above) make me almost wish for a return of the “cowboy era” of computing (i.e. the early 1990s). But only almost. I’m neither a psychotherapist nor a psycho-the-rapist.