This is a great gift to the community and if no one has said thank you for that, let me be the first. Enough has been written about the bikeshed at this point that the # of characters about the library probably have reached a point where a sizeable portion of changes could have been made to get it building by now.
Paige appears to offer a value to haiku in in that it available and haiku is in need.
Paige is dated, and written in c, but could probably be turned into c++ library ,without the hard 8 16 32 64 bit issues with effort.
Paige owners are willing to give haiku more favorable licensing for inclusion in tree.
So, how about this to the owner of Paige, consult with your engineer and ask him the following questions for the community.
Is he willing to work on pauge after hours ?
Is he willing to work on a community funded contract ?
Is he willing to fix the issue with 32 64 etc byte sizing ?
Is he willing to maoe paige into a c++ library , and would he be willing to port to haiku ?
If he is willing to do these things, could he give a rought estimate of the financial incentive he would require to tackle this ?
Thank you again for your contribution to the haiku community, letâs see if we can find a way to make this a win for everyone, and if youâre current engineer is not interested can yoy recommend a former or retired engineer familiar with pauge who may be interested in this ???
I may have been too quick to judge. I have not thoroughly examined it but a quick perusal of the code shows it to be pretty decent (for C, haha), and honestly it reminds me a bit of BeOS source code, which I have always found pretty readable. Just because it is old, doesnât mean it is bad, much like some of the code in Haiku.
Like many people lurking around the Haiku community my time is a bit limited but nonetheless I will try to give Paige a real evaluation soon. My main PC is Windows and given Paige seems to work well there I suspect that would be a sensible place to start to explore and try it out before worrying about a Haiku port.
Hopefully the documentation will be enough but if not I can reach out here.
Thatâs a very fair assessment of the situation but Iâm not going to judge people for procrasturbating. This is a big job, and it makes sense to give matters a good think-over before and while people contribute; thereâs already been two pull requests to fix some of the issues and make it 64bit-ready, and even though it ended in failure itâs still progress.
Agreed.
I was going to say that doing this is not tenable, but after some thought, I actually agree with you. The majority of Haiku is C++ code, after all, and it makes sense to have âturtles all the way downâ. The downside, which I was fixated on, is that this would mandate a paradigm shift, from procedural to object-oriented (and yes, I know Haiku is the object-oriented operating system, but there was some instinctual resistance to thinking on these terms).
Thatâs an accurate summary of the situation, yes.
Maybe. Depending on the scope of the work, it would significantly retard progress on our core product.
A contract would significantly lessen the sting of this and compensate us for lost time, yes.
Yes, this could be done.
Remember that the reason weâve even released Paige as a public project is that we need it for one reason and only one (i.e. as an HTML composer for a Windows and Wine-compatible app that specifically also targets Haiku).
The cost would reach the low four figures; weâd be looking at $2,000 to $4,000. On the low end, weâre looking at fixing the byte-size issue and making Paige compile as a 64-bit library (which it currently does not doâbut it does do Unicode). On the high end, weâre looking at putting our core product on the back burner for a little bit and porting Paige to C++.
For a good engineer who knows Paige inside and out, might I suggest Doug Baron of Chilehead Software in Austin, Texas? He can be reached at dougb@chilehead.com.
I fundamentally agree with this approach. Youâll find the documentation more than sufficient, and if not, I can hook you up with our engineer.
I think long term, youâd benefit by turning paige into a c++ library.
For the benefits a engineer willing to work on Paige for 5-10k would absolutely be worth it as it would allow for the development of native apps for word processing etc that are sorely lacking in the haiku software stack
Thanks for the feedback , i think itâs very clarifying.
Apologies for barging into the conversation, but C++ doesnât have to mean OOP. Simply changing function arguments from pointers to (const) references can help a lot with safety and performance. Or using RAII to manage memory where possible, instead of malloc and free. It can also be done gradually, thanks to the two languages being like 80% compatible. You can start slow, by making it so that the C code compiles as C++, which would already be a big step forward, and a good way to get a feel for the task.
I would love to have time to tackle this and maybe this fal I will. My hands are currently crazy busy, I would however contribute some $ to fund a engineer who would be willing to and was familiar with paige.
I mean, I certainly didnât say no to this. But only if you could co-ordinate and scrape some money together.
And I would accept your contribution. If more people signed on to that plan, weâd definitely move in that direction; I assumed folks on the Haiku side might prefer to contribute their time rather than their money to silly library code like this, but my companyâs nothing if not flexible.
Youâre certainly not barging into anything. If I didnât want community input on this, I wouldnât have asked for community input. And if I flubbed a fact, I should hope someone would fact-check me on it.
Hi everyone, so I received a series of emails from the engineer in charge of this project. @memecode, your work was instrumental in getting this over the line. Paige will compile for 64bit soon, and as mentioned, it does already support Unicode. From our perspective as a software development house, we have what we needed, i.e. unencumbered source-level access to it for use as a Unicode-compliant rich-edit toolkit for our MUA product, and so giving that same kind of treatment to Haiku makes a lot of sense.
Hereâs what I can share; the earlier messages in the thread are suffused with proprietary information, but this screenie isnât sensitive at all.
Just as a little âgotchaâ Zig can compile Z code too and is compatible with it, in the sense that you can add new zig code to a C project. It might be possible to do a C->zig gradual progression. Though for upstream this would likely be less than ideal since zig is shill in active development
Iâm also doing a refresh of the documentation, converting from the PostScript file that was the original manual into Markdown source, from which an HTML file will be generated. This is taking a lot of work, of course, as it is 800 pages, but an upload is coming.
If anyone wants to take on the hard work of progressing this to C++ or, apparently, Zig, be my guest (of course, once the 64-bit part of the work is fully done.)
Team HERMES has now invested a fair amount of work into this project. Not only is the 64-bit version (which is yet to be published) approaching completion, but also, the documentation is now available (and therefore editable) in Markdown and HTML formats! This was truly a Herculean taskâit took me and my secretary six weeks of eight-hour days to get it over the line, and thatâs just the first draft.
Anyway, weâre having a bit of trouble hosting the HTML manual on GitHub Pages (hosting as part of the project produces a 404 error, while hosting as part of the organisation refuses to load figures). In any case, Iâm hopeful that weâll get it fixed soon. Try these links (one is guaranteed to work):
Now that the (first draft of the) Programmerâs Guide is done, though, Iâm starting to put some serious thought into the engineering. Getting the platform-independent half of the project to compile as 64-bit is something weâve promised, and we keep our promises⌠but that leaves the platform-specific half.
Obviously, Windows 3.1 and Classic Mac are both there for historical interest only, but that leaves Haiku itself. Reference is made in the existing manual to things like grafports and âColor QuickDrawâ. I may be hopeless with C but this Mac-specific stuff is foreign to me in a whole new way. Does Haiku deal with drawing in this same way?
I know weâve talked about balancing effort between the Team HERMES side and the Haiku side. OK, we will produce a 64-bit version and weâve moved the manual into editable form⌠how much of the remaining work should be ours, for an equitable disposition? Letâs lay it all on the table.
Haikus drawing is usually done by the app_server internally (with the help of the control look which provides drawing implementations for certain UI controls), which for itâs part uses anti-grain-geometry at itâs core.
The idea is usually that libraries and applications link to the interface kit (or application kit?), and that takes care of sending the relevant data over to the application server, with itâs own protocol.
Iâm not sure what data or how paige transfers this? we have applications that can draw more directly too, basically only sending more basic commands to the application server, like webkit does. So depending on how low level the access is required both may be implemented.
I am wondering for a port of paige, if this should become a new kit in haiku or what the plan is? if it becomes a kit than mantenance of the port itself would be haikus responsibility, but it could also be a kit build ontop of the library as third party.
An additional consideration is that we have a newer-er textview in HaikuDepot too, so maybe those two implementations can be merged.
To be honest, iâve not personally looked closely enough at paige to provide a good answer there yet. : )
An early contributor has written a very simplistic text engine for one of the platformâs applications called HaikuDepot and you can find the source for this here. In particular this would show you how to deal with font-metrics and textual rendering.
⌠how much of the remaining work should be ours, for an equitable disposition? Letâs lay it all on the table.
Speaking for myself; as I have said before, although I would like to help and see this as very valuable for the platform, all of my limited âHaiku timeâ is already tied up with the HaikuDepot application and its server component. For this reason I am unable to contribute to this in a hands-on way.
We could post an article on the home page outlining the situation and see if anybody would like to get involved or possibly it might be something where we could try to look at this for a future GSOC project where a graduate student might be able to contribute as a project?
âModular edit viewâ has been in the gsoc ideas list for many years. It does not seem to attract the interest of GSoC candidates, at least not in the way the idea is currently written.
I think it also wants to handle too many things at the same time. I donât believe a code editor ano a word processor would have so much in common that they could be based on the same user interface widget.
Iâm not sure what youemean here, WebKit uses BView and the interface kit like any other application. Paige can probably get a backend using a limited set of BView APIs: of course the ones related to drawing text (DrawString, StringWidth), and maybe StrokeLine and FillRect. Depending on the invalidation/redrawing model, it could either draw directly to an on-screen view, or use an offscreen view rendering to a bitmap.
This is the $64,000 question. Everything else is semantic sugar that really serves to sidestep grappling with this. So, hereâs my view: the Paige library is essentially an abstraction layer that saves application developers from having to deal with Haiku (or Windows) drawing primitives. So half of the library is cross-platform, furnishing Paige text-processing (as opposed to drawing) primitives, and the other half is platform-specific. And these are parted out into their own directories.
Which means that talking about a âportâ is not exactly right. The cross-platform half just needs to build and run (and it would obviously come in useful for us too), while the platform-specific half does need a port.
Iâd love for this to become a new kit for Haiku. Either just the platform-specific half, or the whole damn thing. What would make most sense to you?
This would, I think, be ideal (perhaps both of those options at once, should this gain traction in a meaningful way; the GSOC option would especially be good for further development if and when the library is used by multiple projects).
Moreâs the pity.
Thatâs what I tried doing with the documentation: transferring it to a modern, editable format, and weâre obviously in the process of editing it as the development track continues.
Oh, really. Both a code editor and a word processor need to be able to show a blinking caret, change font style/size/colour, move the caret to the left and the right by word, by page, by screen, etc. These are basic text mechanics that essentially anything that deals with text needs to tick off.
Obviously, a code editor doesnât need to be able to do hyperlinks. A Markdown editor does. But thatâs why the text edit needs to include a set of hyperlink primitives, and when a programmer sits down and decides he wants to write a Markdown editor, these primitives are right there in the manual for him. If he doesnât need hypertext capability, he can just leave them out.
The idea is that text reflow around images and such, aswell as severall styles, fallbacks and fonts is a much more complex task than what a code editor needs.
A code editor on the other hand needs to parse syntax, color stuff automatically etc.
This leaves stuff out of the equation what is expected of word processing software (editors) nowadays, like inline tables with calculation, rendering graphs from this etc.
edit: basically both deal with âtextâ but are quite different tasks apart from that.
The thing is, native applications donât need to do this at all, unless you want to draw something specific, and in that case you want some drawing primitives, either an abstraction that maps cleanly or the native api. Or your own library that draws to an off-screen surface and just hands it off.
Is paige to be seen more like an alternative to sdl2? I think in that case I misunderstood quite badly what it is about.
For a haiku port the two options would pretty much be:
A) Import this into a Haiku kit, make a native haiku api to access paige this would allow native haiku applications to use it without requiring third party libraries.
B) Port paige to haiku but do not provide a native api, stick with the C-like api (even if exposed to C++)
I think option B would allow cross-platform apps that use paige to more easily target haiku, but would make it harder for Native applications to use it.
I think Haiku could benefit most, if it really does do the job of text layouting etc quite good by importing it, but this goes to the detriment of the cross-platform nature of the library.
The question then really becomes what you want to achieve with paige at this point, do you want this to be a cross-platform library for cross-platform applications? or is your intention to make this available to Haiku applications in a first sense as an alternative to the native api or even integrate it into the native api.
If I understand the above conversation correctly, you could have a team working on (A) and another on (B), since Paige is a two-part entity already.
Whether we have the manpower (am I still allowed to say that, okay, personpower) for that is of course a different issue. Iâm not exactly seeing a flood of volunteers.
More seriously: at the moment I donât think itws time to talk about integrating this into Haiku sourcecode repository. That would just lead to maintaining different versions, and trouble synchronizing them, right? And it doesnât need to âtouchâ any Haiku internals. The BView interface should provide all it needs.
So, this can be a 3rd party library, and doing it this way gives the most flexibility in this case for getting it up and running.
The next question is⌠what will we do with this next? A word processor? An html renderer? A generic document viewer for docx and other word processing formats? Some richtext notetaking/personal wiki/ideas organizer/sketchbook/notebook app? Try to use it for a code editor despite it being way too complex for that?
Without an application to use it, the whole thing seems a bit pointless to me. If you have a solution looking for a problem, Iâm not sure you end up making the best choices in integrating it
