Yes, it’s part of Scribe and the editor code is here. Generally it supports styled text (fonts/colours, bold, underline etc), links, images, emoji and horizontal rules. It’s built on Lgi which does have Haiku bindings. And while Scribe will build on Haiku it’s certainly not setup for haiku threading and would likely crash at the drop of a hat. The whole every window is a thread model is so different to Mac/Windows/Linux that it makes porting difficult.
1 Like
GTK, Qt, etc. don’t seem to have problems here, likely because the port code just has all the event loop handling on the main thread still and just locks the window threads when it wants to do something with them, transparent to the consumers of the APIs.
1 Like
This is interesting, but I don’t really understand how this works. The events for each view come in on that window’s thread. Does the view’s event handlers re-post the event over the “main” thread? Like to handle a mouse click? By default the main thread can’t see the events on some other window otherwise.
A quick note here, you can call:
uint32 buttons = Window()->CurrentMessage()->GetInt32(“buttons”, 0);
to get the current mouse button state in MouseUp() and MouseDown(). GetMouse() has some threading issues and is best avoided when possible. It doesn’t look like you are using the absoluteLoc point.
1 Like
Yes, that’s how it works. You can take a look at how Xlibe does this, for example (it generates a regular X11 event struct and then invokes an internal function _x_put_event to post it to the main event queue.)
2 Likes
Thanks also from my side, it’s the same strategy in liblitehtml (to circle back to the thread topic…:wink ).
I’m still not sure why my BView override is never called although the view has focus…
Thanks but that looks a bit hacky to me and should not be necessary, as I’m using a normal BView override that works fine in other code. But it’s worth testing to track down this issue.
I don’t need the absolute location but iirc the function parameter is mandatory.
Suit yourself, GetMouse() is only a real problem in MouseMoved() since it gets called over and over again. It’s easier to get the button state from the message even in MouseUp() and Down().
Ah that’s what you mean, okay that makes sense!
so I was too strict with mouse button checking, works now:)
Also fixed unnecessary redraw and other annoyances.
Looks quite good now, will add support for gradients next, because it’s actually called e.g. for the Haiku website,-)
4 Likes
NetSurf doesn’t mix javascript with other parts of their engine. You can simply not link the javascript library and have just the HTML and CSS rendering.
I don’t think you are going to be much more efficient and light than their libraries if you want decent HTML+CSS support. You don’t have to reuse the whole browser, and you can cherry pick from their work as needed. For example in Renga I use just their CSS parser, because that’s all I needed (I already have an XML parsing for XMPP). It was very easy to plug it together with my own code.
Anyway, I expect the component will be relatively easy to swap in and out with different implementations once it has a well defined API, so that doesn’t really matter 
1 Like
Now you got me interested, will try this out next:nerd_face:
and yes, that’s the plan.
The API can be really simple and it currently only has like 3 methods to read HTML from a URI or path, and to render it (with or without remote resource loading).
Does it support text selection?
You can still reply to HTML mails in text mode, which is what I usually do, as a subtle protest against the proliferation of unnecessarily bloated HTML “text” mail with no visual gain but proprietary Windows fonts usually sent out by MS Outlook…
Opening in a browser forfeits any security checking usually done in Mail and is not as quick and pleasant while browsing through your mail.
1 Like
hmmm I had a look at the project but only found a HTML, CSS and DOM parser, but no rendering infrastructure.
I’m quite far with liblitehtml though and am working on Mail integration now…
You can follow my progress here:
https://dev.haiku-os.org/ticket/18386#comment:2
Also cleaning up the code a bit while I’m at it, it’s a bit ugly as it directly accesses the TextView through the Content layer 
Since we no longer deal with always only text mail, I took the liberty to separate this out into separate class files and accessing only the ContentView from the MailWindow, leaving the mail rendering to the Content layer as it should be.
I think the Haiku source should also act as an example on how to do it right, so we should invest some time in cleaning up the code as we move along, else Haiku apps will accumulate too much cruft until we finally reach R1 
5 Likes
It looks like the layout part is “currently” (last change was 6 years ago) being worked on as a separate library, but that has not been released yet.
So, yes, you’re right, the only easily reusable part would be the HTML parsing, the DOM, and the CSS library. Other parts would need to be extracted from NetSurf and into a library, which may be more work than desirable here.
2 Likes