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


#21

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.


#22

Volunteers?


#23

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. :slight_smile:


#24

[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.


#25

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


#26

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.


#27

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:


#28

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


#29

Great to see this one!

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


#30

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


#31

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).


#32

@ 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 ../
make

#33

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

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

cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/boot/testing-fltk -D OPTION_USE_GL=OFF -D OPTION_HAIKU_SDL=ON …


Question about X11
#34

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


#35

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.


#36

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

#37

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).


#38

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).


#39

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.


#40

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.