Mais OOOOUUUUIIIIII. D'ailleur 80 % des projets ont au moins la taille d'evolution.
Et alors, ai je parler de taille de code ?
Je parlait en terme d'impact, d'applis qui feront que le libre marchera (suites office, logiciel de communication/gestion intranet, grosse applications metiers)
et la actuellement dans le libre il y en a tres peu.
Alors pour toi kdevelop est un gros projet et evolution, galeon, gnucash de petit projet.
kdevelop oui, car il un IDE de ce niveau ca commence a devenir ce qu'un developeur logiciel (et un gestionnaire de projets) attend.
Pour evolution je pense qu'il est sur la voie de devenir un bon logiciel de "workflow" (le nom est pas terrible mais comme lotus ou exchange quoi) meme si, perso, je trouve qu'il a qques lacunes assez genante (que n'ont pas l'ensemble kmail/korganiser/kontact du cvs kde)
Voyons ça. Ma référence, les src.rpm d'une distribution redhat 9 :
- galeon : 3.9M
- kdevelop : 6.6M
- gnucash : 8.2M
- evolution : 13M
Comme dit plus haut ce n'est pas la taille du code qui fait une grande appli.
Car a ce moment selon les chiffres, le notepad de microsoft serait une appli qui "ecrasereait" ton galeon.
Ajoutons dans le projets plus gros que kdevelop :
- gnumeric
- abiword
- gimp
Ai je dit que gnumeric ou abiword etaient moins "gros" que kdevelop. Connait tu le sens du mot "exemple".
Super, tu est heureux quand une appli mal concue depasse les centaines de milliers de lignes alors qu'elle devrait a peine en faire une dizaine ?
Je doute. Celà veut dire :
1- KDE propose un wrap pour tout les fonctions/types de Qt (j'en doute grave).
2- Il suffit de faire un wrap d'une librairie GPL (même un wrap très sommaire, en se limitant à des changement de noms des fonctions/type/constantes) pour inhiber une licence GPL d'une librairie.
1- Non pas vraiment, mais kde fournit une API de plus haut niveau ce qui evite, en general, de faire du Qt bas niveau. Donc de linker explicitement avec Qt
2- Oui tu peut le faire, et meme mieux tu peut meme avoir les memes noms de fonctions,etc... a condition que tu reecrive tout from scratch. Par contre tu dois sortir ton code sous une licences GPL compatible.
Le meme principe est utiliser par Linux: noyau GPL, libc LGPL, applis Proprios
Ou wine: wine core libs GPL, wine ext libs LGPL, applis Proprios
Il faut juste faire super attention aux conditions de links
[^] # Re: Good and bad news
Posté par Raphael Junqueira . En réponse à la dépêche qt3 sur windows, une version GPL ?. Évalué à 1.
Et alors, ai je parler de taille de code ?
Je parlait en terme d'impact, d'applis qui feront que le libre marchera (suites office, logiciel de communication/gestion intranet, grosse applications metiers)
et la actuellement dans le libre il y en a tres peu.
Alors pour toi kdevelop est un gros projet et evolution, galeon, gnucash de petit projet.
kdevelop oui, car il un IDE de ce niveau ca commence a devenir ce qu'un developeur logiciel (et un gestionnaire de projets) attend.
Pour evolution je pense qu'il est sur la voie de devenir un bon logiciel de "workflow" (le nom est pas terrible mais comme lotus ou exchange quoi) meme si, perso, je trouve qu'il a qques lacunes assez genante (que n'ont pas l'ensemble kmail/korganiser/kontact du cvs kde)
Voyons ça. Ma référence, les src.rpm d'une distribution redhat 9 :
- galeon : 3.9M
- kdevelop : 6.6M
- gnucash : 8.2M
- evolution : 13M
Comme dit plus haut ce n'est pas la taille du code qui fait une grande appli.
Car a ce moment selon les chiffres, le notepad de microsoft serait une appli qui "ecrasereait" ton galeon.
Ajoutons dans le projets plus gros que kdevelop :
- gnumeric
- abiword
- gimp
Ai je dit que gnumeric ou abiword etaient moins "gros" que kdevelop. Connait tu le sens du mot "exemple".
Puis regardes : http://ftp.rhnet.is/pub/redhat/linux/9/en/os/i386/SRPMS/(...(...)) . Même galeon qui est le plus petit cité est dans les 25 % plus gros projet (il y a 75 % de projet plus petit).
Super, tu est heureux quand une appli mal concue depasse les centaines de milliers de lignes alors qu'elle devrait a peine en faire une dizaine ?
Je doute. Celà veut dire :
1- KDE propose un wrap pour tout les fonctions/types de Qt (j'en doute grave).
2- Il suffit de faire un wrap d'une librairie GPL (même un wrap très sommaire, en se limitant à des changement de noms des fonctions/type/constantes) pour inhiber une licence GPL d'une librairie.
1- Non pas vraiment, mais kde fournit une API de plus haut niveau ce qui evite, en general, de faire du Qt bas niveau. Donc de linker explicitement avec Qt
2- Oui tu peut le faire, et meme mieux tu peut meme avoir les memes noms de fonctions,etc... a condition que tu reecrive tout from scratch. Par contre tu dois sortir ton code sous une licences GPL compatible.
Le meme principe est utiliser par Linux: noyau GPL, libc LGPL, applis Proprios
Ou wine: wine core libs GPL, wine ext libs LGPL, applis Proprios
Il faut juste faire super attention aux conditions de links