jackburton79 fixed a case where the cursor color in Terminal wouldn’t be initialized, especially notable when running Terminal as a replicant. He also added support for executing commands in Terminal using the scripting API, and made the cursor when the view isn’t focused empty instead of filled.
As always, thanks to everyone involved for the great work.
Although it’s just a small detail in the big picture, but I’m happy that someone finally created a MIME type for the flattened BMessage files. I’d been wanting to do that for quite some time but never got around to it. Too many projects I guess
Special thanks go out to @augiedoggie !
Yes, but no: there is no Dragger. But it is available for other apps like Genio to embed in their own user interface. Not sure if using replicants is the best way to implement this (I would have gone for a BTerminalView in one of the shared libraries), but I guess it works that way as well.
All the recent reports all start with “This report covers hrevxxx to hrevxxx” without any other introduction. Unfortunately, this is all you see if you look at the Haiku homepage. It would be nice if that header mentionned the highlights of the month (such as the merge of the OpenBSD memory allocator when that was done) or a short overview of what’s going on (such as the ongoing Tracker bugfixes and libc updates).
There is currently a single section for “libroot and kernel”, which tends to get pretty large as there is a lot of activity in these general areas. In some of the reports, even bootloader changes end up in that same section. For my quarterly reports at linuxfr.org, I found that it’s better to split this section in smaller ones, at least separating libroot and kernel.
Overall, the report seems very close to the git log now. When I wrote them, I tried to provide a bit more context on each change: what issue it fixes, is it part of a larger work that doesn’t quite fit in a month, are other parts coming up next, etc.
The reason I’m complaining about this is part because of my attempts to write quarterly reports (I had to dig into the commit logs for some things to remember what it really was about, and it’s not easy to do so after the fact), and also because I recently heard people saying they don’t hear much about Haiku anymore. I think the lack of a clear outline and highlights in these reports means a lot of changes go “under the radar” and are not picked up by tech news websites and other places who could relay them. So that would go a long way, maybe more than we expect, for visibility of the project and the progress being made.
Unfortunately I don’t think I can spare the time to do this myself at the moment. But maybe some of the people who already run their own news websites, or some other members of the community, could help with that? For writing these for a while myself, I know it is difficult to do it month over month, and maybe it would be nice to see some new people handling that task occasionally. If there was a team of maybe 3 people taking turns at it, each of them would have to do it less often and I hope it would make the content more enjoyable to read, and open the way for some experimentation in the report format?
Previous attempts to change memory allocator have bring a lot of disappointments and end up restoring the original. Perhaps is it to early to say though it would be nice to know if we have , or not, seen some downside effects after the change to the new one…
Any disruptive change will bring downsides at first, that is why we test it in the nightlies. from my personal experience this didn’t make much of a difference (which I suppose is good). But we will see
It’s been more than a month and only improvements so far.
Waddlesplash has learnt from his past mistakes and took considerably more time to test this change before merging it
For example, with this change it is possible to build WebKit on 32 bit systems without running out of memory. That had been broken for a while.
Souds like a good idea. Should it be required for every change, or just when there is something interesting to say?
I think it would still need a bit of editorial work at the end (to decide what to highlight in the article header, for example), but it would still make the job easier for the person doing it, and spread the work quite a lot.
I hope that only when there’s a real need. because I doubt my “monthly” one-liners merit anything more than what’s already on the commit message. Also… requiring both gerrit and a PR over github? Doubt that will make some devs happy
You rock!!!