I read a lot of times about native apps being better than Qt, GTK, and so on… Maybe it would make sense to have an easy way to filter Haiku-native apps in HaikuDepot, after all.
Define native.
2 Likes
Is that really a big problem? By default, the development packages aren´t shown anyway in HaikuDepot.
How can you “accidentally” link to a library?
Don´t get me wrong, I don´t want to advocate widespread use of X11 on Haiku here, I just think having possibilities is better than not to have them. Especially if the work of porting those libs is already done.
It’s haikuports. If something requires the lib, it’s easy to just add it to dependencies without further thinking and checking if there is a --disable-X11 or similar option…
That’s an excuse to remove X11… not a reason. And I’m pretty sure there are no reasons to remove it. Also badly developed HPKG recipes is quite a stretch… even a badly developed hpkg is better than not having it at all though, and it can always be corrected later.
"They clutter the list of packages in HaikuDepot "
That’s absolutely ridiculous… if they do then your featured packages list clearly doesn’t work as it should.
Indeed, I consider the current HaikuDepot UI unusable. Fortunately for me I know my way around pkgman, but HaikuDepot is a source of confusion for most users and not a good way to expose the great software we have.
3 Likes
Hovewer i did most of them (at least the proto recipes), +1 for removing the X11 stuff.
1 Like
So what do you think needs changing? The “show” menu is pretty confusing if you leave something checked… then come back later and then you’re like… is HaikuDepot broken? because it only shows installed packages etc… stuff like that? I only mention this as I just did it in a VM.
I can see how libraries and data packages should probably be hidden… and only pulled in if needed or explicitly installed.
I meant applications built with Haiku APIs, in this context. I see much praise on the advantages Haiku APIs and applications based on them, and how these should be preferred, but it seams that for the end users those advantages are not evident.
Also, it seems that there should be a better separation between GUI applications and other kinds of tools (libraries, drivers…) and a way to sort by recently updated apps (like in web depot).
1 Like
If you can see where I’m going with this, just saying native apps is ambiguous. Should it native mean written from the ground up native, with all-native libs? A native UI with ported libs? Ported apps that have been revamped to use the BeAPI?
1 Like
My HiQDock is one such ‘hybrid’ app (hence the name “Hi” “Q”) that launches and tracks running apps, using native Haiku APIs (Roster), but the UI is mostly built on Qt (with one native UI element to track mouse position when the app does not have the focus).
1 Like
…unfortunately it is…
and there is one solution:
…would it be helpful if you could just filter the X11 stuff out instead of removing them?
In fact I don’t care about the tech used. What I mean by native is that it follows the UI guidelines, use the native look, and behaves seemlessly. Ideally it also means using existing native libraries in preference to existing alternatives.
So it is possible to base your work on Qt, but then, do your app use Translators to get support for extra image formats? Does it support drag and drop of text, color swatches, images, as expected? How about copypaste of styled text? Does it behave properly with workspaces? Does it set its thread priorities in a well-behaving way? Is it as self contained as possible in /boot/system/apps or does it need files all over the filesystem hierarchy?
If you manage to do all this without using the native APIs or while mixing them with other toolkits, that’s fine. But I really can’t see how X11 would help for something like that.
3 Likes
Isn’t X11 going away in the future with Wayland anyway?
You can do what I do; I just fire up a VM somewhere, install a very lightweight Linux distro on it, and then install Xrdp and connect to it from the rdesktop client inside Haiku.
(RDP is superior to VNC, in case you wondered why I use it)
1 Like
There was a commercial version and the FOSS X11 server for BeOS. Most issues stem just from
understanding app_server and porting X11-dependent/related applications to it.
Porting FlightGear and SuperTuxKart to Haiku, those apps also have their X11 lib dependency.
Maybe, we can make more notes on this area of porting to help students/others port Inkscape and GIMP apps
to Haiku - and what modern Haiku native tools/utilities are suggested to help the transition. 
1 Like
That would seem a bit bonkers when if you for some reason need to run an X11 application either locally or remotely you could just fire up a rootless X session… without involving VMs for which Haiku has no hardware acceleration anyway. Perhaps splitting haikuports between “native” and 3rdparty repos like Linux often does.
One way around this might be to Hide X11 based applications in HaikuDepot unless X11 is installed… and clearly indicate them as such. That way they are clearly indicated as foreign in functionality and usability while still being available to anyone that might need them. Certainly duplicate applications with X11 and native interfaces are unwanted.
Also at this rate it will be another couple years before Wayland really takes hold if at all. And even on Wayland you aren’t forced to give up X11 applications.
Speaking of Wayland, whatever happens with it, I was looking at the source…
There are a few Linux-specific lines/requirements in there. BSDs can work around them with kqueue like this.
There are a few contemporary tickets (with patches) about fixing that in their tracker. libevent is mentioned but it looks like they’ll go for a “pick linux.h or bsd.h” type solution,
I have no idea how rendering works on Haiku, and I don’t personally want X or too much extrra linuxism (I have Linux for that) but I mean Wayland doesn’t look as hard as I thought.
IFF wayland were portable, it might be possible to leverage it to support more cross platform UI toolkits as they each add support. (but apparently not FLTK)
I’m more tempted right now to fool around with ph’s gtk work directly. Much bigger task I think, but if that existed it would trump some of the desire for ‘other display servers’. (wow, mmu’s stuff looks great)
EDIT: gtk3 is ugly as heck, tries to munt your title bars, wants to provide a uniform experience everywhere, so awful, and i think gtk4 will be even worse.
What’s the point in porting stuff and then sticking a big DO NOT USE on it?
1 Like
I suppose I’m just struggling to understand why you’d want to spend time porting X11 frameworks and apps (X11 is pretty much end of life; most of the developers have moved to Wayland) which won’t fit into the Haiku UI and will have the issues that @PulkoMandy mentions.
Just my $0.02, but I don’t think Haiku needs any more ported component frameworks/toolkits; there’s the native one, and there’s QT; the GTK one is just rendering to a web browser.
So get rid of it. What have you gained? Takes less disk space on some software depot server or distribution.
Don’t get rid of it. What have you gained? X11 programs running anywhere in the world can be simultaneously directed to a PC or VM running Haiku as an X11 display device.
Look up the expression: “pennywise, pound foolish”
There’s no big picture guy in the Haiku inner circle, just lots of very smart, little picture guys.