the wrong inverted mask in xlibe turns them into something weird ).
there is a crash when delete cursor in the XFreeCursor function (when exiting the program).
thread 9562: AzPainter (main)
state: Exception (Segment violation)
Frame IP Function Name
-----------------------------------------------
00000000 00000000 ?
Unable to retrieve disassembly for IP 0: address not contained in any valid image.
0x7f6f912d6e60 0x156ce9b73df XFreeCursor + 0xf
0x7f6f912d6e90 0x1ecdac4eca9 AppCursor_free + 0x19
PS: I purposely put disabling cursors in a separate patch to make it easier to discard this patch after fixing the problems in xlibe.
As impressive as the progress of GTK on Haiku has been so far, they really do not fit in well with the rest of the system. Hopefully that aspect can be improved on later.
Or maybe it should stay that way? Make it work just well enough to be useful, but still bad enough to remind people that Haiku is meant to run its own native apps, not ported Linux or Windows ones
I think there are some small touches that would make GTK applications not so jarring:
Always force GTK applications to use Haiku’s file picker. GTK’s file picker is a huge complaint on any OS, so getting this out of the way would make quite a difference
Make GUI widgets a more appropriate size, similar to native Haiku applications
Adapt the colors and eventually the widget style to look more native
Yes, the applications will still look foreign, but I think the results would be pretty nice. Native is better, but only if there are people making native applications in the first place.
Don’t we already have D-Bus and need it for Qt?
What scares me more is that xdg-desktop-portal is a Flatpak-related project.
Sure,a better integration of GTK would be good,but it’s not worth bringing useless container crap from Linux to Haiku.
If it works without copying large parts of Flatpak,I think it’s a good idea to implement it.
Perhaps, but has it been evaluated yet on how difficult that will be and how sustainable it will be in the long-term? I do not trust that GTK developers won’t make changes that would make it harder over time, incidentally or intentionally.
With the current xlibe texstudio fails to build successfully
.obj/XKeyboard.o: In function `kb::XKeyboard::XKeyboard()':
XKeyboard.cpp:(.text+0x2d9): undefined reference to `XkbIgnoreExtension'
XKeyboard.cpp:(.text+0x346): undefined reference to `XkbAllocKeyboard'
.obj/XKeyboard.o: In function `kb::XKeyboard::set_group(int)':
XKeyboard.cpp:(.text+0x13e8): undefined reference to `XkbLockGroup'
collect2: error: ld returned 1 exit status
Makefile:1124: recipe for target 'texstudio' failed
Make it work just well enough to be useful, but still bad enough to remind people that Haiku is meant to run its own native apps, not ported Linux or Windows ones
It’s a chicken and egg problem, but there is only one way to break the circle: Native software will only come as the user and developer base increases, and that will only grow if there is good software available.
I think instead of artificially limiting the integration of ported software, we should strive to make the user experience the best it can be, and then try to make the native experience even better so users will want software that does things the Haiku way, just like macOS users overwhelmingly prefer native software.
A unified experience is one of the main selling points for Haiku over Linux, and ported/WINE’d software integrating better with the rest of the system than it does on Linux is a great way to show this off.
