@X512 can you produce a mini guide how to port linux program with wayland compatibility layer ? For example worker commander, it uses Xlib, freetype and harfbuzz.
You can’t port X11 applications with the Wayland compatibility layer (well, maybe if xwayland worked, but that’d be a bit inefficient.)
I actually tried running Worker on top of Xlibe. It compiles and runs, but there’s a lot of redraw errors making most text obscured by other content. I didn’t manage to figure out what the problem was there, but it’s probably something relatively simple to fix once the problem has been identified.
I’m not familiar with Worker internals, so I’m not entirely sure what it’s trying to do that’s going wrong. I considered asking its developer, but I didn’t want to bother them unnecessarily…
Emailed the author of Worker Ralf Hoffman about 2 years ago, so think we won’t bother him much with this:
Krusader already ported to Haiku, but some ex-Amigians want to see Worker in Haiku too
What would be easiest to port Worker on ? Haiku has wxwidgets qt and sdl lib.
Some people may be interested in doing this port.
I really can’t tell which is easier. I use a self-written GUI library
which resembles the look and feel of Amiga GUIs. This use a lot of low
level X drawing routines which might be relatively easy to port to SDL,
however it also makes extensive use of X window for each single GUI
element and its event handling and I think there is no replacement for
that in SDL.
It is probably a little bit easier to port it to Qt, but the widget
library I use is not well separated from the underlying X system so
there are a lot of dependencies. Also, you probably need to adjust or
create custom Qt widgets to mimic the look and behavior of the X11 widgets.
A quick’n’dirty hack might be relatively fast to achieve (a couple of
days to few weeks), but for a complete, fully functional replacement it
will probably take much longer. But I can’t really tell, since I don’t
have much knowledge about Qt anyways.
That sounds like he might be amenable to some back-and-forth by which he can indicate what X11 features he is using which Xlibe does not implement correctly. I might see about emailing him myself, then.
1 Like
I spent a bunch of time fixing behavioral differences in Xlibe today. And now:
There’s still redraw glitches, as you can see, but it does seem to (mostly) work now.
21 Likes
Wonderful!!!
1 Like
There are still drawing glitches. They appear to boil down to clearing operations apparently not happening as expected, i.e. regions are repeatedly over-drawn and text stacks up on top of itself.
Forcing full redraws (e.g. moving a window overtop another) causes things to be redrawn correctly, so there’s probably some minor bug here.
Well, I fixed the redraw problems, but that revealed that Worker depends on overlapping-siblings behavior too, just like Tk… 
It doesn’t seem to have the event-handling problems here like Tk does, though, so I made some modifications to the sibling-clipping patch I had and got something at least partially working for that. But it still doesn’t behave correctly, and I’m not entirely sure why. Maybe I’ll ask one of the other developers to take a look…
3 Likes