Re: [fltk.coredev] Towards a Wayland platform for the FLTK library ?

GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Towards a Wayland platform for the FLTK library ? "W. B." 17:39 Jun 11 top right image
 
Glad you're happy.
Could you share your experience with your FLTK apps + Wayland?


yes, of course. I set up new targets for 2 of my projects for wayland support.

One of them is pretty simple, it's basically a REST-api client for a webservice - get json-formatted data, show it. Well it's kind of a forum api, so writing posts, searching is also working etc...
The other one is for my work, an in-house database-management frontend of sorts, doing the inhouse office management, accounting etc. pretty complicated (but still very small in size - the DB-system doing the bulk of the work).
Got both to work under wayland. I did however build the libdecor as a static library (didn't want to install it systemwide). so both fltk and libdecor are statically linked.

the linker settings for the first one as follows:

on X11:
curl, fltk, dl, X11, Xrender, Xext, Xinerama, Xcursor, Xfixes, Xft, fontconfig

on Wayland:
curl, fltk, dl, fontconfig, wayland-client, wayland-cursor, cairo, xkbcommon, decor, cairo, pango-1.0, gobject-2.0, pangocairo-1.0, dbus-1

the second (db-management) one has basically the same + some more, like sqlite, mariadb, etc etc

first - I really dislike linking to "gobject". or anything glib related really. POS software. It's here because of Pango, I get it, still - imo stay away from Gnome libs as far as possible...
so far - both programs run. Both tested under "Weston".
The X11 versions of both were used all the time, the second app is mostly used on MacOS however (-> it's a very "apple" house ;) in production


On both the fontrendering is very blurry under wayland. Pango related I think. I remember you (= fltk-core-dev team) had some problems like that in the past. Pango changes. Even little version jumps can have "side-effects". Debian (+ ubuntu etc) stay longer on older versions, Arch etc jumps pretty fast on newer ones. It's a "gnome" library, sigh

On both of my apps it's possible to drag windows not only by the top-bar, just with the mouse, using the "unused" space of a window. This doesn't work on wayland - but the documentation mentions it, so I knew beforehand

On the smaller app I create a window before the Fl::run, it has a reload() function, and there Fl::check() is used 2 times. The window gets created, the reload function is called, afterwards the window->show() is called, and then Fl::run loop is run. It does work on X11 and MacOS just fine. On wayland it crashed - had to remove those two Fl::check() - then it ran. Hmm, don't know why ... - never had such on X11 and MacOS ^^
Besides of that - the smaller app runs just as good as the X11 version (but blurry text-rendering)


The second one however... is far more complex. A lot of Trees, Tables, input-widgets etc. A lot of "text" overall. The resizing of windows is waaaaay faster on X11 and MacOS. Wayland resize is much slower. I use a lot of pop-up windows here (like search dialogs, date/calendar widgets pop ups etc) - they open relative to the widgets on X11/MacOS. On wayland it's all random (the readme.wayland mentioned it, so that's known). It however also happens on Fl_Choices, Fl_Choice_Inputs etc. Fl_Trees with own drawing functions for Fl_Tree_Items seems to be fine.
I use quite a lot "Sub-Windows", so Fl_Windows inside of other Fl_Windows. On Weston if you have some windows open (something non fltk, and some fltk windows), if you use SUPER+tab you can switch between them - the active will be fully drawn, the others slightly transparent. If an fltk window has an "sub-window" inside - that subwindow will be drawn non-transparent (but only! the subwindow). Weston has the option to "minimize", but no real "app-bar". If you minimize it will just fade out and disappear. You can get it back through SUPER+tab switching. Fltk windows try to fade out, then they glitch, and you can see parts of them still (just move the mouse over those glitches to get that portion of the screen to redrawn)

Btw the resizing is much faster under Xwayland on Gnome3-wayland than in native wayland under weston. Need some more tests under Gnome3 wayland though

I do also have slightly modified versions of flVLC and flaxPDF somewhere. VLC itself is working with wayland, and flVLC uses nothing X11 related directly - that one should be relatively easy to get running.
flaxPDF however uses X11 functions directly - afair it uses X11 to directly copy betweedn SHM buffers to draw parts of the PDFs. These two come to my mind because they are relatively complex (= not using only FLTK stuff XD. So I would try to get them to run... My own programs are somewhere inbetween the two mentioned above - the DB-system-client is by far the most complex one

But honestly - it's very impressive so far :)
 

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/e50c461e-5181-4c28-a5ab-b180f60128d9n%40googlegroups.com.
Direct Link to Message ]
 
bottom left image   bottom right image
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2021 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.