...
[ 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:
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
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 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…
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.
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.
Agreed on not being full ui tookit, but having coded FLTK based apps in Windows(Xp to 7), common linuxes and an arm device with raw linux framebuffer for the screen, i see not so much competing software in “portability” classification.
Probably wont matter to new app developments if you are writing your new Haiku app, but having it as an UI kit lib shouldnt hurt.
Edit: your lambda usage link makes its callback hell much better, .
However, i agree with Pulkomandy, not a Gsoc matter, as the work done/to do should be just like another 3rd party ported lib/app, and doesnt gives much in the learning process nor the os inners itself.
Gets in the way of compiling apps, i understand it’s needed for compiling fltk itself? but is there a way to remove it pre/post install?
I was compiling Dillo and i had to comment it in order for the build to succeed.
One more thing i noticed while testing Dillo is that the mouse buttons were swapped out (left button for right button), i don’t know wheither it’s a bug in Dillo or that the mouse in fltk is misconfigured for haiku.
.