helloSystem / helloSystem/hello

Make the applications in FreeBSD downloadable

Open
#173 3 comments 0 reactions 0 assignees View on GitHub
enhancement help wanted
Dominant language
No language data
Stars
2.5k
Forks
59
PR merge metrics
No merged PRs in 30d

Description

We need a way to make the applications in FreeBSD accessible to helloSystem users who do not use the command line.

(Triggered by: https://www.youtube.com/watch?v=Ol2IRmeH0qk&t=658s)

There is OctoPkg but it is not suitable: It is full of non-application packages that have no use to "mere mortals" (and are only needed as dependencies), doesn't have application names in correct capitalization and spelling, lacks application icons, and generally does not appeal to a non-technical audience used to "app stores".

Many users nowadays (unfortunately) expect something like an "app store", "app center" from an operating system. Can we make something that goes roughly into this direction but sucks less?

For example, by creating one "placeholder" `.app` bundle for each application in FreeBSD. Like we currently do with LibreOffice and the like. (Ideally, the "placeholder" `.app` bundle would convert itself into a full `.app` bundle when it is executed for the first time, but for the time being, it just installs the application through `pkg`).

For this we need:

* The **application name in correct capitalization and spelling** (e.g., "Qalculate!", "KTurtle", "SpeedCrunch"). Not the all-lowercase atrocity that package managers typically use. We can get this from
* `pkg-descr` *if* the second word is "is", which is often the case but not always
* The AppStream metainfo file at , `/usr/local/share/metainfo/*, in the "name" key in the "component" element, *if* the package has such a file (but for this we need to have access to the package)
* The `*.desktop` file at `/usr/local/share/applications/`, in the `Name=` key in the `[Desktop Entry]` element (but for this we need to have access to the package)
* The **application icon as an 128x128 pixels png** from `/usr/local/share/icons/.*/.*/apps/.*[png|svg]`. Unfortunately some packages only ship scalable versions so we need to take the svg and convert it in those cases (but for this we need to have access to the package)
* The **absolute path of the (main) executable** for the application. We can get this from
* The AppStream metainfo file at , `/usr/local/share/metainfo/*, in the "name" key in the "component" element, *if* the package has such a file. Also, we only get the name but not the full path there. So we would have to take that name and search in the `pkg-plist` file for files at locations on the `$PATH` that have the corresponding name
* For applications without such a file, search in the `pkg-plist` file for files at locations on the `$PATH` and if there is more than one, then pick the one that is most similar to the application name (fuzzy logic)

Packages that contain no `*.desktop` file at `/usr/local/share/applications/` are likely not GUI applications and are hence not of interest to us. An exception may be GNUstep related application. (It's a shame that we have to rely on the pesky Desktop Entry Specification to tell an application package from a non-application package.)

Regarding "we need to have access to the package":
Having to download 100 GB worth of packages is wasteful, slow, and expensive.

Possibly we can use a combination of https://github.com/jbd/httpfs2 or http://httpfs.sourceforge.net/ and libarchive to get packages "mounted" without downloading the entirety of them.

Or possibly we can get https://www.freshports.org/ interested enough to provide this data.

Nice to have would be:
* Whether the application is using Qt/PyQt ("native" and preferred on helloSystem)
* Whether the application is using Gtk or WxWindows
* Whether the application is using Electron
* Whether the application is drawin in GNOME components

We could use this to rank applications in roughly this order.

Note to self: FreeBSDPortsToApps.ipnynb

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.