FLTK port (was "Port Debian Package Management System to Haiku")

Interesting. Does it come with bindings to any language besides C++?

Great to see this one!

Hopefully, I will port my project GeomSpace (https://sourceforge.net/projects/geomspace/) to Haiku.

Thanks a bunch for porting that toolkit. The FLDigi (ham radio) program needs FLTK, so now maybe that’s a potential port. Great!

I saw somewhere in the source that your intention is to make FLTK work against the native Haiku graphics kit. That is awesome, as I don’t always feel the need for the overhead of Qt. Albeit, I should learn the native kit lingo (someday).

@ mmu_man:

[ 39%] Building C object src/CMakeFiles/fltk.dir/scandir.c.o
[ 40%] Building C object src/CMakeFiles/fltk.dir/numericsort.c.o
[ 40%] Building C object src/CMakeFiles/fltk.dir/vsnprintf.c.o
[ 40%] Building C object src/CMakeFiles/fltk.dir/xutf8/is_right2left.c.o
[ 40%] Building C object src/CMakeFiles/fltk.dir/xutf8/is_spacing.c.o
In file included from /boot/home/fltk-test-only/src/xutf8/is_spacing.c:22:
/boot/home/fltk-test-only/src/xutf8/../Xutf8.h:24: X11/X.h: No such file or directory

When I tried to build FLTK on Haiku itself, there seemed to be an unmet Xlib dependency. So, I copied the X11 headers from a Ubuntu package into /boot/home/config/non-packaged/include/X11, and the libfltk library built just fine. The only thing I had to do was put the include path (for the X headers) into CMake/setup.cmake, and remove all -lpthreads references (since it’s already in libroot). Fluid didn’t quite build for some reason. But this looks promising!

I think that FLTK could be an easier point of entry for folks to do GUI dev on Haiku (without using Qt). Also, there are a number of interesting Linux apps that could easily be ported with FLTK (including the one I’m currently interested in). So, this is a very interesting project indeed …

For anybody else interested in trying this project, here is some good info:

git clone -b haiku-port-try001 --single-branch https://www.github.com/mmuman/fltk-test-only

Otherwise, the default won’t be the correct branch. Then:

cd fltk-test-only
mkdir build
cd build
cmake ../

(looks like I had a draft reply before I got a working account…)

Ah, I finally got a working discuss account :smiley:


1 Like

Ok, seems FLTK finally made the switch to git, but I’ll have to rebase all my changes…

So, just replayed my old FLTK branches over the proper history (they were written on their “test-only” repository… who publishes stuff expecting people not to use it anyway?):

They are not rebased yet, only over the same commit they were on the old repo.

Just rebased the haiku-1.3-final branch, seems to still work.

If anyone wants to try:

git checkout haiku-1.3-final

pkgman install doxygen graphviz_x86 libpng16_x86_devel jpeg_x86_devel zlib_x86_devel groff

# opens a subshell to use the newer GCC instead of 2.95
setarch x86

# use autoconf, as IIRC this branch lacks some CMake fixes
# (at least pthread stuff)
NOCONFIGURE=1 ./autogen.sh && ./configure --prefix=/boot/testing-fltk --disable-gl --enable-debug

This stuff is / will be used for sure!

My project uses FLTK for GUI, but it is OpenGL centered software. The new version will need OpenGL 3.2 or higher (the first to support geometry shaders and still can be implemented without hardware acceleration). Just now I am debugging the shaders. It is difficult to me to instruct GPU to draw natively non-Euclidean geometry, not only some model thereof.

I tried your FLTK-haiku (1.3.x branch) and observed the lack of OpenGL context. I am oscillating between adding OpenGL to Haiku version of FLTK (it would be nice to upstream Haiku port to official FLTK project, which is really crossplatform) and writing native Haiku API user interface (I always wanted each GeomSpace version to have native look and feel).

The later option mean much larger effort, because the GUI related code is already about half of the codebase. I would be pity to duplicate this code for each and every OS (essentially different 3, Haiku would be the 4th). This GUI code is rather simple and not interesting. OpenGL code instead is what I want to showcase. If FLTK would support (officially or inoffilially) modern OpenGL, it would be brilliant for further research of GPU capabilities for native non-Euclidean geometry (beside the geometry itself of course).

If Haiku supports that opengl version (didnt delve with 3d in haiku yet), i guess the option to improve the fltk port would be better community wise.

I mean, probably native version lovers would love the last option, but then more people using fltk projects woudlnt have the opengl features, and it would be repeated.

Asuming more than 3 of us use fltk nowadays (it is small, embedded, and fast but looks oldie).

I use it exactly for its small size and no bloat. It seems easy to port for this reason. And actually it looks oldie only with default skin, but quite nice with gtk+, plastic or gleam skins.

No, they all look equally bad, seriously!
But customs skins are possible, and an Haiku-looking one could be made if someone is willing to put the effort (as it was done for Qt).

I should also mention IUP, which is a portable toolkit using native widgets. There is a lot to fix in the Haiku port of it, however.


A BeAPI style for FLTK would make for a decent GSoC project probably… not too hard not to little work etc… maybe with opengl context support as a stretch goal.

I would prefer GSoC to focus on native applications rather than supporting ported software.


I see your point, but if someone wants to mentor it and someone is interested in doing it… it would be reasonable to let them.

Also the gleam FLTK scheme isn’t too bad that’s been around since 2014? Probably could be modified to look closer to Haiku also. FLTK seems to have support for getting system colors that could interoperate with Haiku’s native color settings.

I would say that FLTK doesn’t really compete with the BeAPI or most any other API anyway… but it has it’s place for being a lower barrier of entry for somewhat esoteric simple portable applications. Similar to what SDL does for games. I don’t know that it makes sense to use the BeAPI in the same manner, such as statically linked etc…

Well, I’d rather try to have it upstreamed first even without GL, and work from there.


Maybe write a application which can rewrite FLTK to BEAPI as a porting tool, FLTK is ugly and clunky UI IMHO

That doesn’t make much sense as the BeAPI and FLTK are pretty different… FLTK is based heavily around callbacks and BeAPI around Be Messages… The best you are going to be able to do is make FLTK look like the native theme. Also, I guess you could use native APIs from within a FLTK app as well if you wanted… such as opening file pickers etc similar to what QT does.

Apparently modern C++ can pretty up FLTK code though at least a little.

Maybe, if fltk applies to gsoc they can mentor it. But for Haiku as the gsoc org admin I prefer tofocus on ideas that promote what haiku should be, and this means native apps, not porting or improving 3rd party libraries.