Indeed, maybe then dillo can be ported it has gotten a bit better recentley I like alot of what the dillo win32 port did with removing broken dpi plugins.
Volunteers?
What is your goal in porting FLTK 1.3?
Is there an FLTK application that you would like to run on Haiku? Dillo was mentioned. How does the speeed and functionality of Dillo compare to WebPositive? CinePaint uses FLTK, but I donât know if any other libraries would need to be ported before it would be able to compile on Haiku.
An FLTK application on Haiku would look non-native, correct?
FLTK is a C++ API, like Haiku has a C++ API. Is there a benefit to learning the FLTK API instead of the Haiku API?
I donât want to discourage you from developing for Haiku. Haiku could use many new software developers and applications. I just donât want you to work very hard without seeing results, or get burned out. 
[quote=drcouzelis]What is your goal in porting FLTK 1.3?
Is there an FLTK application that you would like to run on Haiku? Dillo was mentioned. How does the speeed and functionality of Dillo compare to WebPositive? CinePaint uses FLTK, but I donât know if any other libraries would need to be ported before it would be able to compile on Haiku.
An FLTK application on Haiku would look non-native, correct?
FLTK is a C++ API, like Haiku has a C++ API. Is there a benefit to learning the FLTK API instead of the Haiku API?
I donât want to discourage you from developing for Haiku. Haiku could use many new software developers and applications. I just donât want you to work very hard without seeing results, or get burned out. :)[/quote]
I think that the big deal here is to try to bring more apps to Haiku and give more options than just the Haikuâs API for GUI development. We could create native look for FLTK in order of having an app that looks like native. With FLTK, we got Fluid, where you can prototype and compile applications rapidly. Some people are already used to use FLTK, what could incentivate them to port their apps to Haiku instead of learning Haikuâs API to port them.
I believe porting FLTK to haiku is a big win, first of all it is small and fast compared to other GUI libraries and secondly using it makes your application portable, while Haiku API is only for Haiku, so for many rewriting an application (with Haiku API) to work under Haiku just donât make sence
There is also an FLTK port for Symbian S60. It is pure C++ http://sourceforge.net/projects/fltk-s60/?source=dlp. Anyway, after Nokia dumped Symbian operating system there can be former Symbian developers available for the task.
Well, I was bored last xmas so I started porting FLTK.
I just published my current branch here:
https://github.com/mmuman/fltk-test-only/tree/haiku-port-rebasing
Still has some rough edges but itâs mostly usable.
It looks like this:
1 Like
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 directoryWhen 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 ../
make(looks like I had a draft reply before I got a working accountâŚ)
Ah, I finally got a working discuss account 
cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/boot/testing-fltk -D OPTION_USE_GL=OFF -D OPTION_HAIKU_SDL=ON âŚ
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
3 Likes
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.
4 Likes