Skip to content

Commit 7eef750

Browse files
committed
Updating Docs for commit 8c770d6 made on 2025-04-05T06:35:23+00:00 from refs/heads/main by probonopd
0 parents  commit 7eef750

File tree

168 files changed

+37996
-0
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

168 files changed

+37996
-0
lines changed

.buildinfo

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
# Sphinx build info version 1
2+
# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
3+
config: 2ea8f8c084aeebea80a4955dd7d6f9b7
4+
tags: 645f666f9bcd5a90fca523b33c5a78b7

.nojekyll

Whitespace-only changes.

README.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
# GitHub Pages Cache
2+
3+
Nothing to see here. The contents of this branch are essentially a cache that's not intended to be viewed on github.com.
4+
5+
For more information on how this documentation is built using Sphinx, Read the Docs, and GitHub Actions/Pages, see another branch in this repository.
Lines changed: 145 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,145 @@
1+
# Acknowledgements
2+
3+
Grateful acknowledgement is made to the following persons and organizations.
4+
5+
Mentions roughly in the order of first involvement with the project.
6+
7+
## FreeBSD project
8+
[https://www.freebsd.org/](https://www.freebsd.org/)
9+
* Providing the underlying operating system
10+
11+
## FreeBSD port maintainers
12+
As listed on [https://www.freshports.org/](https://www.freshports.org/)
13+
* Providing end user applications
14+
15+
## Simon Peter
16+
__[probonopd](https://github.com/probonopd)__
17+
@probonopd on twitter
18+
* Founded the project
19+
* Acting as the main developer
20+
21+
## Joe Maloney
22+
__[pkgdemon](https://github.com/pkgdemon)__
23+
malco2001 on irc (#FuryBSD)
24+
* Originally wrote the tools to create Live ISOs for FuryBSD
25+
26+
## Cirrus CI
27+
[https://cirrus-ci.com/](https://cirrus-ci.com/)
28+
* Providing continuous build infrastructure
29+
30+
## Fedor Korotkov
31+
__[fkorotkov](https://github.com/fkorotkov)__
32+
* Provided helpful support concerning all things Cirrus CI
33+
34+
## FreeBSD Foundation
35+
[https://www.freebsdfoundation.org/](https://www.freebsdfoundation.org/)
36+
* Gave permission to use the trademarks in the 'Install FreeBSD' utility
37+
38+
## Sławomir Wojciech Wojtczak
39+
__[vermaden](https://github.com/vermaden)__
40+
@vermaden on twitter
41+
* Provided helpful feedback and configuration advice
42+
* Configuration for tap to click and two-finger scrolling for Synaptics and Elan touchpads
43+
44+
## Reven Martin ([CutefishOS](https://cutefishos.com/))
45+
__[rekols](https://github.com/rekols)__
46+
@revenmartin on twitter, @cutefishos on twitter
47+
* Originally wrote Panda Status Bar, which the hello Menu is based on
48+
* Originally wrote Cyber Dock, which the hello Dock is based on
49+
50+
## Ale Rimoldi
51+
__[aoloe](https://github.com/aoloe)__
52+
@a_l_e on twitter
53+
* Implemented Action Search (search through menubar)
54+
55+
## Antony jr
56+
__[antony-jr](https://github.com/antony-jr)__
57+
@antonyjr0 on twitter
58+
* Put Search field for Action Search in menubar
59+
* Integrated of 'System' menu into menubar
60+
61+
## Keshav Bhatt
62+
__[keshavbhatt](https://github.com/keshavbhatt)__
63+
@keshavmail68 on twitter
64+
* Helped making 'System' menu submenus clickable
65+
66+
## @FreeBSDHelp on twitter
67+
* Reached out to FreeBSD kernel developers
68+
69+
## TheAssassin
70+
__[TheAssassin](https://github.com/TheAssassin)__
71+
* Improved documentation by providing Sphinx evangelism and ReStructuredText help
72+
* Helped with CMake and Qt translations
73+
74+
## Leodanis Pozo Ramos
75+
__[lpozo](https://github.com/lpozo)__
76+
* Wrote tutorial and sample code that forms the basis for Calculator.app
77+
78+
## Marcel Kaiser
79+
__[mrclksr](https://github.com/mrclksr)__
80+
* Wrote `initgfx` graphics hardware autoconfiguration
81+
82+
## Graham Perrin
83+
__[grahamperrin](https://github.com/grahamperrin)__
84+
* Provided early testing and feedback
85+
86+
## PreyK
87+
__[PreyK](https://github.com/PreyK)__
88+
* Made System menu to refresh itself automatically
89+
* Fixed Menu and desktop for multi-monitor setups
90+
91+
## Chris Moore
92+
__[moochris](https://github.com/moochris)__
93+
* Improved Filer: Added initial 'spatial mode' option (folders open in a new window) and made already-open windows come to the front rather than opening the same window multiple times
94+
* Made volumes show up on the desktop
95+
* Added menus to the desktop
96+
97+
## Weblate
98+
[hosted.weblate.org](https://hosted.weblate.org/projects/hellosystem)
99+
* Providing infrastructure for crowd-sourced translations
100+
101+
## Chris Rees
102+
__[crees](https://github.com/crees)__
103+
* Made it possible to use a fixed Intel GPU driver for FreeBSD 12.2 from a private package
104+
* Created a package for the Falkon browser that does not pull in many KDE dependencies
105+
* Updated required FreeBSD ports and helped writing new ports
106+
107+
## Jordan Gordeev
108+
* Wrote `geom_rowr` FreeBSD kernel module to combine a read-only with a read-write device
109+
110+
## Jesper Schmitz Mouridsen (jsmdk)
111+
__[jsm222](https://github.com/jsm222)__
112+
* Packaging helloDesktop components for FreeBSD Ports ([details](https://wiki.freebsd.org/helloDesktop))
113+
* Fix for the Global Menu in Chrome and Firefox
114+
* Added patches to Firefox and Thunderbird Ports for global menu support
115+
116+
## Sergey Tyuryukanov
117+
__[s199p.wa1k9k](https://github.com/s199pwa1k9r)__
118+
@S199pWa1k9r on twitter
119+
* Packaging helloDesktop components for FreeBSD Ports on aarch64
120+
121+
## Zoë Knox
122+
__[mszoek](https://github.com/mszoek)__
123+
@thatzoek on twitter
124+
* Implemented `org.freedesktop.FileManager1` API in Filer
125+
126+
## alphamodh0
127+
__[alphamodh0](https://github.com/alphamodh0)__
128+
* Translated helloSystem to Spanish
129+
130+
## Sebastian Birnbach
131+
[https://zweibruecken-ip.de/](https://zweibruecken-ip.de/)
132+
* Donated a Mac mini (Mid 2010) (`Macmini4,1`) to the helloSystem Hardware Test Zoo
133+
134+
## Luna Jernberg
135+
__[bittin](https://github.com/bittin)__
136+
* Swedish translator
137+
138+
## Framework Computer Inc
139+
__[FrameworkComputer](https://github.com/FrameworkComputer)__
140+
* Donated a Framework Mainboard (i5-1135G7) through the Developer Mainboard Program
141+
142+
## Jérôme Ornech
143+
__[Hierosme](https://github.com/Hierosme)__ alias __[Tuuux](https://gitlab.com/Tuuux/)__
144+
* Rewrote Processes.app ([#159](https://github.com/helloSystem/Utilities/pull/159))
145+
* Wrote Network Utility.app
Lines changed: 98 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,98 @@
1+
# Application Bundles
2+
3+
helloSystem uses __application bundles__ to manage native applications. Whenever possible, application bundles are used. XDG-style `.desktop` files are considered legacy and should be avoided.
4+
5+
## Benefits
6+
7+
Applications shipped as application bundles can
8+
9+
* Easily be moved around in the filesystem (relocation)
10+
* Easily be copied to e.g., another machine or a network share
11+
* Easily be copied on the local machine to get a second instance of the same application (e.g., to make changes to it while keeping the original around)
12+
* Easily be deleted by moving to the Trash
13+
* Easily be managed without the need for a package manager
14+
* Easily be modified (e.g., changing the icon) without any side effects to other parts of the system
15+
* Easily be distributed (e.g., in archives like zip files or in disk images) without the need for packaging
16+
* Easily be understood by switchers coming from other operating systems with similar application distribution formats
17+
18+
## Application bundle formats
19+
20+
### `.app` bundles
21+
22+
helloSystem supports simplified GNUstep-style `.app` bundles.
23+
24+
Minimal requirements:
25+
26+
```text
27+
./Application.app
28+
./Application.app/Application <-- (link to) the executable to be launched when Application.app is double clicked
29+
./Application.app/Resources/Application.png <-- the application icon (png format)
30+
./Application.app/Resources/can-open <-- optional, MIME types the application can open, separated by `;`
31+
```
32+
33+
In order to realize the full intended functionality, additional metadata may be required (such as localized application name, version, supported file formats, etc.). Possibly the GNUstep metadata format is sufficient for this.
34+
35+
### `.AppDir` bundles
36+
37+
helloSystem supports simplified ROX-style `.AppDir` bundles.
38+
39+
Minimal requirements:
40+
41+
```text
42+
./Application.AppDir
43+
./Application.AppDir/AppRun <-- (link to) the executable to be launched when Application.app is double clicked
44+
./Application.AppDir/.DirIcon <-- the application icon (png format)
45+
```
46+
47+
In order to realize the full intended functionality, additional metadata may be required (such as localized application name, version, supported file formats, etc.). Possibly the ROX AppDir specification is not sufficient for this and may need to be amended (to be determined).
48+
49+
### Wrappers for legacy packages
50+
51+
helloSystem supports applications that are not shipped in bundle formats yet. These can be bridged by __wrapper bundles__, application bundles that merely launch (but do not contain) the payload application (which may be installed in traditional ways).
52+
53+
A __desktop2app__ tool ships with helloSystem that automates the creation of such wrappers.
54+
55+
Please note that the use of wrapper bundles is discouraged and is only available as a bridge technology for backward compatibility with existing application packages.
56+
57+
## Building application bundles
58+
59+
Here is a real-world example on how to build an application bundle for a Qt application written in C++ using GitHub and [Cirrus CI](https://cirrus-ci.com/):
60+
61+
https://github.com/helloSystem/QHexEdit
62+
63+
The application gets compiled and uploaded in a fully automated process.
64+
65+
The resulting application bundle is provided for download in zipped form on GitHub Releases.
66+
67+
Please see the [`.cirrus.yml`](https://github.com/helloSystem/QHexEdit/blob/main/.cirrus.yml) file for details.
68+
69+
### Making an application load privately bundled libraries
70+
71+
If an application is supposed to load privately bundled libraries, one must patch it so that it loads privately bundled libraries from a path relative to itself (`$ORIGIN`) rather than from `/usr/local/lib`:
72+
73+
```console
74+
$ sed -i -e 's|/usr/local/lib|$ORIGIN/../lib|g' usr/local/bin/falkon
75+
$ ln -s usr/local/lib .
76+
$ rm usr/local/bin/falkon-e
77+
```
78+
79+
This works because by coincidence the string `/usr/local/lib` has the exact same length as `$ORIGIN/../lib`. If this was not the case, one would need to either specify the rpath at compilation time, or use a tool such as `patchelf`.
80+
81+
### Avoiding absolute paths
82+
83+
For an application to be fully relocatable in the filesystem, one must take care that no absolute paths to data files (e.g., those in `/usr/share/<APPNAME>` get compiled in.
84+
85+
In Qt applications, void [`QStringList QStandardPaths::standardLocations(QStandardPaths::AppDataLocation);`](http://doc.qt.io/qt-5/qstandardpaths.html). According to the [Qt documentation](http://doc.qt.io/qt-5/qstandardpaths.html), this resolves to `"~/.local/share/<APPNAME>", "/usr/local/share/<APPNAME>", "/usr/share/<APPNAME>"` but clearly `/usr` is not where these things are located in an `.app` bundle.
86+
87+
Instead, use [`QString QCoreApplication::applicationDirPath()`](http://doc.qt.io/qt-5/qcoreapplication.html#applicationDirPath) and construct a _relative_ path to `../share/<APPNAME>` from there.
88+
89+
For an example, see:
90+
https://github.com/KaidanIM/Kaidan/commit/da38011b55a1aa5d17764647ecd699deb4be437f
91+
92+
## Credits
93+
94+
Application directories and application bundles have been used by many desktop-oriented operating systems, including RISC OS, NeXTStep/OPENSTEP, Mac OS X, and various other systems. Classic Macintosh System used single-file applications that kept resources in the Resource Fork.
95+
96+
* https://en.wikipedia.org/wiki/Application_directory
97+
* http://rox.sourceforge.net/desktop/AppDirs.html
98+
* https://en.wikipedia.org/wiki/Resource_fork
Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
# Applications
2+
3+
Applications specifically written for helloSystem, especially Preferences and Utilities applications, should be
4+
* Simple to use
5+
* Easy to hack on
6+
* Open Source (2-clause BSD licensed by default, but similar permissive licenses may also be acceptable)
7+
* Ideally written in PyQt
8+
* Come as simplified `.app` bundles with no external dependencies apart from what comes with helloSystem by default on the Live ISO
9+
10+
Some of the example applications and utilities are written in Python with PyQt. This is designed to invite (power) users to have a look at the code, start to experiment, and possibly eventually contribute. Especially when used in conjunction with the simplified `.app` bundle format and with an IDE with autocompletion, this makes for a _very_ accessible development environment with _very_ low barriers to entry. No source code to search and download, no compilers, just open the `.app` bundle and start hacking away. Tiny example applications like `Log.app` and `Calendar.app` are included that anyone should be able to understand in no time.
11+
12+
Please see [https://github.com/learnpyqt/15-minute-apps](https://github.com/learnpyqt/15-minute-apps) for what we mean by "Simple to use" and "Easy to hack on".
13+
14+
For an introduction to [Creating GUI applications with Python & Qt5](https://www.learnpyqt.com/pyqt5-book/) you may be interested in the book with the same name by Martin Fitzpatrick. There is also a forum at [forum.learnpyqt.com](https://forum.learnpyqt.com/).
15+
16+
[![](https://hellosystem.github.io/docs/_static/book-pyqt5.png)](https://www.learnpyqt.com/pyqt5-book/)
17+
18+
## Using .ui files in PyQt
19+
20+
Using Qt Creator, you can also create and edit graphical user interfaces for __Python__ based applications using `.ui` files. These can be used in PyQt like this:
21+
22+
```py
23+
#!/usr/bin/env python3
24+
# This Python file uses the following encoding: utf-8
25+
26+
27+
import sys
28+
import os
29+
30+
31+
from PyQt5.QtWidgets import QApplication, QWidget
32+
from PyQt5.QtCore import QFile
33+
from PyQt5.uic import loadUi
34+
35+
36+
class Widget(QWidget):
37+
def __init__(self):
38+
super(Disks, self).__init__()
39+
self.load_ui()
40+
41+
def load_ui(self):
42+
path = os.path.join(os.path.dirname(__file__), "form.ui")
43+
ui_file = QFile(path)
44+
ui_file.open(QFile.ReadOnly)
45+
loadUi(ui_file, self)
46+
ui_file.close()
47+
48+
49+
if __name__ == "__main__":
50+
app = QApplication([])
51+
widget = Widget()
52+
widget.show()
53+
sys.exit(app.exec_())
54+
```
Lines changed: 60 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,60 @@
1+
# Architecture
2+
3+
helloSystem is designed with simplicity in mind. Less, but better. This page describes key elements of the hello desktop. To begin with, everything should be welcoming for Mac users but 10x as simple.
4+
5+
## Frameworks
6+
7+
In order of preference:
8+
* PyQt
9+
* Qml
10+
* Qt
11+
* Kf5 components where absolutely needed
12+
* Everything else
13+
* Gtk
14+
15+
Rationale: Most cross real-world productivity applications are written cross-platform and this often means Qt. Hence, to provide the best possible environment for those applications, we choose Qt for now. Philosophically, we would prefer to use something BSD licensed (or similar), such as FyneDesk, but in its current state it cannot yet provide the same truly native experience for existing Qt applications. (Maybe it helps to think of Qt as the "Carbon of hello", whereas something else will eventually become the "Cocoa of hello".)
16+
17+
## Desktop components
18+
19+
The minimum number of components viable to produce an efficient desktop should be used. Each component should be as simple as possible, and have as few dependencies as possible (besides the ones that are central to the hello Desktop, such as Qt and PyQt). Outside dependencies that are closely tied to other outside components should be avoided. XDG specifications are considered overly complex but insufficient and should be avoided, but may be acceptable as legacy technology for compatibility reasons.
20+
21+
### Filer
22+
23+
File manager that can handle (simplified) `.app` and `.AppDir` bundles
24+
25+
### Menu
26+
27+
Global menu bar that displays the System menu for system-wide commands (such as 'About this Computer'), and the active application's menus. It also contains a search box to search in the menus.
28+
29+
### Dock
30+
31+
A Dock that shows icons for running and pinned applications. (In the future it should also get an animated icon as a launching indicator for applications that are being launched but are not yet showing a window.)
32+
33+
### `launch` command
34+
35+
The {command}`launch` command is used to launch applications without specifying a path to them.
36+
37+
The {command}`launch` command is expected to determine the preferred instance of an application with the given name. (The {command}`launch` command is supposed to find the _preferred_ instance, e.g., the one with the highest version, the one last put onto the system, etc.) Eventually the {command}`launch` command should also gain knowledge of which application to open a file with.
38+
39+
Filer is supposed to launch all applications through the {command}`launch` command. Shell scripts, `.desktop` files, etc. should be written to use the {command}`launch` command rather than hardcoding paths to applications, where appropriate.
40+
41+
If an application cannot be launched, the {command}`launch` command shall give a localized, understandable clear-text error message and offer a solution if possible; fall back to the console output of the application that could not be launched.
42+
When beginning to launch an application, the {command}`launch` command shall notify the Dock via some IPC mechanism (ideally something _much_ simpler than the convoluted D-Bus) about the icon and name of the application about to be launched, so that the Dock can start a launch animation until the application is showing its first window).
43+
44+
### IPC mechanism for the desktop
45+
46+
A very simple IPC mechanism should be introduced for the desktop components to talk to each other. A lightweight, standard publish/subscribe mechanism should be identified; _possibly_ something like MQTT (which would have the added benefit of allowing for network-wide communication). In the meantime, the use of D-Bus as a legacy technology may be acceptable (even though it is considered obscure, convoluted, and closely linked with various other Red Hat technologies.)
47+
48+
### Applications
49+
50+
Applications must not need to be installed. Simply downloading them, attaching an external drive containing them, or connecting to a network share containing them must be sufficient. Multiple versions of the same application must be able to co-exist. The {command}`launch` command is responsible to determine which one to use in cases where the user did not explicitly launch a specific instance by double-clicking it.
51+
52+
Custom-written applications should come as Application bundles whenever possible. It is acceptable for pre-existing applications to come with legacy XDG desktop files instead.
53+
54+
### Utilities
55+
56+
The system should come with some commonly used utilities, such as a Terminal application, a Process Monitor application, etc. These are just regular applications inside a 'Utilities' subdirectory. It is acceptable for pre-existing applications, preferably written in Qt.
57+
58+
### Preferences
59+
60+
The system should come with some commonly used preference panels, such as for configuring the system language, OpenZFS Boot Environments, etc. These are just regular applications inside a 'Preferences' subdirectory. These should be super simple, "minimal viable" applications. It is expected that many will need to be written from scratch, but it is acceptable to re-use pre-existing applications, preferably written in Qt.

0 commit comments

Comments
 (0)