Surprised by the size of the package.
I kind of recall fpc or Lazarus including debug symbols when using default compiler configuration, with binary size that could be drastically reduced with a compiler flags (-Xg if I remember well will place debug symbols in external files, which you can chose not to include in the final package).
Have not been using it for years though so I may be wrong.
The script I use is pretty basic, so no optimization flags used, posted it before here in some thread but I still keep a copy at:
https://raw.githubusercontent.com/Begasus/HaikuScripts/refs/heads/master/scripts/lazarusBuild.sh
Maybe this could be finetuned to slimm down the ending size. 
(Patches welcome 
)
EDIT: thanks @Yann64 the -Xg flag worked fine and installed size went down to less then 800MB (for comparing, the current package in the depot hold +700MB in /system/lib/lazarus).
Been looking on how Arch and Fedora do packaging and changed the script here a few times, the current script looks more like the way it’s done in Fedora as that one still uses “make install”
Manual created package size atm is +151MB, so not that bad.
Next up, try to see if I can get this running within a recipe.
EDIT2: still no go with the recipe, seems to find fpc_source but not the units 
I’ve updated the build script here:
And added a .PackageInfo file to create the package (adjust to your liking )
Only done on 64bit, on 32bit there are cross errors due to multi lib environment.
Creating a package atm which I’ll upload later to codeberg, once done I’ll make an announcement here also.
Strike that last, can’t upload the hpkg to codeberg (or any other I guess), filesize too big.
QtCreator 17.0.0-rc1 build with Qt 6.9.1
Playing around a bit more with the sources I saw QtDesignStudio 4.8.0 is included also, building works fine and it runs fine also, packaging seems to be a problem as it changes something in the QtCreator binary at the end.
Call me blond the Design Studio plugin is already available in the QtCreator package, just needs activating 
2 Likes
No package for this yet? Is the build available anywhere?
Recipe is at haikuports, disabled though as aside of me I don’t know how many already tested this.
There is a test package at: Making sure you're not a bot!
If there are some positive checks there I might enable it in the depot.
PS, the one at codeberg is already a bit outdated, but can’t share my current package due to Qt6 requirement.
1 Like
EDIT:
This popped up and the correct path shoud be /boot/system/data/mlt-7/profiles
Once you put that path in and the app opens, I would exit cleanly and re-open the app so the path is stored. Otherwise you will have to enter it again.
Then this popped up, but clicking OK was fine and the app opened. But the error is persistant, it pops up when trying to open or import a video file and the app crashes.
But this is exciting progress! Great work Begasus!
1 Like
The issue with KIO worker is one of the reasons a few of the KDE applications (read Dolphin and a few others I can’t remember atm) are not defaulting to KF6, others are not directly having this issue.
Sometimes it helps to first install/run the KF5 version and then install the KF6 version, somehow it triggers something so the KIO worker does work.
Trying to keep up with upstream here though
2 Likes
Calligra 25.04.2, needs newer frameworks then the ones currently in the depot (I’ll probably do an update on those next month).
Local build with KF6 6.15.0 and Qt 6.9.1.
4 Likes
Gstreamer 1.26.2 multimedia framework updated. Ported the FFMPEG plugin, gst-libav, so now AAC works for Internet radio streaming services like SomaFM and Radio Paradise.
5 Likes
I’m porting dosemu to Haiku. Unfortunately this will have to wait until beta 6 (needs some missing features in beta 5, and also currently triggers a KDL in some cases).
It allows to run DOS apps almost natively, a bit similar to what Wine does for Windows. So here is Microsoft QBasic running in Haiku terminal
There is also SDL support if you need to run things with a graphical display (it may be possible to write a GUI for it that doesn’t go through SDL and uses a native window, too).
On Linux this can use vm86 or KVM to run the DOS code on the native CPU. On Haiku we have no such things, but there is a CPU emulator in dosemu as well. Still, it will use host code running directly on Haiku as much as possible (to provide DOS and BIOS services).
It should even be possible to run Windows 3.1 in it.
18 Likes
Nice!
On a much, much humbler note, you might find this interesting: Misc Haiku utilities and ports - Browse /emu2 at SourceForge.net
1 Like
Some applications checked with GTK4, still not there yet, but doesn’t look too bad, GTK4 PR is at haikuports, together with libadwaita, gtksourceview5 PR is up also.
6 Likes
Hi @Begasus , thank you for the update, and congratulations for the great work!
Just a comment: besides both applications being GTK, the one on the right (Xournal++) looks way more “integrated” in the overall Haiku GUI than the calculator on the left. Did you had to tweak the first one, to achieve better integration? or that depends solely on how the application was designed?
Thanks in advance!
Hi @un_spacyar both applications were build from source, the calculator one is part of the Gnome apps and using libadwaita, xounap++ just uses GTK4 without libadwaita, don’t know if that is the issue both of them showing up differently.
For the record, this isn’t my work alone, it’s a joint effort on haikuports.
EDIT: no tweaking done on the sources for both.
1 Like
Thanks for the detailed answer, @Begasus yeah, makes sense, probably is related to the libadwaita component
1 Like
Prepping scripts before gear 25.08 is released (KDE libraries/applications). ecode proves to be handy 
2 Likes
It might benefit from a Haiku UI theme.
1 Like
Haven’t checked how this looks on another OS, could you give some hints?
See ecode/docs/uicustomizations.md at main · SpartanJ/ecode · GitHub. You can customize how UI looks with CSS.
One could in principle make a theme that looks native on Haiku.