As far as I know, Audacious is an open-source project…why mark it as ‘native’?
Open source has nothing to do with the app being native or not, it’s just that the code is publicly available.
But it is not native to haiku-os…
You did not get my point
haiku depot , under ‘featured packages’ has a mark as ‘native’ for some applications
Audacious is marked as native
Well, the way you mentioned that the app is open source made it sound as if its nativeness was somehow linked…
Anyway, mistakes happen. I may have misclicked. It’s fixed now. If anyone find more packages that are mistakenly marked ‘native’, or vice-versa, let me know.
2 Likes
Are there any specific “nativeness” criteria used? Even Haiku itself uses not “native” libraries.
The HDS site states:
A package is considered native if it supplies desktop application(s) with a human-facing GUI that aligns to the Haiku “look and feel” and uses native Haiku APIs to achieve this.
1 Like
The app GUI must use the Haiku API. That’s it, other addons don’t count.
…So there should be a “Native GUI” tag.
…So, the Linux desktop wars have come to Haiku (as I mentioned in another thread).
I think they are not needed here.
…I think Haiku would rather have some kind of beta channel (or some kind of tag at least) for incompletely ported or tested programs.
That means Emacs is a native app. It directly uses classes/methods from the Haiku kits, including the InterfaceKit, StorageKit, TranslationRoster…
Then, in the “Nativeness” or more precisely “GUI” section, you should also add “Qt”, “GTK”, “FLTK”, “Electron” and anything else, if necessary.
…That should make more sense.
…That should make more sense.
All that “native” is nonsense and makes no sense!
Works only with “HAIKU” or “BeOs” would be clear!
What are you even talking about?
We have an Operating system, and libraries to write applications and expectations how those behave. Marking those clearly makes it very easy to find properly working applications designed for Haiku. We are not a linux distro and don’t want to be.
4 Likes
This sounds better than “native” while retaining the same meaning, IMO.
3 Likes
You are the one trying to start a war here. If you don’t care about the UI integration of apps or what they are built with, you can ignore this tag, and let people who think it is important use it as they see fit. And everyone can live in peace.
It seems a bit strange to say that this comes from Linux, there were similar debates in Mac OS and also discussions in Haiku development and direction for a long time, whereas in Linux it is just normal to mix several ui toolkits.
2 Likes
Good thing we have an icon instead of a label. 
2 Likes
Don’t kill the messenger. The war was already there before I named it (“native” vs. “non-native”).
Ignoring the problem is not the path to peace. The path to peace is the introduction of greater order and clarity. So, that is the motivation for all my previous statements.
There is no war, you are not a messenger for anything here.
Native apps work fine, ported apps work fine. Having clear labeling allows users to make informed decisions. Nothing more, nothing less.
7 Likes
Really, why are you answering me? To “put me in the place” that you yourself assigned to me? Why do you think you have the right to speak and judge on behalf of the entire community?
I disagree. Not all “native” works well. Ported (often only partially) also work mediocrely. Besides, “native” is quite unclear. “Native” of what? and what is “Non-native”? and what is the difference? The “native” notation, convenient only for Haiku API purists, I personally don’t need it, and for those who don’t really get into these things, it’s just an additional confusing thing.
C’mon guys. Why not try to have fun with our OS instead of fighting.
I think it’s quite clear what native means in the context of this thread, even if there maybe some grey areas. Some people care about if an app is native others don’t. What’s the problem, really?
1 Like
If you don’t care about having native apps, then why are you using Haiku?
Honest question.
1 Like