si ça augmente les délais de développement ça n'a aucun interêt
Dans une optique commerciale, oui, mais tu conviendras que tu t'en fous un peu lors d'un développement de type hobby.
Gnome est un mauvais exemple...
Pour Gnome je ne sais pas, d'habitude je m'arrette à GTK. Mais pour ce qui est de GTK, tu es bien placé pour le savoir, ça reste objet, léger et simple d'utilisation. Malgrès le choix du C qui n'est pas très approprié pour du dev de haut niveau (à mon avis), GTK reste nettement plus intéressant et simple que les librairies que j'utilise au boulot.
Et puis, le problème n'est pas Gnome ou QT/KDE, je disais juste que cette approche composants/objets favorisait l'apparition de gags comme les accès répétés aux ressources et les boucles inutiles. Le côté boite noire fait que tu n'as pas vraiment à savoir ce que fait l'objet en interne mais pour l'utiliser correctement, tu dois connaitre quand même son fonctionnement interne. Pire encore, plus l'objet est complexe, plus tu as de chances qu'il ne te convienne pas.
Bon, remarque, c'est pareil pour les librairies et pour le code généré par les compilos, mais si tu multiplies les couches, tu multiplies la compléxité des objets manipulés et le risque de consommation inutile alors qu'on peut faire mieux sans cet amas de couches.
Si ta production est diffusée dans l'entreprise (c'est mon cas), ce que tu gagnes en temps de developpement, tu le fais perdre largement en infrastructures (machines, réseau, etc). On ne change pas de machines tous les ans (ça coute trop cher et c'est invendable d'occase).
[^] # Re: Un peu comme MS-Windows 1
Posté par Toufou (site web personnel) . En réponse à la dépêche Ces "nouveaux" gestionnaires de fenêtres. Évalué à 1.
Dans une optique commerciale, oui, mais tu conviendras que tu t'en fous un peu lors d'un développement de type hobby.
Gnome est un mauvais exemple...
Pour Gnome je ne sais pas, d'habitude je m'arrette à GTK. Mais pour ce qui est de GTK, tu es bien placé pour le savoir, ça reste objet, léger et simple d'utilisation. Malgrès le choix du C qui n'est pas très approprié pour du dev de haut niveau (à mon avis), GTK reste nettement plus intéressant et simple que les librairies que j'utilise au boulot.
Et puis, le problème n'est pas Gnome ou QT/KDE, je disais juste que cette approche composants/objets favorisait l'apparition de gags comme les accès répétés aux ressources et les boucles inutiles. Le côté boite noire fait que tu n'as pas vraiment à savoir ce que fait l'objet en interne mais pour l'utiliser correctement, tu dois connaitre quand même son fonctionnement interne. Pire encore, plus l'objet est complexe, plus tu as de chances qu'il ne te convienne pas.
Bon, remarque, c'est pareil pour les librairies et pour le code généré par les compilos, mais si tu multiplies les couches, tu multiplies la compléxité des objets manipulés et le risque de consommation inutile alors qu'on peut faire mieux sans cet amas de couches.
Si ta production est diffusée dans l'entreprise (c'est mon cas), ce que tu gagnes en temps de developpement, tu le fais perdre largement en infrastructures (machines, réseau, etc). On ne change pas de machines tous les ans (ça coute trop cher et c'est invendable d'occase).