- Kate s’est développé principalement dans l’écosystème Unix, mais il fonctionne désormais, ou a été porté, sur plusieurs systèmes d’exploitation desktop, jusqu’à Windows, macOS et Haiku
- Sous Linux et BSD, la prise en charge de X11 et Wayland est stable depuis longtemps, et Kate peut être installé comme paquet standard sur Fedora, NixOS, FreeBSD, OpenBSD, etc.
- La prise en charge de Windows et macOS s’inscrit dans le travail de portage à long terme de la communauté KDE, avec une disponibilité via le Windows Store, des builds nightly et des environnements de développement basés sur Craft
- Android et iOS ne sont pas les principales cibles de Kate, mais il existe des cas de portage sans intervention directe de l’équipe Kate, comme pour Haiku
- Sur les systèmes qui n’utilisent généralement pas DBus, comme Windows, macOS et Android, la suppression de la dépendance à DBus reste un chantier, et des frameworks comme KIO nécessitent un travail supplémentaire
État de la prise en charge de Kate par plateforme
- Les systèmes de type Unix sont pris en charge de façon stable depuis longtemps dès lors qu’ils disposent de X11 ou de Wayland
- Linux a été utilisé comme plateforme principale de développement de Kate dans les environnements X11 et Wayland
- Comme les autres applications KDE, Kate a été porté vers plusieurs variantes de BSD
- Il peut être installé via les systèmes de paquets standard de Fedora, NixOS, FreeBSD, OpenBSD, etc.
- Il est possible de le compiler directement depuis les sources, et les correctifs nécessaires doivent se trouver dans le dépôt upstream
- La manière de compiler Kate et de participer à son développement sur les systèmes de type Unix est décrite dans le guide de compilation de Kate
- La prise en charge de Windows s’inscrit dans la démarche de la communauté KDE, qui fournit depuis des années ses bibliothèques et applications sur Windows
- Windows est une plateforme non libre, mais il offre un moyen pour les applications KDE de toucher de nouveaux utilisateurs et développeurs
- Kate et certaines applications KDE sont référencés dans le Windows Store officiel
- Davantage d’applications sont disponibles sous forme de builds nightly
- Le développement de Kate sous Windows est possible via Craft
- Pour l’essayer, il suffit d’utiliser l’installateur nightly disponible sur le site de Kate
- macOS fait également partie des principales plateformes non libres que Kate cherche à prendre en charge
- Des builds nightly pour macOS sont disponibles
- Comme sous Windows, il est possible de développer Kate avec Craft
- Les installateurs nightly pour Mac ARM et Intel sont disponibles sur le site de Kate
- Kate peut aussi être porté vers d’autres systèmes d’exploitation desktop
- Les plateformes mobiles comme Android et iOS ne font pas partie des principales priorités de Kate
- Même si l’équipe Kate n’y a pas travaillé directement de façon active, un port de Kate pour Haiku a été réalisé
- Quelques correctifs d’une ligne pour le port Haiku ont été intégrés en upstream
- Même pour des ports vers des systèmes moins répandus, les correctifs peuvent être acceptés en upstream s’ils ne sont pas trop intrusifs
Pourquoi des contributions pour d’autres plateformes sont nécessaires
- La plupart des développeurs de Kate travaillent sous Linux ou BSD, si bien que les autres systèmes ont davantage besoin d’aide, aussi bien pour le développement que pour les tests
- Les utilisateurs de Windows ou macOS peuvent télécharger les builds nightly depuis le site de Kate pour les tester
- L’utilisation de Craft facilite également le processus de contribution
- L’un des chantiers récents consiste à avancer sur la suppression de DBus sur les systèmes qui ne l’utilisent habituellement pas, comme Windows, macOS et Android
- La coordination se fait dans l’issue craft-blueprints-kde
- Les builds nightly actuels de Kate se sont améliorés au point de ne plus se bloquer sur macOS, entre autres
- Certains frameworks comme KIO nécessitent encore du travail supplémentaire
- DBus est utile sur les systèmes qui l’utilisent nativement, comme Linux ou BSD, mais sur les systèmes dépourvus de ce concept, il peut provoquer des blocages ou la création de processus non souhaités
- Sur ces systèmes, il n’existe pas non plus de service de bus avec lequel communiquer, ce qui réduit l’utilité de DBus
1 commentaires
Avis sur Hacker News
Kate a été l’une des principales raisons pour lesquelles je suis passé à Linux en 2004/2005.
À l’époque, je faisais des exercices pratiques avec MySQL, et sous Windows, pour développer, il n’y avait guère que MySQL Workbench, qui était beaucoup trop lourd. L’exécution de SQL était si lente que ça en devenait pénible, avec des cycles d’itération interminables.
Sous Linux, j’écrivais le SQL dans Kate, je lançais le client en ligne de commande MySQL dans le terminal intégré, puis, quand c’était prêt, j’appuyais sur le bouton “pipe to terminal” et ça s’exécutait aussitôt. Ce qui prenait plusieurs minutes sous Windows prenait moins de 2 secondes sous Linux, impossible de ne pas tomber sous le charme.
Une autre raison était le lecteur MP3 Amarok. Si vous aimez la façon dont des services comme Spotify génèrent automatiquement des playlists infinies ou des radios selon vos goûts, KDE proposait sans doute déjà ce genre de fonction depuis 2002. iTunes l’a d’abord copiée, puis Spotify l’a copiée, et aujourd’hui c’est considéré comme une fonctionnalité standard.
KDE 3.5 a été l’un des sommets de l’interface graphique GNU/Linux, peut-être même le plus haut.
Quand on était habitué à l’interface de Windows XP, essayer KDE était impressionnant, et les innovations d’interface promises ensuite par Vista paraissaient bien modestes face à ce qu’on pouvait déjà faire avec Compiz. Cela dit, là, on parle plutôt de Gnome 2.
Et il y avait aussi Amarok. Je l’avais oublié pendant un temps, mais en devenant utilisateur de Mac, perdre Amarok est ce que j’ai le plus regretté. Depuis, je n’ai jamais rien utilisé qui s’en rapproche.
Kate est très bien, mais ce n’était pas le premier à proposer ce genre de fonction.
Comme c’était assez proche des premières versions, ces problèmes ont sûrement été corrigés depuis, mais à l’époque j’ai pris des habitudes de travail sans Kate, et je ne l’utilise toujours pas aujourd’hui.
Kate, avec Dolphin, a été l’une des premières choses que j’ai découvertes dans KDE et qui m’ont le plus agréablement surpris.
Kate remplit pour moi le rôle que jouait Np++ à l’époque où j’étais sous Windows. Je l’utilise quand je veux travailler à partir de fichiers, plutôt qu’à partir d’un projet ou d’un répertoire.
\net\t, et l’interface est quasiment la même.Il n’a pas été mis à jour depuis des années, mais je l’utilise depuis plus d’un an sans rencontrer de bug.
Kate est un éditeur vraiment impressionnant, et je suis content de voir qu’il continue d’être développé et porté vers d’autres systèmes d’exploitation. Je ne savais pas qu’il prenait désormais en charge LSP, c’est une bonne chose.
S’il arrivait quelque chose à BBEdit, mon prochain choix pourrait être Kate.
BBEdit est mon éditeur par défaut.
J’utilise BBEdit depuis environ 1997, et même si, ces 15 dernières années, je suis surtout passé à Sublime et VSCode, je les configure toujours pour qu’ils se rapprochent autant que possible de BBEdit. Mais ils n’arrivent toujours pas au niveau de BBEdit pour la recherche/remplacement dans un ou plusieurs fichiers, ni pour les fonctions de comparaison.
De la même manière, macOS reste mon environnement de bureau préféré, mais depuis deux ans mon principal environnement de développement est KDE. Il faut donc vraiment que j’essaie Kate.
J’aime bien le passage disant que “même sur des plateformes non libres, aller à la rencontre de nouveaux utilisateurs et développeurs peut ensuite les amener à s’intéresser à une migration vers une plateforme entièrement ouverte”.
Les développeurs de KDE ont toujours eu une bonne vision. Ils semblent peut-être vouloir créer un shell d’OS qui synchronise les données utilisateur entre plusieurs systèmes d’exploitation. Avec KDE Connect en plus, les applications KDE couvrent 99 % des usages du grand public.
KDE Plasma ne me convenait pas vraiment, mais les applications KDE étant réactives, je les ai toujours choisies sur mes systèmes Linux.
Il existe aussi Dolphin pour Windows[1], mais il présente quelques problèmes.
[0] https://apps.kde.org/kdeconnect/
[1] https://cdn.kde.org/ci-builds/system/dolphin/master/windows/
Comme la plupart des gens ici, je finis par utiliser plusieurs ensembles d’outils, mais je suis content que Kate existe et je suis vraiment reconnaissant pour sa grande qualité et ses excellentes fonctionnalités. Autrefois, il aurait fallu payer pour quelque chose comme UltraEdit et se battre avec les licences, ce qui pouvait devenir un cauchemar dès qu’on traversait les frontières de grandes entreprises.
Sur mes machines Windows/macOS/Linux, j’alterne entre Kate, Geany et Notepad++ selon la tâche.
Il y a quelques mois, Kate m’a surpris. Je devais écrire de l’assembleur pour un processeur entièrement personnalisé, avec une ISA sans aucun rapport avec les standards du secteur, et Kate m’a fourni la coloration syntaxique ; avec un thème de couleurs adapté et la fonction de “surlignage par double-clic”, j’ai pu gérer des changements complexes bien plus facilement qu’avec n’importe quel autre outil, y compris VSCode/VSCodium.
Kate est un éditeur adorable. J’ai écrit à peu près la moitié de Designing Sound avec Kate, avant de passer à Emacs vers la fin. C’était pour mieux gérer l’intégration du code
Ce que j’aimais, c’était de pouvoir garder une fenêtre de fichiers ouverte et couper-coller très rapidement entre les fichiers
Même si je suis un disciple d’Emacs baptisé et confirmé, je n’ai toujours pas l’impression que l’approche centrée sur les buffers corresponde aux fichiers autant que je le voudrais. Kate a trouvé le bon équilibre pour un workflow basé sur les fichiers
Je me suis connecté juste pour dire ça. À l’époque de KDE 3, Kate était la principale raison pour laquelle je continuais à utiliser KDE comme environnement de bureau
Je suis passé sur Mac il y a longtemps, mais j’utilise encore Kate comme éditeur. Je suis content qu’il existe toujours
J’ai aussi essayé les outils de build proposés dans l’article, mais même avec ça, compiler Kate était un cauchemar. Après avoir passé plusieurs jours à essayer au hasard les suggestions données par les gens sur le chat de Kate, j’ai fini par abandonner. Chaque build prenait des heures et échouait à la fin avec une erreur totalement obscure
Sur Linux, j’utilisais Kate avec beaucoup de plaisir, mais comme j’utilise surtout un Mac, j’ai fini par laisser tomber et par continuer à utiliser emacs pour les petites tâches diverses, et IntelliJ pour Java/Kotlin/Groovy/Dart et ce que JetBrains prend bien en charge
Kate est une bonne alternative à des outils comme VSCode ou BBEdit, mais d’après mon expérience, il reste encore des aspérités sur macOS
Je l’utilise surtout sous Linux, et le support LSP est en fait plutôt correct. Il n’a pas un écosystème de plugins aussi riche que d’autres éditeurs, donc il donne une impression assez basique, mais si vous avez besoin d’un outil pour écrire des scripts ou éditer des fichiers, il devrait tout à fait convenir
J’aime Kate. Dans mon précédent boulot, je devais absolument utiliser Windows, donc je l’ai installé tout de suite
J’avais besoin de bidouilles avec curseurs multiples et d’excellentes fonctions de recherche-remplacement. En revanche, le thème par défaut m’arrachait les yeux à chaque ouverture, ce qui posait problème, mais les builds nocturnes ont réglé ça
Kate a été le premier éditeur de code que j’ai utilisé sous Linux. C’est avec lui que j’ai appris PHP et Python
La coloration syntaxique rose pour Python me rend encore nostalgique. Je ne sais pas si c’est toujours comme ça aujourd’hui
Merci à tous les contributeurs, cela a clairement eu un impact sur ma vie