[HS]En espérant que blockquote fasse ce qu'il semble vouloir dire... Ca se réalise comment des requotes propres sur linuxfr?[/HS]
Ben non, meme si il le permet(tu peux faire un projet gnome depuis kdevelop), kdevelop est la avant tous pour les developpeurs KDE! Et il fait bien son boulot meme si je lui reproche quelques problemes d'instabilité.
Je n'utilise et ne connais quasiment pas kdevelop. J'imagine que le K fait référence à son intégration (aheum) au sein de KDE plus que son utilisation de qt.
Mwai, ils sont en train de faire comme tout le monde, mettre le maximum de chose dans des libs réutilisables, mais cela ne veut en aucun cas dire que tu aura un gimp basé sur Qt, gimp c'est du gobject(model objet de gtk)!
Ca serait effectivement totalement biscornu d'utiliser les fonctionnalités de la glib et faire du qt en 'backend' graphique. Et vice versa. Et se priver de ces libs de base, c'est vouloir réinventer la roue.
Aucun rapport, c'est juste la pour permettre aux applications sous linux(pas uniquement kde et gnome) de communiquer entre elles.
Tu fais donc référence à DBus. Il me semblait que pour l'instant, Gnome et KDE utilisaient leur propre modèle, mais qu'ils avaient décidé de coopérer pour l'utilisation d'une base commune. C'est ce dont je parle: on détache/modularise afin de ne pas limiter une fonctionnalité à un seul environnement - quand celle-ci est disponible sous plusieurs. Après, je me doute bien qu'il y a des différences de modèle insurmontables.
Mais vouloir une application à la fois Qt et Gtk, c'est totalement utopique tellement ces deux toolkit sont différents: pas les meme widgets, comportements, ...
Je pensais plus au fait que tu apportes une surcouche (avec tous les défauts que ça peut entraîner) qui permettent d'utiliser un backend au choix.
Je suis d'accord que, partant sur la glib ou QT, tu peux difficilement choisir autre chose que respectivement GTK+ ou ... (je ne connais pas l'équivalent pour les widgets graphiques liés à QT).
Je pense que le point de vue du commentaire parent reste valable, à savoir (et à ce que j'ai compris) qu'un minimum de généralisme ne fait pas de mal. Moins il y a de dépendances obligatoires aux libs gnome (GTK+ étant d'une gêne de magnitude différente) ou KDE, mieux ça me semble être (sauf au prix de fonctionnalités, bien sûr).
[^] # Re: pourquoi spécifiquement ?
Posté par Kurosu . En réponse à la dépêche Sortie de Anjuta 2.0.0. Évalué à 1.
Je n'utilise et ne connais quasiment pas kdevelop. J'imagine que le K fait référence à son intégration (aheum) au sein de KDE plus que son utilisation de qt.
Ca serait effectivement totalement biscornu d'utiliser les fonctionnalités de la glib et faire du qt en 'backend' graphique. Et vice versa. Et se priver de ces libs de base, c'est vouloir réinventer la roue.
Tu fais donc référence à DBus. Il me semblait que pour l'instant, Gnome et KDE utilisaient leur propre modèle, mais qu'ils avaient décidé de coopérer pour l'utilisation d'une base commune. C'est ce dont je parle: on détache/modularise afin de ne pas limiter une fonctionnalité à un seul environnement - quand celle-ci est disponible sous plusieurs. Après, je me doute bien qu'il y a des différences de modèle insurmontables.
Je pensais plus au fait que tu apportes une surcouche (avec tous les défauts que ça peut entraîner) qui permettent d'utiliser un backend au choix.
Je suis d'accord que, partant sur la glib ou QT, tu peux difficilement choisir autre chose que respectivement GTK+ ou ... (je ne connais pas l'équivalent pour les widgets graphiques liés à QT).
Je pense que le point de vue du commentaire parent reste valable, à savoir (et à ce que j'ai compris) qu'un minimum de généralisme ne fait pas de mal. Moins il y a de dépendances obligatoires aux libs gnome (GTK+ étant d'une gêne de magnitude différente) ou KDE, mieux ça me semble être (sauf au prix de fonctionnalités, bien sûr).