This report covers hrev57309 through hrev57363 (again a bit of a shorter month than average.)
It was very interesting to read about the issues with getting Tk to run natively on Haiku. Couldn’t be simple, now could it? Oh well. Thanks for looking into it. Now we know more.
Thanks for another great activity report as always and thanks to everyone else involved!
I found this very useful to build some packages that would take a long time to finish, especially LLVM changes. The GCP guide for Haiku was straightforward to setup: Setting up Haiku on Google Compute Engine | Haiku Project
Just one note that the VM can run out of space very quickly if you don’t have or create another disk to attach it to the VM. (There is no resizing support yet)
Nice progress again! Obvious I can’t really help out on fixing Tk, but could do test runs if need be.
Thank you everyone for your hard work.
What are the developers opinion about what is missing for Haiku to be feature complete? Meaning; what functionality needs to be implemented before Haiku can exit the beta stage and go to a release candidate stage?
None. Our definition of “beta” is “all features complete”. There are no plans for “release candidate”, the next step after beta is R1.
That also explains why a lot of the changes are “not flashy” as Waddlesplash puts it: many bugfixes, performance improvements, and so on.
However, there is still quite a list of bugs to solve, and there is always maintenance work to keep Haiku useful and relevant: continuing to support reasonably current hardware,keeping the web browser up to date so it can render existing websites (not those from 10 years ago), updating ffmpeg, openssl, and other libraries to remain on maintained versions that get security fixes, …
This is all tracked in the bugtracker, there are currently 16 tickets for the next beta:
And then 600+ for R1: Custom Query – Haiku
Both of these lists are, of course, open for discussions, although it seems a better idea to remove things, than to add even more 
Have you considered adding an “activity overview”, like in Gnome?
One thing, I’d like to see in the future beta is an attempt at getting a sorted menu. Long time users are used to launchers and docks of all kind but it is not the case of people trying Haiku for the first time. Also I suspect that it gives a bad impression to people who tried Haiku before and who are seeing that it’s still a problem after many years.
More and more software is available nowadays and it makes it even more obvious.
The solution doesn’t have to be perfect. Even if it ends up being just a try and afterwards a better solution comes up; it would to show that progress are made in that matter.
That would also reduce a bit the apparition of the countless threads, about menu itself but, also about blue and grey folders.
The problem with the menus is that if you now e.g. If you would say, you divide the menu into subcategories like it was at Zeta back then, then all packages that have an entry in the menu have to be revised in this regard and you can’t be sure that everyone will take this step later and in the future.
As far as I know, there are no category entries in the packages, so you can’t divide the menu according to package information.
I would really like that too, but I think it will take a long time to get there. I think that as long as other basic things are not yet done, hardly anyone will have time for this.
Isn’t it the answer to the question already?
If the information about the app would be in the package it would be possible to sort them then!
If HaikuDepot had another attribute like “kind” or “type” , wouldn’t it be possible to filter those attributes to be used in the Desktop menu!
app:office, kind:audio, type:productive
I think the way to go here may be to add a filter bar to Deskbar’s main menu. Not something that’ll replace QuickLaunch by any means, just something analogous to Tracker’s typeahead filtering (but for all the Deskbar folders at once.) I’ll add that to my TODO list.
Good update mate. I recently went from an AMD to nVidia card and initially struggled to get a 4k res working, but then realised some compatability mode setting in my BIOS was forcing rEFInd to use a lower res, and that was the same res used by Haiku. For some reason the vesa buffer feels even snappier on this card, though I did also upgrade the CPU recently so could just be that.
The thing that stops me using Haiku more may or may not be related to 3d acceleration in a way - I use audio over HDMI. I’m guessing that’s a feature of graphics drivers and as such wouldn’t be possible to implement when using vesa, but I don’t know much about it other than it’s a convenient way of sharing my rather old amp between multiple machines as I can just connect it to my monitor.
Get the installer to set up the bootx64.efi file automatically, removing a “barrier to entry” for systems that require it. Initial setup should be as simple as possible.
Perhaps something to save colours schemes. the same way it is done for Terminal, nothing fancy.
Tbere is already third party applications that do this (for example theme manager)
You can also back up your settings and restore them later, that goes for pretty much all preference panels
This should be possible without having to install extra packages. ThemeManager is not saving all colours and I’m not even sure that saving terminal colours is still working.
Open a bug on the bugtracker of it?
In any case, this doesn’t need to be in haiku proper imo : )
Totally agree. The ability to easily install and boot on any machine that could get to a desktop should be an important goal for an upcoming Haiku release. Increases trust in the quality of the system, makes it easier to onboard new contributors, would reduce forum threads by like 10% 
so saves developers from troubleshooting in the forum.
The problem with auto-installing the EFI loader would be with the many different/non-compliant/strange bios implementations around, with people trying to install Haiku alongside their existing OS, and since they do not understand how to copy the file to the right partition, they would also not be able to fix their other OS problems.