En 1998, quand j'ai commencé à utiliser Linux, c'était moche.

À cette époque, vous l'avez installé en insérant une quarantaine de disquettes dans votre ordinateur et en priant pour que l'une d'elles ne devienne pas un duffer et vous oblige à recommencer.

Après ce long processus d'installation, cette interface non totalement intuitive vous a généralement été présentée:

darkstar login:
_

À ce moment-là, le système d'exploitation dominant était Windows 95. Windows 98 commençait tout juste à se mettre en branle. L'ambiance Wargames-esque de Linux ne le réglait clairement pas pour une génération moderne élevée dans l'interface graphique.

Au fur et à mesure que nos amis influents du monde du noyau Linux ont compris comment faire fonctionner les cartes graphiques, de plus en plus d'efforts ont été consacrés à la création d'un environnement graphique familier avec le monde..

Cet effort a commencé avec X - la partie du logiciel qui affiche des éléments sur votre écran - mais cela ne suffisait pas. Pour obtenir une interface graphique réellement utilisable, il vous fallait un bon gestionnaire de fenêtres avec lequel travailler..

Contrairement au monde Windows, X vous permettait d'exécuter plusieurs gestionnaires de fenêtres, et une multitude de tentatives loufoques et merveilleuses ont été faites. Certaines étaient simples, d'autres plus complexes, d'autres essayaient d'imiter le système d'exploitation de Microsoft et d'autres n'étaient que des dingues. Au milieu de cette explosion créative, deux environnements graphiques ont émergé comme choix clairs: KDE et Gnome..

Alors que les deux étaient des environnements pleinement fonctionnels et intéressants pour les utilisateurs, ils étaient essentiellement deux jardins murés différents avec peu de croisement. Tous deux ont résolu bon nombre des mêmes problèmes, tels que la présentation de méthodes de lancement de fichiers et de gestion de polices, mais chacun a agi à sa manière. Les choses devaient changer.

Alors que notre communauté grandissait, il était insensé que deux développeurs puissent résoudre le même problème de deux manières différentes. Heureusement, la situation allait s'améliorer beaucoup.

Unifier le bureau

Avec de plus en plus de discussions sur la participation multi-postes, le projet freedesktop.org a été annoncé comme un lieu indépendant des postes de travail, dans lequel un logiciel pourrait être développé pour profiter à tout poste de travail souhaitant l’utiliser. Le site fournissait un wiki, de l'hébergement de code, des listes de discussion par courrier électronique, des canaux IRC et plus encore..

Cela a eu un impact énorme sur les ordinateurs de bureau. Beaucoup de logiciels ont été créés. certains ont atteint rapidement leur maturité et ont résolu de vrais problèmes, alors que certains projets ont démarré mais n'ont finalement jamais été achevés. Quels que soient les projets qui ont fonctionné ou non, freedesktop.org a également apporté un message important: nous devrions essayer de collaborer entre les ordinateurs de bureau, dans la mesure du possible. Le message a été populaire et le bureau a continué d'évoluer.

L'un des logiciels les plus importants issus de freedesktop.org était un système de messagerie unifiée. À l'époque, l'un des principaux défis auxquels les développeurs de postes de travail étaient confrontés était la manière dont les applications pouvaient communiquer entre elles. le navigateur Web devait communiquer avec le trousseau de clés du système, le démon de réseautage avec l'icône dans le panneau, etc..

KDE a tenté de résoudre ce problème avec un système appelé DCOP, qui était un moyen intuitif pour les applications d'envoyer et de recevoir des messages depuis et vers d'autres applications. Bien que DCOP fonctionne bien dans KDE, cela ne résout malheureusement pas le problème plus général qui se pose entre plusieurs applications sur plusieurs bureaux. C'est ainsi que le projet D-BUS est né.

En résumé, D-BUS est un équivalent de DCOP sur plusieurs postes de travail. Il fournit une installation dans laquelle les applications peuvent communiquer entre elles via un bus commun et en utilisant un langage commun. D-BUS a traversé une période fiévreuse de développement, a finalement été ratifié en tant que norme freedesktop.org et la technologie a été intégrée aux environnements KDE et Gnome. Ce fut un énorme pas en avant pour le bureau et une autre étape importante dans son évolution.

Raffiner le bureau

Avec tout ce travail sur plusieurs ordinateurs en cours, nous avons assisté à d’immenses développements sur le bureau Linux. Un grand nombre de nos problèmes de longue date étaient résolus - les périphériques USB étaient plug and play, la mise en réseau sans fil n'était qu'à un clic, l'impression était un jeu d'enfant, le logiciel était simple à installer; les choses s'amélioraient. Nous avions l’impression que nous devenions vraiment pertinents et que nos concurrents avaient quelque chose à faire: une incroyable communauté mondiale travaillant ensemble..

Dans le monde Ubuntu, nous faisions de notre mieux pour être à l'avant-garde de la fourniture de cette innovation aux utilisateurs. Nous prenions et intégrions des logiciels open source, et notre objectif était de fournir ce contenu de manière à résoudre les problèmes du monde réel; que ce soit pour que votre lecteur de musique fonctionne, pour vous connecter ou quoi que ce soit d'autre.

En 2008, Mark Shuttleworth, le fondateur d'Ubuntu, souhaitait intensifier cette innovation et cette focalisation sur Ubuntu. Il a donc fondé le projet Ayatana. L'idée était simple: recruter une équipe de conception et une équipe d'ingénieurs et créer un ensemble d'améliorations de l'interface utilisateur, définies par un sens aigu de la qualité dans la conception..

C'était nouveau pour Mark, la société (Canonical) et Ubuntu. Nous avions une longue tradition d'expédition et d'intégration de logiciels, mais une telle initiative centrée sur la conception était un terrain inconnu..

Ayatana

Lors de la création d’Ayatana, Canonical a recruté une équipe de concepteurs complète. L'équipe venait d'horizons variés: beaucoup venaient de la marque, du graphisme, du développement de produits, du design d'interaction et d'autres domaines..

Le terme 'melting pot of personalities' est un euphémisme, et beaucoup étaient nouveaux dans l'open source, mais ils étaient tous enthousiasmés et inspirés par l'idée d'un excellent design infusé avec une forte communauté..

Le premier projet issu de l'équipe s'appelait Notify OSD. Il fournissait une nouvelle approche des bulles de notification, que nous connaissions trop bien avec Ubuntu. Pendant des années, nous avions vu apparaître ces bulles jaunes carrées ennuyeuses dans le coin supérieur droit du bureau de Gnome lorsqu'une application devait vous dire quelque chose..

Notify OSD était le même concept de base, mais repensé. Avec elle, une jolie bulle noire transparente apparaîtrait et au lieu de cliquer dessus pour la faire disparaître, passez votre souris dessus, la bulle s’affaiblirait pour vous permettre d’interagir avec l’application située en dessous..

La justification de la conception était que les bulles de notification devaient présenter des informations à l'utilisateur de manière non intrusive. Avec la première version de Notify OSD publiée et livrée avec Ubuntu, l'équipe de Kubuntu souhaitait également disposer de la technologie KDE..

Heureusement, l'équipe Ayatana avait créé la spécification Notify OSD de manière transversale et l'équipe Kubuntu a simplement travaillé sur une interface graphique différente, parfaitement adaptée au bureau KDE. Comme l'OSD Notify de Gnome, il a été bien reçu. une amélioration subtile et douce au bureau.