General quality of AppImageHub entries still very low ("lipstick on pig")

[KurtPfeifle]

I feel very unhappy feeling the need to use this blunt language, and it is very unfortunate, but....

While it did put some nice lipstick on the old pig, the recent cosmetic updates to AppImageHub did not address most of my criticism going back already more than one years ago:

1. Many of the (now 665, nice!) listed AppImage-d apps do not provide a download link, nor a link to the project's home page from where one might have a chance to douse the AppImage download location through own efforts. Amongst these are even such potential "showcase" apps as Cura, LibreOffice, Scribus, Kdenlive, Kate, Kdevelop, ...
2. Many do not provide any meaningful screenshot.
3. Many (most) do miss essential facts in the overview table (like author of software, author of AppImage, license, logo, valid description, ...).

Other, individual shortcomings, leaving a big part of the stuff underneath the lipstick still to be a "pig":

1. For PowerShell, the link goes to a MS-owned GitHub page where there is no AppImage provided (did MS cancel their AppImage packaging for good?)
2. For QPDF there is still no logo displayed.
3. ImageMagick is still totally missing in the list.
4. MuseScore is still totally missing in the list.
5. [...and so on, and so forth...]

More was filed, discusssed (and rejected or not implemented) in #322, #427, #424 and #315. I do not feel motivated to add more details here, because of the ongoing stubbornness regarding these topics displayed there already... 👎

---

_{Just to clarify: the "pig" here isn't the AppImage project or its splendid technological achievements -- it is just its AppImageHub "showcase".}

[probonopd]

Thanks for commenting here @KurtPfeifle. I agree much still needs to be improved and I am sure you realize that I am doing this in my spare time as a one-man show?

I only add one information to the repository for each application, which is the URL. Everything else needs to be automatically generated from the AppImage itself.

Which means that the resulting set of information on the "product detail page" can only be as good or bad as the information which is inside the AppImage itself.

This means that it is up to application authors to put AppStream metainfo into their AppImages. Everything else is too much for the limited time I can spend on this, sorry.

[probonopd]

To make this more clear, there is now a "Note for application authors" at the bottom of each "product detail page", which explains how to improve the entry.

These are customized for each application, depending on whether the author already provides AppStream metainfo or not.

Please feel free to help upstream application authors to improve.

[probonopd]

Many of the (now 665, nice!) listed AppImage-d apps do not provide a download link

This only works if a) the project ships an AppStream metainfo file inside the AppImage, or b) if the project is hosted on GitHub (in which case we guesstimate the URL).

Amongst these are even such potential "showcase" apps as Cura, LibreOffice, Scribus, Kdenlive, Kate, Kdevelop, ...

Please help improve the situation by asking application authors to ship an AppStream metainfo file inside the AppImage.

Many do not provide any meaningful screenshot.

The screenshot is taken from the AppStream metainfo file inside the AppImage, or, if that doesn't exist, a screen shot is used that was taken during the automated test. It shows reality. If the application shows only a white screen when not connected to the internet, so will the screenshot. If the application shows only a nag screen, so will the screenshot.

Please help improve the situation by asking application authors to improve their application's initial screen, and/or ship an AppStream metainfo file inside the AppImage.

Many (most) do miss essential facts in the overview table (like author of software, author of AppImage, license, logo, valid description, ...).

I cannot get those links out of thin air. And I certainly won't want to keep track of them myself. Hence, and you'll know the answer by now, please help improve the situation by asking application authors to ship an AppStream metainfo file inside the AppImage.

[probonopd]

For PowerShell, the link goes to a MS-owned GitHub page where there is no AppImage provided (did MS cancel their AppImage packaging for good?)

I don't know but indeed the AppImages are missing on their Releases page. Please ask them, not me.

For QPDF there is still no logo displayed.

If you mean https://appimage.github.io/qpdf/, it's a command line tool. Usually command line tools don't really have icons...

ImageMagick is still totally missing in the list.

Triggered a new run of the test for https://github.com/AppImage/appimage.github.io/pull/456.

MuseScore is still totally missing in the list.

Because it is not passing our automated test. Coincidentally, I tried today. https://github.com/AppImage/appimage.github.io/pull/1225.

Please understand that in order for this to be scalable, applications need to pass the automated tests and all information must be extracted automatically. Otherwise I cannot build such a directory in an automatic way.

[KurtPfeifle]

"[....] and I am sure you realize that I am doing this in my spare time as a one-man show?"

I do realize that. But you do not seem to realize that it will remain for a long time a one-man show as long as you refuse to accept improvement suggestions which were made in the past (in writing, in filed issues as well as verbally), such as:

1. Use elements of real crowd-sourcing with respect to the overview table of AppImageHub as well as its sub-pages.

   The website claims to be crowd-sourced, which is a blunt lie since it is automatically generated (not crowd-sourced), but with badly chosen info snippets. Badly chosen, because a lot of them are empty.

   This probably cannot be maintained automatically, true -- but then lets think up a way to include really crowd-sourced info items automatically or semi-automatically, by approving or dis-approving suggested links to logos, screenshots, short and long descriptions and/or download URLs.

   If you are honest to yourself, the table in the end isn't build automatically anyway -- only the final look is automated. A LOT of manual work goes into it when you add any new entry and when you trigger tests.

2. Add an additional info field to distinguish between AppImage packager and the original software author(s), because, realistically, there will not always be a 1:1 match of the two, even if it is your dreamed-up ideal.

   This surely can be automated.

3. Only publish exactly this list of AppImages in the main table, where none of the currently automatically populated columns or fields (icon/name, description, author(s), update information, download URL) is empty. If then only remain 100 entries than 666, then so be it! Add another secondary table then, with 566 entries which you label as "incomplete" according to your "wanted AppImages quality spec".

   This surely can be automated.

"I only add one information to the repository for each application, which is the URL. Everything else needs to be automatically generated from the AppImage itself."

See?
Not crowd-sourced.
probonopd-sourced only. Manual work.

"Which means that the resulting set of information on the "product detail page" can only be as good or bad as the information which is inside the AppImage itself."

Which means, that mostly it is bad. It is bad because most AppImages lack the info you want to display.

One incentive to get more info into the AppImages would be to devide the big table into two:

• One where all the columns have a valid entry and which is the "showcase" table of "premium" AppImages.
• Another secondary one, where some columns have incomplete entries, and which is clearly labelled as "other AppImages where you can help its creator to provide better info so that this app may enter the 'premium' table".

This surely can be automated.

"This means that it is up to application authors to put AppStream metainfo into their AppImages."

To me it currently looks like AppImageHub is just a project that pursues your personal ambition (nothing bad with that, per se) to drive the first line "We currently have XXX apps in our database" as fast as possible to reach the 1000 threshold. But what good is it to boast such a figure to potential users if they cannot find a download URL for half of that number?!

"Everything else is too much for the limited time I can spend on this, sorry."

It's your own fault if you are too stubborn to accept good suggestions for improvements and if you repel and drive away people and potential contributors which could help ending the one-man show it currently is -- unless you like to keep it that way.

[KurtPfeifle]

For PowerShell, the link goes to a MS-owned GitHub page where there is no AppImage provided (did MS cancel their AppImage packaging for good?)

I don't know but indeed the AppImages are missing on their Releases page. Please ask them, not me.

I'm asking you, because your creation "AppImageHub" claims that MS offers an AppImage. Which used to be the case, but no longer is.

For QPDF there is still no logo displayed.

If you mean https://appimage.github.io/qpdf/, it's a command line tool. Usually command line tools don't really have icons...

Not correct. A lot of command line tool projects have their own logo and use them on their web pages as well as frequently in desktop start menus -- so why not use them on AppImageHub when such a CLI tool is available as AppImage and listed on the hub? VIm, ImageMagick, htmldoc, QPDF, ....

In the case of QPDF, this was recently discussed somewhere, and I know its logo IS included in the AppImage's AppDir root as qpdf.png... Could be automatically extracted.

[KurtPfeifle]

ImageMagick is still totally missing in the list.

Triggered a new run of the test for #456.

Sad to be reminded of #456. Sad, because the whole discussion over there is again a reminder of your stubbornness (which is good when pursuing general longterm goals and basic design principles of the AppImage project) being applied in the wrong direction... (Made me add fresh 👍 and 👎 markers to most comments).

[KurtPfeifle]

See also this old suggestion in a #456 comment which seems to require on-going thinking....

[probonopd]

Here is an example conversation of how to work with upstream application authors: https://github.com/oskardolch/SteamCAD/issues/6

Any help doing this is appreciated.

[KurtPfeifle]

@probonopd wrote:

Here is an example conversation of how to work with upstream application authors:
oskardolch/SteamCAD#6

Nice.

Any help doing this is appreciated.

Can you somehow proof for this appreciation? Any evidence?

Here is an example proposal from a year ago, addressing the same overall theme, which was rejected by closing it: #424.

[probonopd]

Can you somehow proof for this appreciation? Any evidence?

Indeed I do highly appreciate working with upstream application providers to include AppStream metainfo in their AppImages.

As you correctly guessed, my primary objective for https://appimage.github.io/ is to list as many available AppImages as possible (that pass the automated tests - which means they run on the oldest still-supported version of Ubuntu), while I consider it the responsibility of upstream application developers to provide nice and beautiful metadata by shipping AppStream metainfo in their AppImages, if they want to have a nicer representation in the catalog.

"Peer produced" for me means that

• Anyone can add a link to an AppImage by sending a pull request as outlined in README.md
• Anyone can help improve the "product detail page" by working with upstream application providers to ship AppStream metainfo in their AppImages
• Anyone can send pull requests to e.g., improve worker.sh which runs the automated tests, or to the Jekyll stuff that generates the web pages

Does that make sense?

[KurtPfeifle]

"Does that make sense?"

Yes, it does. If you agree with the stated goals and definitions as outlined in the paragraphs above, it does. However, as some people (not just me) have argued already with you: these goals and definitions are sub-optimal. Especially your selection of "automatic tests" is not what other people sympathetic to the AppImage project would advice.

Plus, you suddenly change your argument away from "crowd sourced" to "peer produced"...