> Et les licences là dedans ? Et le design ?
Pour un utilisateur lambda : évidemment aucun intérêt. Tout ce qu'il voit c'est que son appli se charge plus lentement et qu'elle consomme plus de mémoire. Le pire c'est quand le bureau est mal configuré, les applis ont un look complètement différent. Va expliquer ensuite à un newbie qu'en choissant son thème dans kde control center, il ne sera pas répercuté sur Gimp par exemple, ou OOo. Il te dira : Windows c'est plus simple et honnêtement, il n'a pas tout à fait tord.
Pour le développeur : tout ce que je vois c'est des emmerdes. Est-ce si dur de concevoir un toolkit qui puisse emporter l'adhésion de tous ? Je pense qu'il important de ne pas faire de l'informatique pour l'informatique. Mais de voir ce qui est intéressant pour l'utilisateur. Les problèmes que tu ennonces sont des batailles de chiffonier pour les nouveaux venus. Ce problème d'interface graphique va couter à Linux autant qu'avait couté à Unix la séparation en branches incompatibles (Solaris, AIX, HPUX, Irix, Utrix, BSD, etc ...).
> je ne vois pas ce qui fait doublon ici
En vrac : le code (rappel : un toolkit est un composant qui fait au minium 1 à 2 millions de ligne de code), la doc, le temps passé à comprendre chaque composant, la configuration, les bugs, les mises à jour, les bindings pour chaque langages, etc ... à multiplier par chaques composants redondants.
> Si tout le monde avait la même ...
Même dans les exemples que tu cites il y a énormément de réutilisation (pour faire court). Uniformiser les API (surtout pour quelque chose d'aussi banal qu'un toolkit) n'implique pas d'uniformiser l'apparence, l'ergonomie ou les fonctionnalités, bien au contraire. Il faut arrêter de voir le monde en binaire : soit on uniformise tout, soit on n'uniformise rien. Ce n'est pas ce que j'ai écrit !
[^] # Re: Uniformiser les parties non visibles, améliore les performances
Posté par tpierron . En réponse au journal Laissons les Windowsiens tranquilles !. Évalué à 2.
Pour un utilisateur lambda : évidemment aucun intérêt. Tout ce qu'il voit c'est que son appli se charge plus lentement et qu'elle consomme plus de mémoire. Le pire c'est quand le bureau est mal configuré, les applis ont un look complètement différent. Va expliquer ensuite à un newbie qu'en choissant son thème dans kde control center, il ne sera pas répercuté sur Gimp par exemple, ou OOo. Il te dira : Windows c'est plus simple et honnêtement, il n'a pas tout à fait tord.
Pour le développeur : tout ce que je vois c'est des emmerdes. Est-ce si dur de concevoir un toolkit qui puisse emporter l'adhésion de tous ? Je pense qu'il important de ne pas faire de l'informatique pour l'informatique. Mais de voir ce qui est intéressant pour l'utilisateur. Les problèmes que tu ennonces sont des batailles de chiffonier pour les nouveaux venus. Ce problème d'interface graphique va couter à Linux autant qu'avait couté à Unix la séparation en branches incompatibles (Solaris, AIX, HPUX, Irix, Utrix, BSD, etc ...).
> je ne vois pas ce qui fait doublon ici
En vrac : le code (rappel : un toolkit est un composant qui fait au minium 1 à 2 millions de ligne de code), la doc, le temps passé à comprendre chaque composant, la configuration, les bugs, les mises à jour, les bindings pour chaque langages, etc ... à multiplier par chaques composants redondants.
> Si tout le monde avait la même ...
Même dans les exemples que tu cites il y a énormément de réutilisation (pour faire court). Uniformiser les API (surtout pour quelque chose d'aussi banal qu'un toolkit) n'implique pas d'uniformiser l'apparence, l'ergonomie ou les fonctionnalités, bien au contraire. Il faut arrêter de voir le monde en binaire : soit on uniformise tout, soit on n'uniformise rien. Ce n'est pas ce que j'ai écrit !