Pour repondre a la remarque originale, il faut bien distinguer deux choses:
- le toolkit utilise par anjuta
- les modeles proposes pour faire du dev
Il est evident que anjuta developpe par et pour Gnome utilise a fond les bibliotheques et toutes les possibilites de Gnome.
Il est aussi tout a fait naturel que maitrisant bien Gnome et le developpant pour Gnome, les modeles de projets soient des modeles de projets Gnome.
Mais il ne faut pas y voir la une restriction. Je ne connais pas anjuta mais je serai surpris que l'auteur y aie mis une telle restriction. C'est juste des modeles de projets. Avec le temps et avec les contributions, d'autres modeles seront proposes, qui te permettront de commencer facilement un projet KDE, un projet ncurses, etc.
Si tu prends KDevelop, le concurrent principal, au debut, il n'y avait que des modeles de projets pour KDE ou pour rien du tout. Maintenant, si tu regardes la listes des modeles en C/C++, tu vois qu'il y a beaucoup de KDE, mais pas mal d'autres choses: du ncurses, du gnome, ... http://webcvs.kde.org/kdevelop/languages/cpp/app_templates/(...)
Donc si tu veux des modeles pour d'autres projets que Gnome, a toi de les proposer.
Si tu veux que anjuta ne s'integre pas dans Gnome, c'est completement debile.
> Mais c'est assez risqué d'intégrer des considérations spécifiques à un environnement graphique (IHM) dans le coeur de gestion
En effet, on devrait faire des applis Gnome qui ne dependent pas de Gnome. Comme ca, pas de considerations IHM dans le coeur de gestion.
Pour faire une reponse plus intelligente, Gnome (ou KDE), c'est bien plus qu'une IHM. C'est un modele de boucle d'evenement, des classes de bases, un modele graphique et une IHM. Si tu developpes avec Gnome, tu utilises au strict minimum le modele de la boucle d'evenement et le modele graphique. En general, il n'y a pas de raison de se priver des autres elements.
> On se retrouve dans des situations à la k3b où les gens n'ont les libs qt que pour cette appli.
Et ? Quel probleme cela pose-t-il ? Avoir Qt pour k3b est une bonne raison d'avoir Qt.
> Résultat, une application aussi fondatrice de GTK+ que Gimp est en train de détacher le core de la GUI.
Au contraire, c'est une bonne chose. En separant bien les fonctionnalites de gimp de son interface, on ouvre la possibilite a une nouvelle communaute de contributeur de proposer des nouvelles interfaces. On pourrait donc avoir un gimp en WxWidgets, un gimp en Qt, un gimp en KDE, un gimp en ncurses (j'deconne!).
Honnetement, je trouve que ca ne devrait pas etre le boulot des developpeurs d'applis de developper le toolkit. Gimp a developpe gtk parce qu'il n'y avait rien qui leur convenait. Si un bon equivalent de Gtk avait ete la a l'epoque, gimp l'aurait utilise.
Developper un toolkit et developper une appli sont deux choses differentes. On a pas necessairement les memes objectifs
> Après tout, les spécifications FreeDesktop, la gestion unifiée des messages (Dbus?) me semblent permettre une description du comportement d'une application sans référer à un toolkit.
Tu fais erreur. DBUS, s'il est adopte par KDE et Gnome permet juste d'envoyer des messages a des applications.
On n'a pas a l'heure actuelle de description d'une application complete independante du toolkit. Et tu sais quoi ? C'est une bonne chose. Pour faire une bonne application (ergonomique, fonctionelle, rapide, optimisee), il faut tirer au maximum avantage des possibilites du toolkit.
> Cependant, c'est très récent ce genre de réflexion, et on peut se demander si le port qt de firefox (ou de son rendu, peu importe, je
> souhaiterais qu'on n'ergote pas sur les termes) ne risque pas de souffrir d'une conception trop conditionnée par GTK+.
Ben justement, le rendu ne depend pas de Gtk, ce qui a permis de le porter rapidement en Qt.
Je pense que tu devrais te renseigner plus sur les questions qui te tarabustent, parce que visiblement, tu es peu informe et du dis des betises.
[^] # Re: pourquoi spécifiquement ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Anjuta 2.0.0. Évalué à 6.
- le toolkit utilise par anjuta
- les modeles proposes pour faire du dev
Il est evident que anjuta developpe par et pour Gnome utilise a fond les bibliotheques et toutes les possibilites de Gnome.
Il est aussi tout a fait naturel que maitrisant bien Gnome et le developpant pour Gnome, les modeles de projets soient des modeles de projets Gnome.
Mais il ne faut pas y voir la une restriction. Je ne connais pas anjuta mais je serai surpris que l'auteur y aie mis une telle restriction. C'est juste des modeles de projets. Avec le temps et avec les contributions, d'autres modeles seront proposes, qui te permettront de commencer facilement un projet KDE, un projet ncurses, etc.
Si tu prends KDevelop, le concurrent principal, au debut, il n'y avait que des modeles de projets pour KDE ou pour rien du tout. Maintenant, si tu regardes la listes des modeles en C/C++, tu vois qu'il y a beaucoup de KDE, mais pas mal d'autres choses: du ncurses, du gnome, ...
http://webcvs.kde.org/kdevelop/languages/cpp/app_templates/(...)
Donc si tu veux des modeles pour d'autres projets que Gnome, a toi de les proposer.
Si tu veux que anjuta ne s'integre pas dans Gnome, c'est completement debile.
> Mais c'est assez risqué d'intégrer des considérations spécifiques à un environnement graphique (IHM) dans le coeur de gestion
En effet, on devrait faire des applis Gnome qui ne dependent pas de Gnome. Comme ca, pas de considerations IHM dans le coeur de gestion.
Pour faire une reponse plus intelligente, Gnome (ou KDE), c'est bien plus qu'une IHM. C'est un modele de boucle d'evenement, des classes de bases, un modele graphique et une IHM. Si tu developpes avec Gnome, tu utilises au strict minimum le modele de la boucle d'evenement et le modele graphique. En general, il n'y a pas de raison de se priver des autres elements.
> On se retrouve dans des situations à la k3b où les gens n'ont les libs qt que pour cette appli.
Et ? Quel probleme cela pose-t-il ? Avoir Qt pour k3b est une bonne raison d'avoir Qt.
> Résultat, une application aussi fondatrice de GTK+ que Gimp est en train de détacher le core de la GUI.
Au contraire, c'est une bonne chose. En separant bien les fonctionnalites de gimp de son interface, on ouvre la possibilite a une nouvelle communaute de contributeur de proposer des nouvelles interfaces. On pourrait donc avoir un gimp en WxWidgets, un gimp en Qt, un gimp en KDE, un gimp en ncurses (j'deconne!).
Honnetement, je trouve que ca ne devrait pas etre le boulot des developpeurs d'applis de developper le toolkit. Gimp a developpe gtk parce qu'il n'y avait rien qui leur convenait. Si un bon equivalent de Gtk avait ete la a l'epoque, gimp l'aurait utilise.
Developper un toolkit et developper une appli sont deux choses differentes. On a pas necessairement les memes objectifs
> Après tout, les spécifications FreeDesktop, la gestion unifiée des messages (Dbus?) me semblent permettre une description du comportement d'une application sans référer à un toolkit.
Tu fais erreur. DBUS, s'il est adopte par KDE et Gnome permet juste d'envoyer des messages a des applications.
On n'a pas a l'heure actuelle de description d'une application complete independante du toolkit. Et tu sais quoi ? C'est une bonne chose. Pour faire une bonne application (ergonomique, fonctionelle, rapide, optimisee), il faut tirer au maximum avantage des possibilites du toolkit.
> Cependant, c'est très récent ce genre de réflexion, et on peut se demander si le port qt de firefox (ou de son rendu, peu importe, je
> souhaiterais qu'on n'ergote pas sur les termes) ne risque pas de souffrir d'une conception trop conditionnée par GTK+.
Ben justement, le rendu ne depend pas de Gtk, ce qui a permis de le porter rapidement en Qt.
Je pense que tu devrais te renseigner plus sur les questions qui te tarabustent, parce que visiblement, tu es peu informe et du dis des betises.