C'est que pour moi le composant de KWord n'a pas à se lancer ailleurs que dans KWord.
Interessant comme point de vue :-). Et quel est alors l'interêt d'en faire un composant ?
Pour moi permettre à d'autres applications qu'un traitement de texte d'afficher un document kwd ne sert à rien à part à compliquer les choses pour l'utilisateur débutant.
D'après mon expérience, ça ne semble pas être le cas.
Ça n'aide certainement pas à faire la distinction entre un gestionnaire de fichiers, un traitement de texte...
Mais pourquoi aurait-il à la faire ? Il n'y a aucune loi qui dit que cette distinction soit obligatoire, nécéssaire, ou même utile. L'utilisateur veut juste rédiger ses textes, ce genre de distinctions il s'en fout complètement.
Ceci dit les gens sont capables de choisir entre un portable Nokia ou Siemens
Mais contrairement aux toolkits, un portable siemens peut marcher sur n'importe quel réseau et appeller ou être appelé par n'importe quel portable. Tout ça est standardisé et compatible.
Pour un développeur, devoir choisir entre plusieurs toolkits implique qu'il va devoir passer du temps à évaluer chaque toolkit, puis à imposer à ses utilisateurs d'avoir la toolkit choisie installée et à jour. Pour du free, il va aussi imposer l'API a ceux qui veulent participer. Pour du commercial, à ses collaborateurs.
Dans le cas de Linux c'est pas trop un pb, toutes les distribs installent toutes les toolkits. Pour les autres Unix, y a que Motif et Athena en standard, et installer une toolkit n'est pas forcément trivial (faut souvent être root, avoir un accès à l'extérieur pour downloader l'archive, etc...). Windows n'a jamais posé ce pb à ses développeurs, et ça a été un avantage énorme.
Il n'y a qu'a voir le nombre de projets qui sont des portages d'un projet existant vers une autre toolkit. Est-ce vraiment interessant de faire ce genre de boulot ? Est-ce que le temps qu'on y consacre ne pourrait pas être mieux utilisé à améliorer l'appli de départ ? Et toi qui râle contre les trucs lourds, crois-tu qu'avoir plusieurs toolkits en mémoire (lance xterm, galeon, ddd et kword : 4 toolkits) soit une bonne chose ?
Pourquoi crois-tu que toutes les plateformes de dev récentes (BeOS, Java, .NET...) spécifient quasiment tout, y compris et surtout le graphisme ? L'industrie a compris la leçon.
Au moins sous Linux maintenant ça se décide entre GTK+ et Qt, les autres ont quasi disparu. Les choses s'améliorent.
Quant aux WM, là c'est pire : rien que faire comprendre le concept de window manager à un utilisateur de base, c'est ridicule. Et c'est aussi c'est une grosse source d'emmerdes pour les développeurs, avec des WMs qui sont plus ou moins IEEE compliant, les thèmes qui marchent plus ou moins bien, etc...
[^] # Re: Un peu comme MS-Windows 1
Posté par Guillaume Laurent . En réponse à la dépêche Ces "nouveaux" gestionnaires de fenêtres. Évalué à 1.
Interessant comme point de vue :-). Et quel est alors l'interêt d'en faire un composant ?
Pour moi permettre à d'autres applications qu'un traitement de texte d'afficher un document kwd ne sert à rien à part à compliquer les choses pour l'utilisateur débutant.
D'après mon expérience, ça ne semble pas être le cas.
Ça n'aide certainement pas à faire la distinction entre un gestionnaire de fichiers, un traitement de texte...
Mais pourquoi aurait-il à la faire ? Il n'y a aucune loi qui dit que cette distinction soit obligatoire, nécéssaire, ou même utile. L'utilisateur veut juste rédiger ses textes, ce genre de distinctions il s'en fout complètement.
Ceci dit les gens sont capables de choisir entre un portable Nokia ou Siemens
Mais contrairement aux toolkits, un portable siemens peut marcher sur n'importe quel réseau et appeller ou être appelé par n'importe quel portable. Tout ça est standardisé et compatible.
Pour un développeur, devoir choisir entre plusieurs toolkits implique qu'il va devoir passer du temps à évaluer chaque toolkit, puis à imposer à ses utilisateurs d'avoir la toolkit choisie installée et à jour. Pour du free, il va aussi imposer l'API a ceux qui veulent participer. Pour du commercial, à ses collaborateurs.
Dans le cas de Linux c'est pas trop un pb, toutes les distribs installent toutes les toolkits. Pour les autres Unix, y a que Motif et Athena en standard, et installer une toolkit n'est pas forcément trivial (faut souvent être root, avoir un accès à l'extérieur pour downloader l'archive, etc...). Windows n'a jamais posé ce pb à ses développeurs, et ça a été un avantage énorme.
Il n'y a qu'a voir le nombre de projets qui sont des portages d'un projet existant vers une autre toolkit. Est-ce vraiment interessant de faire ce genre de boulot ? Est-ce que le temps qu'on y consacre ne pourrait pas être mieux utilisé à améliorer l'appli de départ ? Et toi qui râle contre les trucs lourds, crois-tu qu'avoir plusieurs toolkits en mémoire (lance xterm, galeon, ddd et kword : 4 toolkits) soit une bonne chose ?
Pourquoi crois-tu que toutes les plateformes de dev récentes (BeOS, Java, .NET...) spécifient quasiment tout, y compris et surtout le graphisme ? L'industrie a compris la leçon.
Au moins sous Linux maintenant ça se décide entre GTK+ et Qt, les autres ont quasi disparu. Les choses s'améliorent.
Quant aux WM, là c'est pire : rien que faire comprendre le concept de window manager à un utilisateur de base, c'est ridicule. Et c'est aussi c'est une grosse source d'emmerdes pour les développeurs, avec des WMs qui sont plus ou moins IEEE compliant, les thèmes qui marchent plus ou moins bien, etc...