La vision amené dans ce long journal est une vision extrêmement pessimiste des frameworks de Linux. Prenons un exemple simple : Les Frameworks graphiques.
La diversitée des libs graphiques n'est pas plus importante dans un système GNU/Linux que dans un windows classique (voir un commentaire précédent pour plus d'information). La différence essentielle entre les deux système, c'est que là où les second ont un devveloppement fort peu avancé (par rapport a la lib win normal), et ne sont finalement que rarement utilisé, les premiers forment une toile d'ossature autour de quelques projets importants : Gnome, KDE, E17 pour en prendre trois. Dire que cette profusion est un frein au devellopement d'application est une logique digne des Looney Tunes. Au contraire, plus il y a de Toolkit, plus le devellopeur a le choix et plus celui-ci a de possibilité ; de plus, s'il a peur de s'investir dans plusieurs toolkit, il peut fort bien n'en choisir qu'un seul comme il le ferait de manière classique avec windows, car ceux-ci sont tous extrêmement mature.
Maintenant, quittons le point de vue du programmeur pour prendre celui de l'utilisateur. Certes, l'hétérogénéité des applications que forment autant de frameworks peuvent le déconcerter. Mais n'est-ce pas la principale occupation des devellopeurs que de maintenant offrir des interconnexions stables entre ces frameworks ? Nous pouvons citer Freedesktop, qui constitue un pont majeur entre Gnome, KDE et les autre WM ; plus lointain, les certifications Posix, les système de paquets - dont aujourd'hui nous n'avons plus que deux importants, ainsi qu'une pléthore de moindre importances mais tout aussi mature -, le Dcop, X, etc. Malgré la profusion qu'ordonne le principe de develloppement même de GNU/Linux et dérivé, la préocupation de rassembler les éléments autour de quelque chose en commun s'est très vite imposé. Aujourd'hui, on lance des programmes Gnome dans KDE, et ceux-ci prennent automatiquement l'apparence du théme en place, et vice-versa. Ce n'est plus qu'une question de temps et de spécification avant que le reste ne communique simplement.
Enfin, une dernière chose : L'inexistence de "Killer lib" que suppose la fragmentation des devellopeurs est un arguments véritablement infondés dés qu'on recherche un peu plus loin que la croute. Beaucoup de toolkit et libs restent dans l'ombre alors qu'ils sont révolutionnaire, justement parce qu'ils sont révolutionnaire. Deux citations viennent appuyer : les EFL et la CImg library. La première forme l'ensemble des librairies révolutionnaire sur laquelle s'est formé E17. Elle prodiguent, avec beaucoup plus de simplicité et beaucoup moins de ressources que n'importe quels ensembles, des capacités avancés de retouche d'image, d'animation , d'interruption processus, de description graphique (X ans avant XUL). C'est des librairies qui, en leur temps, ont été révolutionnaire, et que seuls la superposition de plusieurs couches permettent aujourd'hui d'approcher l'équivalence.
L'autre exemple, la CImg, est un peu équivalent. Très bon, très simple, très rapide, rarement ou peu utilisé.
# Des Frameworks et de leurs places dans la vie virtuelle
Posté par ThesmallgamerS . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 3.
La diversitée des libs graphiques n'est pas plus importante dans un système GNU/Linux que dans un windows classique (voir un commentaire précédent pour plus d'information). La différence essentielle entre les deux système, c'est que là où les second ont un devveloppement fort peu avancé (par rapport a la lib win normal), et ne sont finalement que rarement utilisé, les premiers forment une toile d'ossature autour de quelques projets importants : Gnome, KDE, E17 pour en prendre trois. Dire que cette profusion est un frein au devellopement d'application est une logique digne des Looney Tunes. Au contraire, plus il y a de Toolkit, plus le devellopeur a le choix et plus celui-ci a de possibilité ; de plus, s'il a peur de s'investir dans plusieurs toolkit, il peut fort bien n'en choisir qu'un seul comme il le ferait de manière classique avec windows, car ceux-ci sont tous extrêmement mature.
Maintenant, quittons le point de vue du programmeur pour prendre celui de l'utilisateur. Certes, l'hétérogénéité des applications que forment autant de frameworks peuvent le déconcerter. Mais n'est-ce pas la principale occupation des devellopeurs que de maintenant offrir des interconnexions stables entre ces frameworks ? Nous pouvons citer Freedesktop, qui constitue un pont majeur entre Gnome, KDE et les autre WM ; plus lointain, les certifications Posix, les système de paquets - dont aujourd'hui nous n'avons plus que deux importants, ainsi qu'une pléthore de moindre importances mais tout aussi mature -, le Dcop, X, etc. Malgré la profusion qu'ordonne le principe de develloppement même de GNU/Linux et dérivé, la préocupation de rassembler les éléments autour de quelque chose en commun s'est très vite imposé. Aujourd'hui, on lance des programmes Gnome dans KDE, et ceux-ci prennent automatiquement l'apparence du théme en place, et vice-versa. Ce n'est plus qu'une question de temps et de spécification avant que le reste ne communique simplement.
Enfin, une dernière chose : L'inexistence de "Killer lib" que suppose la fragmentation des devellopeurs est un arguments véritablement infondés dés qu'on recherche un peu plus loin que la croute. Beaucoup de toolkit et libs restent dans l'ombre alors qu'ils sont révolutionnaire, justement parce qu'ils sont révolutionnaire. Deux citations viennent appuyer : les EFL et la CImg library. La première forme l'ensemble des librairies révolutionnaire sur laquelle s'est formé E17. Elle prodiguent, avec beaucoup plus de simplicité et beaucoup moins de ressources que n'importe quels ensembles, des capacités avancés de retouche d'image, d'animation , d'interruption processus, de description graphique (X ans avant XUL). C'est des librairies qui, en leur temps, ont été révolutionnaire, et que seuls la superposition de plusieurs couches permettent aujourd'hui d'approcher l'équivalence.
L'autre exemple, la CImg, est un peu équivalent. Très bon, très simple, très rapide, rarement ou peu utilisé.
Hum... Voilà.