Hey there,
for many reasons, I’d like my Haiku experience to be as close to “native-only” as possible. Right now though, this seems to be anywhere from rather cumbersome to impossible, because it’s not really apparent how to tell apart ports and hacks from native software.
I know that “native” has a fuzzy definition and that it’s been debated a lot, so for the purpose of this thread, I’d define “native” software as software that…
(1) is not emulated (i. e. no Wine or anything),
(2) has been programmed using the native Haiku libraries for a Haiku look and feel (including widget systems, icons, design conventions, color schemes), and
(3) integrates with the system (e. g. actually hooks into Haiku sound events, supports replicants if possible, pulls contact data from the system address book, works with the default mail client, …).
Unlike KDE for example, Haiku-first software doesn’t have a coherent naming scheme, which is totally fine but makes discovery a little difficult.
I constantly run into the issue where I install some program with a Haiku-like icon that sounds like a native-ish program, only to find out that it’s an unholy mix of Breeze icons and modern Gnome-style design, doesn’t use the system color scheme at all, doesn’t seem to “know” about my contacts or mails, or straight-up has minor features that don’t work.
And in reverse, it also happens - it took forever for me to find pulkomandy’s native RSS client friss, when I thought I had to stick with KDE software to read RSS feeds.
Is there a way currently to show me only Haiku native programs in the Depot?
Exactly this is currently in the work,have a look here: HaikuDepot Featured Packages overhaul - #63 by apl
It has recently been implemented software-wise,but data about a lot of application has to be sorted now.
So after I voiced some issues on this forum about the Featured Apps section on this forum, I am happy to announce that I am now the guy to talk to about this.
…
We can make a separate native apps list later.
The recently deployed version HaikuDepotServer allows for packages to be marked as “native desktop”.
You can set the flag on a package using a hyperlink at the bottom of the “view package” page. You need to ask an admin for the ability to edit this setting on a package. For an admin to set the permission;
Authenticate as admin
Menu > Package authorization
Add Rule
User Nickname: <user’s nickname>
Permission: “Edit Package Native Desktop”
Select “All packages”
Choose “Add Rule” button
There is also a new report which is able to produce a spreadsheet indicating which packages are marked as “native desktop”. As any authenticated user you can find the list of reports on the main menu.
When the data has been entered and capacity is available for making enhancements, it will be possible to use the data.
The option is named a bit weirdly…
Clicking that link directly toggles between native/not-native, right?
So, if the link says: “Configure as native desktop”, that means it is currently set to “not-native”.
And if the link says: “Remove as native desktop”, that means it is currently set to “native”.
Did I get that right?
Maybe those options should be called “Package is flagged as: native” and “Package is flagged as: not native”…
I was going to add an indicator on the package meta-data but if people saw that and it wasn’t correct for the period while the data was being updated then they would be complaining. I’m adding in a simple textual indicator for the next release. In the meantime, you’re quite right in that it is a bit confusing without an indicator. Here is what the links mean…
Configure as native desktop
the package is not currently flagged as native desktop
clicking the link will update the package to flag it as native desktop
Remove as native desktop
the package is flagged as native desktop
clicking the link will update the package to flag is as not native desktop
I’m having a look at the “native desktop” report. It’s quite a long list…
Would it be possible to combine it with the “category report”? Then the list could be filtered for “any category (minus fonts)”, which would hide all the non-GUI apps.
I was actually going to do that to start with but decided to keep them separate in the end. I think both will have a complete list of packages so it should be possible to do a simple VLOOKUP to join the two data sets. Would that be easy enough?
I’m not sure I understand ‘VLOOKUP’, sounds like database jargon.
In any case, I thought I’ll just download the categories report and the native-app report, copy the package name column of the native-app report into the categories report, and go from there.
Unfortunately, the native-app report also has all the _source packages rows, that the cat-report doesn’t. Can those be removed before creating the report?
More unfortunately, even after removing the _source rows, the rows between the two reports don’t match.
For example:
the native-app report has “4colors” and “4colors_j” while the cat-report only has “4colors_j”
the native-app report has “4do_libretro” and “4do_libretro_x86” while the cat-report has none of those
Strangely enough, when I search for “4” on HDS, none of the above is found…
Hi again; I’ve fixed these problems you have mentioned so that change will go out with the next release. Thanks @michel & @humdinger for spotting this!
The VLOOKUP is actually spreadsheet jargon! It is a technique for joining sets of data between two spreadsheets. One could take the data from the categories spreadsheet and “join” it to the native desktop sheet. I know there’s problems right now with the data sets but when that is resolved it would be possible to do this.
I don’t really want to add the extra column to the “categories” spreadsheet because it is used for import and export and so additional columns makes the arrangements more complex.
As the native desktop sheet is export-only, I have added “has icon” as I presume this will be helpful to identify those packages that are supplying applications.
Oh, that means I cannot put a “*” in the ‘native-column’ and hand the CVS file back for importing, right? Oh well…
The ‘has-icon’ column should work as well as the ‘categories-columns’ to filter out non-GUI packages. So that’ll save having to export the categories-report just to copy-paste those columns and avoids any discrepancies between the native-app-report and cat-report.
True, it’s not as complete as filtering-by-category, but it’s close. The few that fall through the cracks can be fixed ‘manually’. Though if there’s no import it’ll all be manually anyway…
I wasn’t aware that this caused much additional work. Then, you are correct, of course. Also, it’s more or less a one-off effort to flag the existing native apps. New apps will get processed - the same as now to set screenshots, categories and translations - as they arrive at HDS.
I’ve finished setting the native-flag for all Haiku apps.
At least those managed at haikuports. Once the flag is visible in the HaikuDepot app, people can start reporting and we can fill in the gaps.
