Nouvelle version du Bureau Agnostep pour les 35 ans de GNUstep

Posté par Patrick Cardona . Édité par Arkem, Ysabeau 🧶, Pierre Jarillon et bobble bubble. Modéré par Ysabeau 🧶. Licence CC By‑SA.
Étiquettes :
37
4
mai
2026
GNUstep

Comme vous le savez sans doute, cette année est marquée par les 35 ans de GNUstep, qui est à la fois un cadre logiciel qui permet de développer en objective-C des applications portables sur Windows, MacOS et GNU/Linux, mais aussi un environnement d’exécution (runtime) de ces mêmes applications.

Plusieurs projets de bureau compatibles avec GNUstep existent depuis quelques années: après les défunts Simply-GNUstep et Étoilé, citons les actifs GSDE développé par Ondrej Florian ou encore le plus ambitieux NEXTSPACE de Sergii Stoïan, qui tend à reproduire fidèlement l’ergonomie d’OPENSTEP sur BSD ou GNU/Linux. Plus récemment, dans un style plus proche de MacOS, citons également les prometteurs bureaux Gershwin (pour Xorg) ou Ambrosia (pour Wayland) développé par James Carthew.

Le bureau Agnostep propose sa version BETA 2.0.0, dans un style plus classique, avec des menus verticaux à la NeXT, combinant Window Maker et GWorkspace, ainsi que le runtime classique de GNUstep.

Il n’en propose pas moins un thème moderne inspiré par le jeu d’icônes du projet Papirus. Bien que fondé sur une distribution Debian Lite, il ne fournit pas de paquets, mais un principe d’installation proche des ports BSD. Un assistant facilite l’installation initiale comme l’ajout d’applications supplémentaire afin de fournir les versions les plus récentes des applications de la communauté GNUstep, compilées depuis les sources. En effet, contrairement à d’autres projets qui divergent parfois tellement des sources originales, qu’il devient impossible de les reverser dans le lot commun, la philosophie d’Agnostep est d’échanger patiemment avec la communauté des développeurs afin que les problèmes constatés et les améliorations bénéficient à tout le monde.

De plus, ayant résolu certains problèmes de la version précédente, il présente une meilleure stabilité. Outre les applications notoires de l’écho-système GNUstep, comme GNUMail, SimpleAgenda, etc., il offre également une nouvelle collection d’applications GNUstep originales créées dans ce but afin de proposer une expérience utilisateur plus cohérente:

  • Meteo.app : une application dockée qui affiche aussi la date courante. Basée sur l’API wttr.in API d’Igor Chubin.
  • UpMem.app : affiche la durée d’exécution l’usage de la mémoire.
  • Updater.app : une application dockée avec un badge de notification pour alerter en cas de paquets Debian susceptibles de mise à jour. Ce qui permet aussi d’effectuer la mise à jour effective à partir de la liste affichée de ces paquets
  • Birthday.app : une application dockée avec un badge pour informer des événements familiaux. Un incontournable pour le grand-père de nombreux petits-enfants.
  • OpenDisk.app : ouvre les dossier media où sont montés les disques amovibles : un compagnon de wmudmount et de udisks2, en se dispensant d’afficher le bureau de GWorkspace.
  • Launcher.app : un moyen rapide d’afficher le dossier des applications dans une nouvelle fenêtre.
  • ScreenLock.app : un simple verrouilleur d’écran fondé sur xtrlock.
  • Pass.app : une interface GNUstep au programme Unix Password Manager donnant accès au coffre local des mots de passe.
  • Mixer.app : une version simplifiée et compatible ALSA du mixer dérivé de VolumeControl.
  • AgnostepManager.app : un assistant dans la compilation et l’installation d’applications supplémentaires : applications courantes, utilitaires, jeux, outils de développement.
  • Dico.app : un service et un outil de recherche dans un Dictionnaire français fondé sur le DVLF de l’Université de Chicago.
  • SaveLink.app : un gestionnaire de raccourcis Internet. Voyez le dossier des Favoris.

À partir de cette version, les manuels d’aide (format .help) seront fournis avec chaque application concernée grâce aux améliorations récentes de l’application HelpViewer. Autre exemple qui illustre les fructueux échanges avec la communauté.

Bureau Agnostep en version 2

Agnostep est initialement développé sur un Raspberry Pi 500, mais son code permet de l’installer sur n’importe quel ordinateur susceptible d’accueillir la distribution GNU/Linux Debian : d’où son nom. Agnostep est un téléscopage de agnostique et GNustep.

Aller plus loin

  • # Patrick est trop modeste

    Posté par  . Évalué à 10 (+10/-0). Dernière modification le 05 mai 2026 à 14:22.

    Patrick est trop modeste, ses interventions dans la liste de discussion GNUStep ont conduit à corriger pleins de trucs dans les docs ou les exemples de GNUStep, en plus de nombreux bugs (dont HemlpViewer). Et encore en plus, il apporte un grand vent de fraîcheur avec ses tatonnements et ses questions ; les devs ont l'air ravis de l'aider (il n'est pas développeur). Il a réveillé l'enthousiasme un peu endormi de tout le monde.

    Xavier

  • # apps gtk ou qt

    Posté par  (Mastodon) . Évalué à 5 (+2/-0).

    Est-ce que Agnostep prend en charge l'installation de themes GTK/QT inspirés de nextstep pour intégrer au mieux des applications gérant ces toolkits?

    • [^] # Re: apps gtk ou qt

      Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

      Ça ne plaît pas trop à certains développeurs d'applications qu'on puisse changer le thème : Please don’t theme our apps (d'ailleurs il faudrait peut-être que je signe).

      J'ai toujours trouvé ça horrible les applications KDE installées dans GNOME avec un thème modifié pour ressembler à Adwaita (le thème par défaut de GTK/GNOME). L'inverse est également vrai (installer gedit sur KDE ne ressemble parfois à rien, faut forcer Adwaita pour avoir le truc d'origine).

      Créer un autre thème pour une application est techniquement possible, c'est juste que ça demande des efforts énormes pour avoir quelque chose de vraiment correct et agréable à utiliser. En pratique, ce n'est pas le cas de la plupart des thèmes alternatifs.

      • [^] # Re: apps gtk ou qt

        Posté par  (Mastodon) . Évalué à 8 (+6/-1).

        Ça ne plaît pas trop à certains développeurs d'applications qu'on puisse changer le thème

        C'est leur opinion et on a aussi le droit d'en avoir rien à carrer.

        • [^] # Re: apps gtk ou qt

          Posté par  (site web personnel, Mastodon) . Évalué à 8 (+5/-0).

          Alors, oui, mais le problème c'est que si l'application s'affiche mal avec un thème, les gens vont se plaindre au développeur de l'application. Et tester une application avec des centaines de thèmes différents, c'est pas simple.

          Cela ajoute donc de la complexité dans le code et du travail de maintenance, et c'est là que les gens qui n'en ont rien à carrer, comme tu dis, sont un problème, parce que c'est pas eux qui vont faire ce travail en général.

          • [^] # Re: apps gtk ou qt

            Posté par  (site web personnel, Mastodon) . Évalué à 5 (+3/-0).

            En effet.

            Peut-être qu'un thème initialement conçu tient la route, mais le thème lui-même demande de la maintenance quand les applications sont mises à jour. Donc un vieux thème a de fortes chances d'être buggé.

            Ceci dit - petite histoire - écrire un nouveau thème GTK a permis en 1998 de convaincre la hiérarchie chez Red Hat de continuer d'investir des ressources dans GNOME et de ne pas virer l'équipe. La hiérarchie leur a dit : vous avez 36 heures pour nous convaincre de ce truc qu'est GNOME. Ils ont travaillé comme des acharnés sur le code, et puis quelqu'un a eu l'idée : tient ce nouveau système de thèmes qui avait été développé récemment, « si on écrivait un nouveau thème » ? La démo ou les captures d'écrans ont suffit :-) (source : présentation de Jonathan Blandford, voir les slides p.21)

          • [^] # Re: apps gtk ou qt

            Posté par  (Mastodon) . Évalué à 3 (+1/-1).

            Ce travail n'est absolument pas obligatoire. Si quelqu'un se plaint auprès de toi, développeur, et qu'ils utilisent un thème différent, tu peux les envoyer bouler et/ou leur dire de tester avec adwaita ou breeze ou que sais-je est le thème par défaut sous QT ou GTK4 aujourd'hui.

            Il faut avoir le QI d'une huître pour faire du logiciel libre et d'être fermé á l'idée que les utilisateurs et mainteneurs de distros fassent ce qu'ils veulent de ton code.

            • [^] # Re: apps gtk ou qt

              Posté par  (site web personnel, Mastodon) . Évalué à 5 (+3/-0).

              Il faut avoir le QI d'une huître pour faire du logiciel libre et d'être fermé à l'idée que les utilisateurs et mainteneurs de distros fassent ce qu'ils veulent de ton code.

              Et il faut avoir un minimum d'empathie pour les devs qui voient les distros faire n'importe quoi avec leur UX, puis renvoyer les utilisateurs vers eux pour s'en plaindre, quand ce n'est pas carrément leur casser du sucre sur le dos à longueur de temps (les exemples donnés par le site viennent de Pop!_OS, ce qui n'est pas un hasard).

              Comme tu le dis toi-même, ce travail — rendre ses applis "thémables" pour que leur UX soit contorsionnable à loisir, comme si une telle chose ne demandait pas des efforts disproportionnés et que les devs macOS et Windows faisaient pareil — n'est pas obligatoire. Stop Theming My App ne doit pas se comprendre comme une injonction à "ne pas utiliser de thèmes" (le site dit lui-même aux utilisateurs qu'ils peuvent faire ce qu'ils veulent), mais plutôt comme une réponse faite à l'injonction qu'on fait encore trop souvent aujourd'hui aux devs de faire des applis qui peuvent à la fois coller à GNOME, à KDE, à NextSTEP et à Windows 95.

              • [^] # Re: apps gtk ou qt

                Posté par  (Mastodon) . Évalué à 3 (+0/-0).

                Le problème ici ce n'est pas de changer le thème ou le code, mais de ne pas prendre en charge le support et leurs responsabilités quand ils le font.

            • [^] # Re: apps gtk ou qt

              Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

              Ce travail n'est absolument pas obligatoire. Si quelqu'un se plaint auprès de toi, développeur, et qu'ils utilisent un thème différent, tu peux les envoyer bouler et/ou leur dire de tester avec adwaita ou breeze

              Tu serais étonné du nombre de rapports de bugs et demande de fonctionnalités que certains développeurs reçoivent, surtout pour les applications installées par défaut.

              Faire du triage de bugs, certains contributeurs en ont fait leur spécialité. D'ailleurs toute aide est la bienvenue !

              À chaque fois qu'un utilisateur vient avec un problème venant en fait d'un autre thème, c'est une perte de temps pour les contributeurs de l'application en amont.

              Oui, il faut filtrer à l'entrée et dire de n'utiliser que le thème par défaut avant de rapporter un problème (exemple pour gedit).

              • [^] # Re: apps gtk ou qt

                Posté par  (Mastodon) . Évalué à 2 (+0/-1). Dernière modification le 08 mai 2026 à 12:48.

                C'est un débat sans fin.

                • donner des libertés aux autres et espérer qu'ils décident d'abandonner cette liberté via une pétition alors que ladite liberté est légitime, c'est illusoire.
                • espérer que les gens ne soient pas tous des trous du culs, c'est illusoire.
                • espérer que les gens lisent et suivent toutes les instructions dans les processus de rapport de bug, ça l'est aussi.
                • espérer que personne ne critique ton projet pour un truc qui est totalement indépendant de ta volonté et de tes moyens, c'est illusoire.

                La seule manière de limiter la charge mentale et temporelle côté developpeur c'est de au choix:

                • déposer une marque et d'interdire à une distrib de distribuer ton appli sous ta marque si elle utilise un autre thème que adwaita (ou breeze ou que sais-je).
                • s'en foutre et d'envoyer bouler allègrement ceux qui ne lisent pas.
                • ne pas recevoir de rapports de bugs. Tu peux distribuer ton appli comme de simple archives sur un site web et sur le flathub et ne pas avoir de suivi de bug publique ni même d'infos de contact.
                • ne pas utiliser un toolkit qui supporte des thèmes. S'il faut patcher / écrire du code pour seulement 3 applis, la majorité des distros et des utilisateurs ne vont pas le faire.
  • # wayland ou Xorg ?

    Posté par  . Évalué à 2 (+1/-0).

    Voila, ce n'est pas tres clair dans ma tête comment ça marche tout ça, mais pour un bureau il faut en prendre un qui va avec sa distribution, non ?

    Agnostep est "basé" sur wayland ou Xorg ?

    • [^] # Re: wayland ou Xorg ?

      Posté par  . Évalué à 4 (+2/-0).

      Xorg
      Pour Wayland regarde Ambrosia, mais c'est encore le début.

    • [^] # Re: wayland ou Xorg ?

      Posté par  (Mastodon) . Évalué à 4 (+1/-0).

      Window Maker n'a à ma conaissance pas été porté sous wayland. D'ailleurs ça n'a pas vraiment de sens de "porter" un wm sous wayland vu que tu as réellement tout à réecrire, autant partir de zéro mėme si on veut que ça ressemble au wm original et compatible au niveau de la config. Comme i3 et sway.

  • # Release Candidate 2.0.4

    Posté par  . Évalué à 4 (+4/-0).

    Bonjour,

    Après une série de tests sur pi500 (aarch64) et un laptop MacBookPro Intel (x86_64) Agnostep est mature pour élargir son panel de testeurs: je vous annonce donc la Release Candidate 2.0.4.

    Annonce de la RC 2.0.4

    N'hésitez pas à installer et à tester.

    P.S.: concernant le débat sur le thème des applications tierces (sans vouloir ranimer le troll ;-)) je tiens à préciser ces points:

    • Un système GNUstep peut avoir un thème Gtk. Ce n'est pas un tabou. Des démos sont notamment visibles dans les vidéos publiées par Gregory Casamento.

    • Donc rien n'empêche un contributeur de proposer un nouveau thème: toutes les propositions (Pull Request) sont les bienvenues: Agnostep est un projet agnostique qui accueille volontiers tout nouveau contributeur.

    Prenez du plaisir avec Agnostep!
    Bien à vous,
    patrick

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.