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.
6 Likes
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.
3 Likes
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.
https://andreldm.com/2016/04/02/replacing-fltk-callbacks-lambdas.html
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.
6 Likes
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.
Oh I really need to read on newer C++ stuff, seems interesting 
Anyway, for now I think we need testers for what we already have rather than speculating.
In haiku.H line:57
# include "../src/Fl_Font.H"
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.
Oh it’s not supposed to be available to apps? Probably I should include it from the files that really need it.
Odd, it shouldn’t matter, as it’s not used when building an application, cf.
#if !(defined(FL_LIBRARY) || defined(FL_INTERNALS)) // this part is used when compiling an application program
Or does Dillo define either of those to work around something maybe??
Because the mac port also does this.
Indeed…, it’s hard to tell why would Dillo pick up that include.
Well… Dillo is known for having a glacial development pace only progressing when someone shows up and makes people mad by telling them how thier code sucks lol.
Dillo was such junk years ago when it relied on plugins for everything… thankfully they moved the SSL support inside and worked on multithreaded dns and it got more stable. Just about any machine that can run Dillo can run Netsurf anyway… which is alot better.
Well, checking the code…
#define FL_INTERNALS
…
#if !( defined(DISABLE_XEMBED) || defined(WIN32) || defined(__APPLE__) )
Yeah, it brings some internal stuff for X11-specific stuff, just need to add the __HAIKU__ case here to disable it.
Btw, I wrote a recipe for my current branch (you need to enable untested in haikuports.conf).
And I should really sleep but…
HG bundle here.
7 Likes
Actually, you don’t need to patch it for the xembed code, you can just configure it with --disable-xembed flag, and the undefined reference to a_Tls_connect error can be fixed by installing mbedtls_x86_devel and set the --enable-ssl flag, which is actually needed for accessing some sites.
Yes but the configure arg is more for *nix users which can have X11 or not (like, Wayland). Just like on OSX, we know we don’t want X11 at all.
And yes, I ended up installing the package, but still it should build without it.
1 Like
Right…, looking at it from that perspective it makes more sense to patch indeed.
BTW did you also notice the mouse issue i mentioned earlier? or is this happening only to me?
Yep, not sure where it comes from though.
