I am still confused about where you think there is a war, and who would be fighting it.
You ask for order and clarity, this is what the “native” label is supposed to bring: more information (clarity) and more organization (order). So, what is it that makes you unhappy about it? Is it the naming? Is it the definition? Is it that the label is irrelevant to your usage of Haiku and applications? Is it that you want GTK and Qt to get separate categories and be treated more equally to BeAPI? Or is it that you are complaining that this might be the next step?
If it is just irrelevant to you, you could simply ignore that specific label. If you want an idea of wether an app is any good, you can use the 5-star user rating. Or you can rely on the editor’s pick in the featured package tab (which recently has changed hands and received more systematic rules for picking packages).
If it is about the definition, we can discuss about making a better one. For me, in addition or as an alternative to the existing definition, I would say that a “native” package does not bring in unnecessary dependencies and libraries when Haiku already comes with an API to do something equivalent. So,no problem when using some ported libraries that are bundled with Haiku, even if I would recommend to use the wrappers we provide around them where possible. Anyways, that definition only makes things more restrictive, and even less apps would qualify.
You may also consider a definition by exclusion, such as “does not use GTK or Qt”. But then it needs to be revised everytime a new toolkit becomes available.
I’m all for porting all sorts of strange applications to Haiku, but native and non-native applications should definitely be categorized as such if possible. There is nothing to argue here.
Add the “Experimental” attribute for programs that are not well-tested or not fully ported (e.g. this would be suitable for GTK programs).
Add the “Nativity (GUI API)” attribute or some better name (English experts will suggest).
That attribute should contain entries: "native (Haiku GUI API), “GTK”, “Qt”, “Electron” and so on.
Why is that needed? Let’s say there are competing programs with “native”, “Qt” and “GTK” GUI APIs, when I choose a program I immediately want to see this and know what I can expect (for example, GTK programs are only partially suitable for me to use, because keyboard support is not fully ported). For example, if I know that my computer has little memory or weak CPU, then “native” programs are better suited for me and so on.
That’s what I meant when I talked about “order and clarity”. I don’t want ported programs to be discriminated against in any way, thus preventing them from integrating into the Haiku environment as well as possible.
That path (which was considered a long time back) unfortunately gets complicated to manage or automate and is hard to reason about.
The semantics of this feature is probably a situation where making all the people happy all the time is not possible. I think the as-built solution would be comprehensible and useful for a majority of people.
I like that. If I understand you correctly, it means that a “Native” app will run on a default Haiku installation with no further dependencies (of course MyApp can include a libmyapp.so of its own). That gets rid of a lot of grey areas.
But according to this definition, nativity is not just a matter of the GUI. For example, if someone wrote a graphics format converter that ignored the Haiku translators and was a frontend for image magick, it would not be “Native” just because it uses a native GUI component. But it might be a very useful little app!
Grey areas will remain, inevitably. Are yab applications native if they rely on the installation of libyab.so? It’s a dependency, but that dependency itself can be argued to be native. I know people are working on a Python API wrapper. Will those apps be native? I think we still have a few old apps that rely on Santa’s Gift Bag. And so on …
Are we going to end up having a Haiku Court of Nativity Arbitration? Or will we end up with endless debates here in the forums? I’m starting to thing that this was a noble idea, but that it will create more problems than it solves.
That’s stupid. The word discriminate means “to make a difference between”
There is a difference between ported apps and non-ported apps. It is simply beeing made visible before you install stuff. The fact that gtk has such a low quality port drives home that point even more.
In any case native means designed for Haiku. On linux it means designed for linux. It does not say anything about the specific code used apart from that.
Edit: keep in mind that Haiku is an OS ment for casual users, who uses what GUI toolkit is irrelevant info. It’s only relevant if the software is designed for Haiku or not.
Like Michel (I think), that doesn’t seem to me like a terrifically helpful refinement of the term. If you do or don’t provide libcurl in the distribution, does that affect the set of “Haiku already comes with an API” and thus which applications qualify as native?
That isn’t what it means to me. There may be some more abstract definition that captures it, but to me it’s limited to that one concrete quality: uses the interface kit for user interface, or uses something brought from outside. It is a significant distinction that is helpful to me in a catalogue of applications, because native applications will have consistent behavior for input, fonts etc. If Haiku distributions started coming with a Qt or whatever, that would still not be native.
Between Haiku and other POSIX type platforms, this is likely the only major distinction we’re going to see, isn’t it?
[ PS - an application that uses Terminal user interface features, curses or whatever, is still native. ]
No, if I wanted to say “no dependencies”, I would have said “no dependencies”. I think that would be a bad idea. I said “when there is no equivalent shipped with Haiku”. For example, let’s look at Renga: it uses libgloox to implement the xmpp protocol. This seems fine, because Haiku does not ship with an implementation of gloox. But, by the “no dependencies” definition, it would not be native.
Let’s look at WebPositive. Currently it uses curl for http support. Haiku provides an independant implementation of http. So, by my definition, WebPositive would not be a native app. I think we can agree this is too restrictive?
But the expression “discriminate against” contains two words, and the important one was “against”. Damoklas did not suggest to hide the differences, but to acknowledge their existence while also considering them as equals. You can disagree and think native apps are superior (superior, not simply different), but I see no reason to call it stupid.
That’s the part you chose to focus on, but the argument is more that the Qt integration is so good that, for some people, it doesn’t matter anymore that an app uses the BeAPI or Qt API. For them, these are both good, and result in apps they want to use. And, indeed, if you look at the “native” definition we picked, it has one part about look and feel, and another about the API used to achieve it. Some people will only care about one or the other half. Or about other things. I think we can talk about this without having to call arguments stupid…
No, I’d agree it is not native by that merrit.
Native apps should have the same access to “high quality” apis. If that requires to use cURL then the Haiku apis should use cURL and not webkit.
The other current situation leads to issues where two presumeably-native applications behave differently in regards to http but unknown to the user on why this is.
Qt can, in theory, achieve a level of integration that is somewhat similar. (but not the same); In practice this is not the case. Qt has different expectations of how the graphics work than Haikus api has. You can very easily see this if you resize Qt applications or do some (to qt apps) unexpected thing like trying to open files after launch. (This is even more obvious if you try to use any kirigami or qtquickcontrols2 apps that basically don’t render native at all and even have control styles that Haiku doesn’t use like middle mouse direct dragging)
Yes, qt has apis for this (e.g file drops) In practice they are rarely implemented because not all OSes have this.
Qt for example also does not have an api for desktop notifications without registering a deskbar(tray) icon.
The flag only discriminates between two types of applications. Discriminating against something is what users can do based on this flag, but on it’s own it is only information, like the rest in HaikuDepot. Some users might not want to install apps without ratings for example, but that does not mean we should abolish ratings.
A “native” flag is not about “should have”. It’s about significant implementation choices that could make an application perceptibly different from ordinary Haiku applications.
If WebPositive’s choice of HTTP client library has any consequences that are perceptible to a user, the next question would have to be, is this web access characteristic then different from the other native Haiku applications that the user would be familiar with, that implement an HTTP web client?
No. Native software means specific to an OS specific “features” (and/or hardware-specific)- not that the OS doesn’t contain open/closed source components (i.e. AGG/libpng/etc) from elsewhere. Usually, BeOS/Haiku software may use BeOS/Haiku-specific system calls/hooks or interfaces requiring the specific BeOS/Haiku system libraries or a specific BeOS/Haiku component. Sometimes, it is just software that is created specifically for that OS - not as a cross-platform and/or ported application intended and/or available on another OS.
Like software written to specifically utilize Be/Haiku threads versus POSIX threads. Or, specific features and/or implementations on the OS versus on other OS platforms - like BeOS/Haiku Game/Interface/MIDI/Media Kits. Or, create here software that was create on a specific OS. in the same way on another OS may get the moniker of “native” software. versus “ported” software.
Examples:
Beam - Haiku email client
BeShare - file sharing application
CheckBFS - utility tool for Be Flile System
Robinhood - HTTP web server
There is a choice to provide only this information, and not expose Qt vs GTK, for example. So, if you look at it from the “which API does this app use” point of view, the result is making one API more visible, and grouping the other ones together. A form of invisibilization, which is one way you can make negative discrimination.
There are many possible ways to define it, and even more ways we could chose to separate “good” apps from “bad” ones. No single definition will make everyone happy.
For example, another app I wrote is ACE. It was designed for MorphOS using the MUI user interface. My Haiku version uses native Haiku APIs, and replicates the original user interface. Is it a native app?
In this dnscussion, we have seen various definitions that all exclude one of the apps I wrote for Haiku. My conclusion is that there is no point looking for he strictest and purest definition, and that I’m fine with things that are in the “grey area”.
There is a correlation but not a causation, not every app which uses native apis follows the HIG and not every app that follows the HIG is native. (e.g python api applications)
I think “which toolkit/renderer” is a related but different type of information. This can be extracted straight out of the package info however and does not require manual intervention like the native apps label. As with other stuff this is just data so if anyone wants to process this to make this visible in haikudepot as usefull labels that is possible but unrelated to the native label.
(edit: note that cleintsidr currently those are not available for not yet installed applications but is available severside iirc)
I don’t follow - “G” here stands for “Guidelines”? What does the implementation language have to do with this? (Or really any aspect of this question. If part of an application is Rust, does that make it inherently non-native? Not to me.)
Interpreter language is not native. I can understand traditional tech-savvy people prefers minimal runtime dependency as it achieves system wide smallest footprint. Interpreter or large language runtimes are one of things they want avoid if they can.
HIG compliant but non InterfaceKit apps (Qt based or not) can be explained by this. As it is somewhat bloated it doubles (runtime) codesize.
It’s true that native applications are likely lighter weight, to do the same thing.
But I wouldn’t say that therefore, lighter weight applications are native, or that heavier ones are non-native. I have been writing in Ocaml, compiled but there’s a runtime that a C++ program wouldn’t (probably) have. Is that different from Python? Swift? Seems ambiguous, and not really the point. It seems better, for someone who has to make this decision for an application, that it be based on a simple criterion where one can easily unambiguously decide that an application is native if it uses the interface kit.
Yes, that’s what we are discussing, the definition used for the native flag in HaikuDepot is:
So, this definition chose to include two items:
The application follows the guidelines
The application is implemented using the Be API and not, for example, Qt or GTK
These two things are somewhat independant, but the definition of the native flag currently includes both. That excludes applications implemented using Qt, even if they are designed specifically for Haiku (for example, HiQDock) and/or fit very well in the look and feel. That also excludes applications that use the native API in unexpected ways (I can think of CL-Amp, which is a Winamp clone for BeOS that uses the native API, but does its own drawing to implement WinAmp skins on its main window). But on the other hand it includes WebPositive (despite using curl), Renga (despite using gloox), and possibly ACE (despite really being a port of a MorphOS application - but you could debate on some of the non-standard UI widgets used in it).
And then, there can be a wider debate about wether the lightweight-ness and use of few 3rd party libraries is part of the Haiku “look and feel”. Either in a direct way (just using Qt outright disqualifies apps), or in an indirect way (longer startup times, slightly different behavior or rendering of UI controls, not using translators for file formats management, …). In the latter case, it would be possible in theory for someone to build a fully “native” app using Qt, if they solve all of these problems. I would say no such app exists currently, but it really depends on what each person considers “good enough”, and we surely will all have a different subset of expectations. So, the “use Haiku native API” has the advantage of being clear cut, at least.
Yes - but (please excuse the obsessively literal nit-picking!) - this is "uses native Haiku APIs to achieve " the Haiku look and feel GUI.
So as you say, it’s immaterial whether WebPositive takes every chance to “use Haiku native API” in the Network kit, the Media kit, etc. The Interface kit seems to be the only part of the API that figures in this.