Oui a lille il y a quelques semaines, le generateur de secours a pris le relais. C'etait la premiere coupure.
Je soutiens entierement leur action, sauf quand c'est n'importe quoi. Le probleme, c'est qu'ils mettent des vie en danger, et je trouve ca inadmissible : Rendre la signalisation HS le matin, couper les hopitaux, supprimer l'eclairage publique en pleine nuit, sans oublier certains particuliers soignés a domicile qui n'ont pas de generateur de secours. L'electricité n'est pas qu'un confort, elle est vitale pour de nombreuses personnes, c'est cet argument qu'ils avancent, et pourtant on peut se demander s'ils l'ont vraiment tous compris ...
Et tu trouves ca normal de couper le courant des hopitaux et service de secours, des sociétés, des particuliers, ... Il ferait mieux de s'attaquer au vrai fautif et couper uniquement l'electricité de matignon, l'elysee ou le siege social d'EDF.
J'estime que certains domaines devraient rester sous le controle de l'etat, EDF en fait partie. Mais ce qui me revolte c'est de prendre les autres en otages. Il y a d'autres moyens d'action que de couper l'electricité. ( Ils peuvent bloquer l'envoi des factures, offrir un mois d'electricité a tout le monde, manifester dans la rue plutot que de rester chez soit ou d'aller a rolland garros ... )
Cairo is a vector graphics library with cross-device output support. Currently supported output targets include the X Window System, in-memory image buffers, and PostScript. An OpenGL backend is in progress, and PDF file output is planned. Cairo is designed to produce identical output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension).
Quelques petites corrections et precisions s'imposent ;)
1. Le ZBuffer est utilisé en hard et en soft, c'est le seul moyen efficace et facilement "cablabe" pour afficher les faces dans le bon ordre.
2. Le BSP, comme les octree, portals et compagnie consiste a diminuer le nombre de polygonne a envoyer a la carte graphique.
Pour mieux comprendre on va prendre un exemple.
On a une scene composée de polygonne que l'on desire afficher, pour cela il nous faut determiner quels sont les polygonnes cachant les autres et figurant devant l'observateurs. Il existe plusieurs techniques : le ZBuffer et le raytracing sont les plus utilisés.
Si cette scene est composée d'un milion de polygonnes on va faire tourner ces algorithmes sur cet ensemble, ce qui n'est pas tres efficace, car il est possible de reduire celui-ci a l'avance. Cette reduction prend en compte la position de l'observateur et determine les polygonnes qui ne seront jamais visibles.
Ce choix peut etre :
- arbitraire : en bornant volontairement le champ de vision (clipping)
- logique : dans les scenes indoor, il est inutile d'envoyer a la carte graphique les polygonnes des pieces ou l'observateur n'est pas present (principe "simplifié" des portals)
- basé sur une repartition spatiale des polygonnes : en classant les polygonnes par zones dans des arbres (Octree, BSPTree, KD-Tree, ...)
Que ce soit en soft ou en hard, ces techniques peuvent etre utilisées conjointement. Ce qui est le cas de Quake. De plus le ZBuffer et derivé sont systematiquement utilisés car ce sont les seules techniques a etre aussi efficaces, polyvalentes et independantes de la scene. Dans l'avenir on se dirigera progressivement vers des methodes hybrides raytracing/zbuffer puis 100% raytracing. Ce qui est un juste retour aux choses, car les tous premier moteurs (Wolfenstein, doom I et II, ...) etaient basés sur un algorithme de raytracing (extremement) simplifié ;)
Sinon pour repondre aux questions de sylvain, les jeux et applications utilisant un moteur 3D basé sur OpenGL exploiteront la bibliotheque openGL installée sur ta config. Si tu possedes une carte 3D et que les drivers du constructeurs sont installé, OpenGL pourra etre vue comme l'interface entre le moteur 3D applicatif et la partie hardware de la carte 3D. Si aucune carte n'est installée, une autre implémentation sera utilisée effectuant tous les calculs en soft (Mesa generallement).
Pour SDL, il ne faut pas tout melanger ;) SDL est une couche d'abstraction du materiel permettant d'acceder de maniere simple a des zones de la memoire video, aux fonctionnalités audios, thread, communication, ... independament de la plateforme. SDL ne sait pas faire de 3D et n'utilise donc pas de zbuffer. Par contre, il est possible d'utiliser ces zones de memoires videos pour l'affichage de scene OpenGL ou le calcul du ZBuffer.
Par contre je maintiens qu'on peut les comparer: deux bout de code qui ont la meme finalite mais une architecture/implementation differente ...
Oui tout a fait. Je voulais juste preciser et justifier dans mes commentaires precedents pourquoi un fichier word est plus gros qu'un fichier OOo et casser le mythe comme quoi word enregistre un peu n'importe quoi pour faire plaisir aux vendeurs de disque dur en augmentant artificelement la taille des fichiers* ;)
Je voulais aussi ajouter que le code et l'architecture de ce genre d'applis sont tres couplés a ce type de format de fichier. Ce qui est moins le cas pour le XML ou les données et le code applicatif sont parfaitement séparés.
C'etait ces deux points qui font que pour moi ce n'est pas vraiment comparable car il ne s'agit pas d'implementations differentes mais bien d'architecture differente.
Et malheureusement ce ne sont pas vraiment deux bout de code qui ont la meme finalite : la portée est plus grande et les conséquences pour le developpeur plus lourdes. Par contre pour l'utilisateur, et au final c'est ce qui est le plus important, c'est tout a fait comparable.
* Quoique ce manque de transparence empeche evidement de connaitre la nature exacte des données enregistrées ...
Tout a fait d'accord, mais du point de vue du developpeur, ce n'est pas qu'une implementation d'une fonctionnalité, c'est aussi toute une architecture propre a l'application : Le format de fichier word est tres lié a OLE/COM et a la programation par composants. On ne lit pas un fichier word comme on lit un fichier XML, d'ailleur il n'y a pas vraiment de parser ni de grammaire pour le format DOC. De plus l'utilisation au niveau API est tres differente, ce n'est donc pas comparable a mon avis.
Ce choix est criticable, mais les avantages pour eux sont nombreux : pas de transparence (=> reverse enginering difficile), le modele objet applicatif est caché (=> la propriété industrielle sur l'architecture du logiciel n'est pas devoilée), le modele par composants leur assure un format de fichier facilement étendable (qui permet d'inclure d'autres composants par exemple) ou le chargement partiel d'un fichier.
Ceci dit, tout ce que je viens de dire est tout a fait envisageable en XML ;)
Et pour revenir a mon exemple entre un binaire java et un binaire standard c'est exactement la meme chose, le binaire java, meme s'il est plus gros aura l'avantage d'etre portable. Tout ceci est donc un compromis entre les fonctionnalités offertes par un format et finallement le poids du fichier lui meme.
Finallement, je ne pense pas que la taille d'un fichier soit vraiment porblematique mais plutot le fait qu'il ne soit pas libre et ouvert.
Je compare ce qui est comparable: un meme fichier, une fois en format OOo, et une fois en format Word ...
Oui et non, pour l'utilisateur c'est effectivement comparable, mais d'un point de vue developpeur la difference est plus importante, puisque les fonctionnalités ne sont pas les memes (duplication des donnees entre autre, meme si elle n'est pas parfaitre ;). Ce serait comme si tu comparais la taille d'un executable java (son bytecode) et celui d'un binaire standard.
De plus, d'apres ce que tu m'en dit, le format de fichier OOo a l'air vachement plus propre que celui de Word.
Ya pas photo ! Plus propre, plus souple, facilement étandable, et surtout plus stable : une erreur dans le fichier n'est pas dramatique (un decalage de byte par exemple) au pire on dezip, on ouvre le fichier et on regarde ou est l'erreur de syntaxe pour la corriger. Au mieux, des outils automatiques sont deja disponibles. Pour Word, il faut prier pour que l'historique ou que la duplication des données soit presente et surtout valide ...
soit dit en passant je l'ai sauve aussi en format OOo et le fichier est beaucoup plus petit que le format Word
Le format de fichier utilisé par word n'a rien a voir avec celui utilisé par OpenOffice : OOo utilise XML et compacte le tout, word est un format binaire "proche" d'un dump memoire (en fait, il s'agit de la collection d'objets au sens POO qui sont dumpé dans le fichier, c'est similaire a de la serialization). De plus ce mecanisme implémente des fonctionnalitées de tolerance de panne en duplicant les données par exemple ou en maintenant un historique des modifications. Il est donc évident que le fichier obtenu soit plus gros.
L'info à prendre avec des pincettes
Cette info est vraie et a deja été relayée par d'autres sites de news (OsNews, clubic Huuummm ;) ...). La principale limitation concerne le support reseau je crois.
Sinon, j'ai lu que Microsoft voulait "coopérer" avec des projets libres tels que Mozilla, pour parfaire leur integration dans Longhorn. Je pense que leur demande consiste a integrer certaines de leur technologie (support de WinFS par exemple) dans ces logiciels libres. Cette news etait parues sur OSNews mais je ne la retrouve plus.
J'avais bien compris, mais je faisait juste une precision a 2c sur le signe != qui n'est pas valide puisque les LL sont des logiciels OS. D'ou mon signe C (l'inclusion en maths).
dans le cas des KDElibs, ça doit être la licence commerciale qui joue
Prendre QT sous licence GPL suffit pour compiler les kdelibs. Par contre l'ensemble QT+KdeLibs est sous GPL. Si tu veux faire une application closed-source basée sur KdeLibs, tu es obligé d'acheter une licence de QT commerciale pour pouvoir exploiter la licences LGPL des KDELibs.
KDE a du payé des kits de dev à Qt, mais peuvent distribuer leur produit comme ils veulent.
Je ne pense pas que ce soit le cas car LGPL et GPL sont compatibles. La licence commerciale n'est donc pas obligatoire. De plus le prix d'une licence est tres elevé et limitée a un developpeur. Et finallement, si ce que tu dis est vrai, cela signifie que les KdeLibs ne pourraient pas etre distribuée sous forme de source car une licence commerciale de QT serait necessaire pour tout compiler.
Demander a la boite de proposer une licence commerciale te permettant de continuer ton developpement proprietaire sur la nouvelle lib (exemple de QT) ou passer sous une licence encore moins restrictive, BSD ou LGPL par exemple.
Dans la "vraie vie", je pense que ce sera le cas (licence commerciale specifique), car la boite, a moins d'etre altruiste, doit toujours vouloir vendre sa lib pour faire de l'argent.
Many of the most common open source licenses, such as the original MIT/X license, the new BSD license, and the LGPL, are "GPL-compatible". That is, their code can be combined with a GPL'ed program without conflict (the new combination would have the GPL applied to the whole).
La licence qu'il faut donc considérer est la licence la plus "forte" parmie toutes les licences "compatibles" utilsées par les bibliotheques liées (Ouuf ;) Ce que tu illustres donc parfaitement. Le probleme que j'ai donc soulevé dans mon journal n'est pas valide car B sera sous licence GPL (et non LGPL comme je l'affirmais)
Par contre cela implique un point que j'avais soulevé dans mon journal précédent : Il est necessaire de connaitre l'ensemble des licences des bibliotheques, meme celles dont on est dependant indirectement, car, toujours dans le cas des KDElibs, celles-ci sont sous LGLP, mais dans la pratique c'est du GPL, car QT lui est sous GLP. Bon enfin je me comprends ;)
Faudrait un outil automatique qui determine automatiquement les licences possibles d'une appli en fonction de ses libs ;)
Sinon j'avais vu, il y a quelques années, un quizz/QCM d'une dizaine de questions sur les licences avec differents cas "limites". Si quelqu'un a le lien ca m'interesse.
Oui pour moi aussi, mais ce qui est dit n'est pas valide* puisque de nombreux contres exemples existent (dont celui que je cite un peu plus loin Qt et KDELibs)
* une bibliothe GPL ne peut pas etre liee a une bibliotheque LGPL
noter que ça me fait ça en twin view d'nvidia mais pas si j'ai qu'un écran...
A verifier, certaines cartes graphiques ne supportent pas l'overlay en mode twin view. D'autres le supporte mais uniquement sur le primary display. Regarde dans ta doc, google ou essaie sous windows pour voir si le comportement est identique.
Je n'ai jamais dit que c'etait revolutionnaire mais tu as raison de preciser que d'un point de vue utilisateur on fait deja ce genre de chose depuis que les reseaux existent.
Avalon n'est pas qu'un systeme de composition 2D accéléré. Il offre une abstraction du bureau, de ces éléments et des médias qui y sont présents. Si XAML est lié très fortement a Avalon nativement ou via des extensions promues par Microsoft, il y a de forte chance que nous devrions implémenter Avalon pour pouvoir être parfaitement compatible avec les "interfaces web" l'utilisant.
1. Tu ne repons pas a sa question
2. J'ai donné juste un exemple, je n'ai jamais dit que c'etait prévu. Mais l'informatique se dirige de plus en plus vers ce genre de chose et c'est juste un exemple pour montrer concretement ce dont est capable XAML.
[^] # Re: Courbevoie
Posté par Anonyme . En réponse au journal Attention ça va couper. Évalué à 7.
Je soutiens entierement leur action, sauf quand c'est n'importe quoi. Le probleme, c'est qu'ils mettent des vie en danger, et je trouve ca inadmissible : Rendre la signalisation HS le matin, couper les hopitaux, supprimer l'eclairage publique en pleine nuit, sans oublier certains particuliers soignés a domicile qui n'ont pas de generateur de secours. L'electricité n'est pas qu'un confort, elle est vitale pour de nombreuses personnes, c'est cet argument qu'ils avancent, et pourtant on peut se demander s'ils l'ont vraiment tous compris ...
[^] # Re: Courbevoie
Posté par Anonyme . En réponse au journal Attention ça va couper. Évalué à 2.
[^] # Re: Courbevoie
Posté par Anonyme . En réponse au journal Attention ça va couper. Évalué à 9.
[^] # Re: Courbevoie
Posté par Anonyme . En réponse au journal Attention ça va couper. Évalué à 0.
Oui mais faire la grevene doit pas empecher les autres de travailler.
[^] # Re: "moteur 2D" dit le titre de l'article
Posté par Anonyme . En réponse au journal moteur graphique 2D. Évalué à 1.
http://cairographics.org/(...)
Cairo is a vector graphics library with cross-device output support. Currently supported output targets include the X Window System, in-memory image buffers, and PostScript. An OpenGL backend is in progress, and PDF file output is planned. Cairo is designed to produce identical output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension).
[^] # Mouai ;)
Posté par Anonyme . En réponse au journal moteur graphique 2D. Évalué à 5.
1. Le ZBuffer est utilisé en hard et en soft, c'est le seul moyen efficace et facilement "cablabe" pour afficher les faces dans le bon ordre.
2. Le BSP, comme les octree, portals et compagnie consiste a diminuer le nombre de polygonne a envoyer a la carte graphique.
Pour mieux comprendre on va prendre un exemple.
On a une scene composée de polygonne que l'on desire afficher, pour cela il nous faut determiner quels sont les polygonnes cachant les autres et figurant devant l'observateurs. Il existe plusieurs techniques : le ZBuffer et le raytracing sont les plus utilisés.
Si cette scene est composée d'un milion de polygonnes on va faire tourner ces algorithmes sur cet ensemble, ce qui n'est pas tres efficace, car il est possible de reduire celui-ci a l'avance. Cette reduction prend en compte la position de l'observateur et determine les polygonnes qui ne seront jamais visibles.
Ce choix peut etre :
- arbitraire : en bornant volontairement le champ de vision (clipping)
- logique : dans les scenes indoor, il est inutile d'envoyer a la carte graphique les polygonnes des pieces ou l'observateur n'est pas present (principe "simplifié" des portals)
- basé sur une repartition spatiale des polygonnes : en classant les polygonnes par zones dans des arbres (Octree, BSPTree, KD-Tree, ...)
Que ce soit en soft ou en hard, ces techniques peuvent etre utilisées conjointement. Ce qui est le cas de Quake. De plus le ZBuffer et derivé sont systematiquement utilisés car ce sont les seules techniques a etre aussi efficaces, polyvalentes et independantes de la scene. Dans l'avenir on se dirigera progressivement vers des methodes hybrides raytracing/zbuffer puis 100% raytracing. Ce qui est un juste retour aux choses, car les tous premier moteurs (Wolfenstein, doom I et II, ...) etaient basés sur un algorithme de raytracing (extremement) simplifié ;)
Sinon pour repondre aux questions de sylvain, les jeux et applications utilisant un moteur 3D basé sur OpenGL exploiteront la bibliotheque openGL installée sur ta config. Si tu possedes une carte 3D et que les drivers du constructeurs sont installé, OpenGL pourra etre vue comme l'interface entre le moteur 3D applicatif et la partie hardware de la carte 3D. Si aucune carte n'est installée, une autre implémentation sera utilisée effectuant tous les calculs en soft (Mesa generallement).
Pour SDL, il ne faut pas tout melanger ;) SDL est une couche d'abstraction du materiel permettant d'acceder de maniere simple a des zones de la memoire video, aux fonctionnalités audios, thread, communication, ... independament de la plateforme. SDL ne sait pas faire de 3D et n'utilise donc pas de zbuffer. Par contre, il est possible d'utiliser ces zones de memoires videos pour l'affichage de scene OpenGL ou le calcul du ZBuffer.
Voili voilou ! mes 2c !
[^] # Re: Gné ?
Posté par Anonyme . En réponse au journal Towel Day. Évalué à 2.
[^] # Re: Comparez ce qui est comparable bon sang !!! ;)
Posté par Anonyme . En réponse au journal OpenOffice.org a la rescousse. Évalué à 2.
Oui tout a fait. Je voulais juste preciser et justifier dans mes commentaires precedents pourquoi un fichier word est plus gros qu'un fichier OOo et casser le mythe comme quoi word enregistre un peu n'importe quoi pour faire plaisir aux vendeurs de disque dur en augmentant artificelement la taille des fichiers* ;)
Je voulais aussi ajouter que le code et l'architecture de ce genre d'applis sont tres couplés a ce type de format de fichier. Ce qui est moins le cas pour le XML ou les données et le code applicatif sont parfaitement séparés.
C'etait ces deux points qui font que pour moi ce n'est pas vraiment comparable car il ne s'agit pas d'implementations differentes mais bien d'architecture differente.
Et malheureusement ce ne sont pas vraiment deux bout de code qui ont la meme finalite : la portée est plus grande et les conséquences pour le developpeur plus lourdes. Par contre pour l'utilisateur, et au final c'est ce qui est le plus important, c'est tout a fait comparable.
* Quoique ce manque de transparence empeche evidement de connaitre la nature exacte des données enregistrées ...
[^] # Re: Comparez ce qui est comparable bon sang !!! ;)
Posté par Anonyme . En réponse au journal OpenOffice.org a la rescousse. Évalué à 2.
Ce choix est criticable, mais les avantages pour eux sont nombreux : pas de transparence (=> reverse enginering difficile), le modele objet applicatif est caché (=> la propriété industrielle sur l'architecture du logiciel n'est pas devoilée), le modele par composants leur assure un format de fichier facilement étendable (qui permet d'inclure d'autres composants par exemple) ou le chargement partiel d'un fichier.
Ceci dit, tout ce que je viens de dire est tout a fait envisageable en XML ;)
Et pour revenir a mon exemple entre un binaire java et un binaire standard c'est exactement la meme chose, le binaire java, meme s'il est plus gros aura l'avantage d'etre portable. Tout ceci est donc un compromis entre les fonctionnalités offertes par un format et finallement le poids du fichier lui meme.
Finallement, je ne pense pas que la taille d'un fichier soit vraiment porblematique mais plutot le fait qu'il ne soit pas libre et ouvert.
[^] # Re: Comparez ce qui est comparable bon sang !!! ;)
Posté par Anonyme . En réponse au journal OpenOffice.org a la rescousse. Évalué à 1.
Oui et non, pour l'utilisateur c'est effectivement comparable, mais d'un point de vue developpeur la difference est plus importante, puisque les fonctionnalités ne sont pas les memes (duplication des donnees entre autre, meme si elle n'est pas parfaitre ;). Ce serait comme si tu comparais la taille d'un executable java (son bytecode) et celui d'un binaire standard.
De plus, d'apres ce que tu m'en dit, le format de fichier OOo a l'air vachement plus propre que celui de Word.
Ya pas photo ! Plus propre, plus souple, facilement étandable, et surtout plus stable : une erreur dans le fichier n'est pas dramatique (un decalage de byte par exemple) au pire on dezip, on ouvre le fichier et on regarde ou est l'erreur de syntaxe pour la corriger. Au mieux, des outils automatiques sont deja disponibles. Pour Word, il faut prier pour que l'historique ou que la duplication des données soit presente et surtout valide ...
# Comparez ce qui est comparable bon sang !!! ;)
Posté par Anonyme . En réponse au journal OpenOffice.org a la rescousse. Évalué à 5.
Le format de fichier utilisé par word n'a rien a voir avec celui utilisé par OpenOffice : OOo utilise XML et compacte le tout, word est un format binaire "proche" d'un dump memoire (en fait, il s'agit de la collection d'objets au sens POO qui sont dumpé dans le fichier, c'est similaire a de la serialization). De plus ce mecanisme implémente des fonctionnalitées de tolerance de panne en duplicant les données par exemple ou en maintenant un historique des modifications. Il est donc évident que le fichier obtenu soit plus gros.
[^] # A oui ca c'est un gros coup de vieux
Posté par Anonyme . En réponse au journal les XP sont invisibles. Évalué à 1.
Le champagne ! Le champagne ! Le champagne !
# MS-Vapoware 2006 will be released later.
Posté par Anonyme . En réponse au journal MS-Vapoware 2006 will be released later.. Évalué à 1.
Cette info est vraie et a deja été relayée par d'autres sites de news (OsNews, clubic Huuummm ;) ...). La principale limitation concerne le support reseau je crois.
Sinon, j'ai lu que Microsoft voulait "coopérer" avec des projets libres tels que Mozilla, pour parfaire leur integration dans Longhorn. Je pense que leur demande consiste a integrer certaines de leur technologie (support de WinFS par exemple) dans ces logiciels libres. Cette news etait parues sur OSNews mais je ne la retrouve plus.
[^] # Re: Warning....
Posté par Anonyme . En réponse au journal Microsoft Et l'OpenSource.... Évalué à 0.
[^] # Re: Warning....
Posté par Anonyme . En réponse au journal Microsoft Et l'OpenSource.... Évalué à 1.
[^] # Re: Warning....
Posté par Anonyme . En réponse au journal Microsoft Et l'OpenSource.... Évalué à 2.
LOGICIEL LIBRE C OPEN SOURCE
Bon a part ca je pense qu'ici ils vont bien parler de logiciel libre :
Qu'est-ce que l'Open Source, les types de licences GPL, LGPL, BSD... ?
et ne pas se limiter a l'OSI ou le programme Shared source de Microsoft.
[^] # Re: Pas clair ?
Posté par Anonyme . En réponse au journal Reflexion sur les licences libres (suite). Évalué à 1.
Prendre QT sous licence GPL suffit pour compiler les kdelibs. Par contre l'ensemble QT+KdeLibs est sous GPL. Si tu veux faire une application closed-source basée sur KdeLibs, tu es obligé d'acheter une licence de QT commerciale pour pouvoir exploiter la licences LGPL des KDELibs.
KDE a du payé des kits de dev à Qt, mais peuvent distribuer leur produit comme ils veulent.
Je ne pense pas que ce soit le cas car LGPL et GPL sont compatibles. La licence commerciale n'est donc pas obligatoire. De plus le prix d'une licence est tres elevé et limitée a un developpeur. Et finallement, si ce que tu dis est vrai, cela signifie que les KdeLibs ne pourraient pas etre distribuée sous forme de source car une licence commerciale de QT serait necessaire pour tout compiler.
[^] # Re: Une question
Posté par Anonyme . En réponse au journal Reflexion sur les licences libres (suite). Évalué à 1.
:
http://www.gnu.org/licenses/why-not-lgpl.html(...)
[^] # Re: Une question
Posté par Anonyme . En réponse au journal Reflexion sur les licences libres (suite). Évalué à 2.
Dans la "vraie vie", je pense que ce sera le cas (licence commerciale specifique), car la boite, a moins d'etre altruiste, doit toujours vouloir vendre sa lib pour faire de l'argent.
[^] # Re: Pas clair ?
Posté par Anonyme . En réponse au journal Reflexion sur les licences libres (suite). Évalué à 2.
Many of the most common open source licenses, such as the original MIT/X license, the new BSD license, and the LGPL, are "GPL-compatible". That is, their code can be combined with a GPL'ed program without conflict (the new combination would have the GPL applied to the whole).
http://en.wikipedia.org/wiki/GNU_General_Public_License(...)
La licence qu'il faut donc considérer est la licence la plus "forte" parmie toutes les licences "compatibles" utilsées par les bibliotheques liées (Ouuf ;) Ce que tu illustres donc parfaitement. Le probleme que j'ai donc soulevé dans mon journal n'est pas valide car B sera sous licence GPL (et non LGPL comme je l'affirmais)
Par contre cela implique un point que j'avais soulevé dans mon journal précédent : Il est necessaire de connaitre l'ensemble des licences des bibliotheques, meme celles dont on est dependant indirectement, car, toujours dans le cas des KDElibs, celles-ci sont sous LGLP, mais dans la pratique c'est du GPL, car QT lui est sous GLP. Bon enfin je me comprends ;)
Faudrait un outil automatique qui determine automatiquement les licences possibles d'une appli en fonction de ses libs ;)
# Un quizz sur les licences
Posté par Anonyme . En réponse au journal Reflexion sur les licences libres (suite). Évalué à 1.
Sinon j'avais vu, il y a quelques années, un quizz/QCM d'une dizaine de questions sur les licences avec differents cas "limites". Si quelqu'un a le lien ca m'interesse.
[^] # Re: Pas clair ?
Posté par Anonyme . En réponse au journal Reflexion sur les licences libres (suite). Évalué à 1.
* une bibliothe GPL ne peut pas etre liee a une bibliotheque LGPL
# Voir la télé en plein écran...
Posté par Anonyme . En réponse au journal voir la télé en plein écran.... Évalué à 2.
A verifier, certaines cartes graphiques ne supportent pas l'overlay en mode twin view. D'autres le supporte mais uniquement sur le primary display. Regarde dans ta doc, google ou essaie sous windows pour voir si le comportement est identique.
[^] # Re: essai
Posté par Anonyme . En réponse au journal Quelqu'un peut m'expliquer clairement ce qu'est la technologie Avalon ?. Évalué à 2.
Avalon n'est pas qu'un systeme de composition 2D accéléré. Il offre une abstraction du bureau, de ces éléments et des médias qui y sont présents. Si XAML est lié très fortement a Avalon nativement ou via des extensions promues par Microsoft, il y a de forte chance que nous devrions implémenter Avalon pour pouvoir être parfaitement compatible avec les "interfaces web" l'utilisant.
[^] # Re: essai
Posté par Anonyme . En réponse au journal Quelqu'un peut m'expliquer clairement ce qu'est la technologie Avalon ?. Évalué à 1.
2. J'ai donné juste un exemple, je n'ai jamais dit que c'etait prévu. Mais l'informatique se dirige de plus en plus vers ce genre de chose et c'est juste un exemple pour montrer concretement ce dont est capable XAML.