Orbitiny est un bureau Linux portable qui se lance comme une appli et qui ne joue pas dans la même catégorie.

Un bureau qui tourne au-dessus d’un autre, et ce n’est pas une blague

Dans l’écosystème des environnements de bureau Linux, on connaît les approches classiques, un gestionnaire de fenêtres, un compositeur, un panel, un menu, des services de session. Orbitiny arrive avec une idée qui semble contre nature, un bureau complet qui se lance comme une simple application, au-dessus de votre environnement actuel, sans remplacer quoi que ce soit, sans ouvrir une nouvelle session, sans toucher à votre configuration.

On clique, et un deuxième bureau apparaît, avec son propre panel, son propre menu, son propre gestionnaire de fichiers, comme une couche graphique autonome qui s’empile sur la première. C’est inhabituel, mais ça fonctionne.

Comment ça marche réellement, sous le capot

Orbitiny n’utilise pas KWin, Mutter ou Openbox. Il embarque son propre mini gestionnaire de fenêtres, écrit en Qt et C++, qui ne prend pas le contrôle de la session. Le système hôte continue de gérer les vraies fenêtres, les notifications, les entrées clavier et souris. Orbitiny ne gère que ce qu’il crée lui-même.

Techniquement, Orbitiny est une application Qt géante, un conteneur qui simule un bureau, un panel, un menu, un gestionnaire de fichiers et des services internes. Cela lui permet de tourner au-dessus de KDE, GNOME, Xfce ou n’importe quoi d’autre, sans conflit de compositeur, sans guerre de raccourcis clavier, sans écraser les paramètres de session.

C’est cette encapsulation qui rend possible le mode portable et l’exécution parallèle.

Qu’est-ce que ça apporte que les autres bureaux n’apportent pas

Orbitiny ne cherche pas à remplacer KDE ou GNOME. Il propose autre chose, un bureau autonome, portable, encapsulé, qui peut être lancé n’importe où, sans installation, sans dépendances lourdes, sans interaction profonde avec le système.

Ce que cela change concrètement :

1. un bureau que l’on transporte réellement sur une clé USB, avec ses réglages et ses plugins
2. un environnement isolé pour tester des applications sans polluer son bureau principal
3. un espace de travail temporaire pour les techniciens, les formateurs, les utilisateurs nomades
4. une solution pour les distributions live qui veulent proposer un bureau complet sans l’intégrer au système
5. une manière de contourner les limitations d’un bureau hôte sans le modifier

Orbitiny n’est pas un remplaçant, c’est un bureau parallèle, un bac-à-sable/sandbox graphique.

Des fonctionnalités déjà bien avancées

Le gestionnaire de fichiers maison, Qutiny, propose des fonctions rarement vues ailleurs, fusion de fichiers texte par glisser déposer, fusion d’images verticalement, recherche par nom et par contenu, double panneau, gestion des opérations avec emblèmes visuels. Ce sont des fonctions immédiatement utiles, sans installer d’outils externes.

Le bureau gère les gestes souris, jusqu’à douze par bouton, gauche ou droit. On peut dessiner un cercle pour ouvrir un terminal, une ligne pour lancer un navigateur, un zigzag pour fermer une fenêtre interne. C’est rapide, efficace, et entièrement configurable.

Chaque écran physique peut avoir son propre fond d’écran, ses propres raccourcis, ses propres applets. Chaque bureau virtuel peut également avoir sa propre configuration. Cela permet de créer des espaces de travail réellement indépendants.

Orbitiny détecte automatiquement WINE et DOSBox. On peut lancer un .exe Windows ou un programme DOS directement depuis le bureau ou le gestionnaire de fichiers, sans créer de fichier .desktop ou de configuration manuelle.

Le mode portable, la vraie différence

L’archive fait environ 185 Mo. On la décompresse sur une clé USB, on lance start-orbitiny, et tout fonctionne immédiatement. Tous les réglages sont stockés dans le dossier d’extraction. On peut donc transporter son bureau complet, ses préférences, ses plugins, et les retrouver sur n’importe quelle machine Linux.

Pour les techniciens, c’est un bureau de secours.
Pour les utilisateurs avancés, c’est un environnement jetable.
Pour les curieux, c’est un terrain d’expérimentation sans risque.
Pour les distributions live, c’est un bureau plug and play.

Informations concrètes

Orbitiny est sous licence GPLv3. Le code source et les binaires sont disponibles sur SourceForge. Le projet est développé par Sasko Usinov. Les premières versions datent de 2023, la version actuelle est la 0.3.0.

Orbitiny utilise Qt 5 et Qt 6 selon les modules, du C++ moderne, et une architecture modulaire composée de 48 composants isolés. Si un composant plante, le reste du bureau continue de fonctionner. C’est un choix technique rare dans les environnements de bureau.

Le développement est actif, et les prochaines étapes annoncées concernent l’amélioration du système de plugins, un thème sombre complet et la stabilisation du mode portable.

Premières impressions, un projet jeune mais déjà solide

Orbitiny tourne vite, tourne bien, tourne même très bien pour un bureau qui s’empile sur un autre. Le gestionnaire de fichiers accède directement au système hôte, le panneau de configuration est déjà complet, l’ensemble est fluide et cohérent.

On est loin du prototype bricolé un dimanche soir. Orbitiny ressemble à un projet avec une vision claire, et surtout avec une approche technique différente de ce que l’on voit habituellement.

Un concept étrange mais une idée qui mérite d’exister

Orbitiny ne remplacera pas KDE ou GNOME, mais ce n’est pas son but. Il propose une approche différente, un bureau autonome, portable, encapsulé, qui peut cohabiter avec n’importe quel environnement existant. Rien que pour ça, il mérite d’être essayé.

L’informatisation et la mise en réseau des ordinateurs nous ont apporté beaucoup de choses formidables ces trente dernières années. Toute la culture musicale, cinématographique et encyclopédique est désormais à une portée de clic de quiconque. Téléphoner de n’importe où à n’importe qui tout autour de la terre est devenu quelque chose de tellement courant que plus personne ne s’en extasie. Et même si l’interlocuteurice s’exprime dans une autre langue ça n’est presque plus un problème avec les différents services de traduction en ligne que l’on peut avoir.

Ne parlons même pas de ce mini-ordinateur que presque tout le monde a désormais dans sa poche, équipé d’une chaîne hifi complète, d’un caméscope, d’un appareil photo d’excellente qualité et d’une connexion permanente au réseau mondial.

Nos logements sont désormais entièrement automatisables et pilotables à distance.

Je peux avoir de la musique ou la radio quand je veux dans mon casque sans fil grâce à la baladodiffusion.

Tous ces rêves numériques des années 90 se sont concrètement réalisés aujourd’hui, mais nous avons tout de même perdu quelque chose : le temps réel des interfaces

N. D. M. : par « temps réel » est ici utilisé dans le sens réponse immédiate humainement parlant, sans latence perceptible, réactives (voir les définitions Wiktionary ou Wikipedia pour temps réel qui, pour l’informatique, vont amener des exigences supplémentaires sur la durée maximale de réponse, la garantie du temps de réponse, etc.

Sommaire

• Le temps réel des interfaces
• Les systèmes sont devenus mous
• Revenons aux interfaces réactives
• Manifeste des interfaces temps réel
• Vers un Score-Interfaces-Temps-Réel ?
• Conclusion

Le temps réel des interfaces

En effet, avec la diffusion du numérique à tous les étages, les interfaces se sont ramollies. Aujourd’hui, lorsque nous appuyons sur un bouton pour jouer une musique, lancer une vidéo ou valider un formulaire sur Internet nous n’avons pas un retour immédiat de cet appui.

Il s’écoule souvent un temps non négligeable entre l’appui sur ledit bouton et la réaction du système. Ce problème ne se limite pas aux boutons bien sûr, c’est le même problème avec les branchements des chargeurs et autres interfaces USB, HDMI…

Nous ne sommes jamais immédiatement sûrs que l’action se soit bien passée. Si la réaction met trop de temps à venir (lancement de la musique, icône de mise en charge, validation du formulaire…) nous allons avoir tendance à réessayer au risque de se retrouver avec un « dys »fonctionnement anormal. Le bouton « play » de la musique est également le bouton pause, un ré-appui sur le bouton coupe la musique. Une absence de réaction de l’appareil au branchement va nous amener à débrancher puis rebrancher jusqu’à jeter le câble et en prendre un autre. Un ré-appui sur le bouton du formulaire va en renvoyer un autre, etc.

Nous parlons bien ici des interfaces qui ne sont pas en temps réel. Cela n’a rien à voir avec la puissance de calcul des machines. Les appareils des années 90 avaient beau avoir des interfaces temps réel, ils n’étaient pas puissants, beaucoup ne disposaient même pas de microprocesseurs.

Sur mon lecteur de cassettes audio, lorsque j’appuyais sur le bouton « play » le bouton émettait un « clic » bien distinctif et une petite vibration dans le doigt qui m’assurait que mon appui était bien pris en compte. Et si j’étais à la fin de la cassette le bouton remontait immédiatement, je savais instantanément que cela n’avait pas marché et qu’il fallait que j’appuie sur « eject » pour retourner la cassette… ou « rewind » pour rembobiner.

Pour lire ma cassette de petit ours brun, j’appuie sur le triangle et ça fait «clic» instantanément !

Alors que pour allumer la boite à histoires, il faut appuyer sur un bouton planqué sur le côté, et attendre plusieurs secondes que l’écran affiche un sourire. Ai-je bien appuyé ? Dois-je retenter ? Y a-t-il suffisamment de batterie pour que j’obtienne une réaction ? Et je ne parle même pas des deux boutons rotatifs rouge qui ne réagissent pas instantanément (en plus celui de gauche est à tourner pour le volume et celui de droite est à CLIQUER pour changer d’histoire…)

Les télévisions cathodiques des années 70-80 prenaient un certain temps à chauffer avant d’afficher l’image, mais l’appui sur le bouton « on » était marqué par un « clang » bien net, et nous savions que la télé était allumée, nous pouvions attendre d’avoir l’image. Les télés d’aujourd’hui mettent également du temps à s’allumer, mais elles ne signalent pas toujours la bonne réception de notre action sur la télécommande. Et ne parlons même pas des écrans d’ordinateur avec leur interface tactile à la noix (on doit pouvoir parler d'interfaces digitales pour le coup non ?) dont on ne voit même pas où se trouve le bouton.

Les systèmes sont devenus mous

Et cette mollesse les rend dysfonctionnels. Je ne compte plus le nombre de fois ou voulant ré-appuyer sur un bouton de validation, j’ai finalement appuyé sur un nouveau bouton venant d’apparaître sous mon doigt/curseur. Sans parler de tous ces systèmes électroniques portables qui prennent un temps dingue avant d’afficher quelque chose quand on appuie sur le bouton “ON”. Systèmes qui ne sont pas toujours réellement éteints d’ailleurs et dont l’appui long… les éteint !
Ne parlons même pas des systèmes avec boutons rotatifs de type « potards numériques » qui — non contents de générer des rebonds ou de sauter des pas — fonctionnent avec la même mollesse que les boutons « standard ».

Mais le problème ne se limite pas aux systèmes embarqués. Oh que non ! Toute l’informatique « desktop » et mobile est touchée. Les sites Web ont rouillé avec leurs méga-octets de bibliothèques javascript à télécharger avant de pouvoir appuyer sur le moindre bouton.

Le réseau étant désormais massivement sans fil (WiFi, GSM, 4g, 5g, gégé, …), l’on ne sait pas toujours pourquoi cette page met tant de temps à se charger. Attention, il n’est pas question ici de vitesse de connexion, mais plutôt d’absence d’indication claire de ce qui est en train de se passer : ai-je déconnecté, ou le lien réseau est-il tout simplement lent ?

Revenons aux interfaces réactives

C’est un problème d’ergonomie. Et l’ergonomie est visiblement toujours reléguée en fin de projet «tant qu’on a un truc qui marche». Cependant, on pourrait considérer que non, ça ne marche pas si l’interface est si lente à réagir.

Je suis persuadé que ce problème n’est pas une fatalité. Il est possible de revenir à des interfaces humain-machine qui soient vraiment temps réel.

Mais il faut que tout le monde s’y mette.

• Aux électroniciennes et électroniciens de mettre systématiquement le voyant (ou vibreur, ou son) qui va bien pour signaler le bon branchement du câble, et le bon appui sur le bouton.
• Aux développeuses et développeurs noyau de soigner l’ordonnanceur pour s’assurer que la partie interface soit bien traitée dans un temps acceptable (moins de 100 ms ?).
• Aux développeuses et développeurs d’applis de considérer un temps de réaction trop long des interfaces comme un bug qu’il faut corriger.
• Aux utilisatrices et utilisateurs de ne plus accepter un seul ralentissement de l’interface et remonter systématiquement le problème comme un bug et/ou ne pas acheter/utiliser le produit.

Manifeste des interfaces temps réel

Voici donc une proposition/un manifeste de règles pour des interfaces temps réel :

1. Toute action humaine (appui ou clic-toucher sur un bouton, branchement d’un câble…) doit être validée par un retour en moins de 100 ms par un visuel, un son ou une vibration.
2. Si le système est bloqué l’utilisateurice doit le savoir. On doit pouvoir faire la différence entre un blocage et un temps de chargement. Un genre de watchdog de l’ergonomie.
3. On peut certainement ajouter d’autres règles quand on fera des audits ITR (Interfaces Temps Réels) dans les bureaux d’études et de développement des grosses boites.

Vers un Score-Interfaces-Temps-Réel ?

Évidement, il est impossible que ces règles s’appliquent du jour au lendemain sur tous les appareils et logiciel du marché. On pourrait inventer un système de notation, à l’image du nutri-score mais pour les interfaces. Par exemple le SITR pour Score-Interfaces-Temps-Réel et développer une appli pour pouvoir récupérer le score des produits qu’on utilise.
Appli qui aurait le culot d’avoir un mauvais score histoire de faire causer.

Conclusion

Pour conclure sur ce manifeste décousu :

✊🏼 Oui l’ergonomie est importante !
✊🏽 Oui un temps de réaction trop long est un BUG !
✊🏿 Oui il faut que ça change !