Packager des binaires pour Mac - Page 2

Folco (./26) :
"Nan mais les gars, faut utiliser les fonctions de windows.h pour vos menus de jeux en gris, c'est built-in et ça respecte le look&feel natif de la plateforme voyons" ~(c).

C'est menus.h.

C'est pas pareil sur PC/Mac ?

Qt respecte le look&feel de la plateforme, GTK+ fait de son mieux pour ça aussi (mais pour OS X, il faut utiliser le portage Cocoa, qui du coup va mal aller avec le KDE 3 utilisant X11 nécessaire pour le support de DCOP dans TiEmu qui est nécessaire pour KTIGCC 1 - bref, il vaut mieux utiliser du X11 partout en attendant au moins KTIGCC 2).

Et l'argument de la place n'est pas aussi important sur un ordinateur, ce n'est pas une calculatrice, les ordinateurs ont d'énormes disques durs.

kim (./28) :
je n'ai pas internet.

Il est là le problème, pas la peine de chercher plus loin.

Qui n'est d'ailleurs pas hébergé sur le même serveur que le tien, si ? Et qu'est-ce qu'il se passe si, ho, juste comme ça, le serveur de l'appli manquante, tombe en rade, ou simplement, n'existe plus ?

On me le signale et je pointe l'installeur sur un autre miroir.

Mais c'est clair que c'est mieux sous Fedora, où les dépendances sont dans le dépôt central et si le miroir tombe en panne, yum utilisera automatiquement le prochain. Pourquoi OS X n'est-il pas capable de marcher de cette manière? OS X est clairement technologiquement inférieur.

Il te manque quoi concrètement ? C'est marrant comme toute discussion avec toi semble toujours tourner à une confrontation là où on ne te demande pas de chercher à comprendre, mais de simplifier les choses quand c'est possible... Il te manque quoi sous osx, que tu as sous windows par exemple ?

Il me manque, sous OS X autant que sous W32, des libs multiplateforme préinstallées et/ou disponibles dans un dépôt central et installées automatiquement (en présupposant Internet, évidemment - ça fait partie de la configuration minimum de nos jours!) quand on installe un logiciel les utilisant, genre GTK+, Qt, kdelibs, libusb etc. Et W32 sux sur ce point autant que OS X. C'est GNU/Linux la plateforme idéale!

Si tu voulais du vrai multiplateforme, tu aurais utilisé java

Et ce n'était pas libre à l'époque où KTIGCC a été écrit (et il me semble que IcedTea ne compile toujours pas sous OS X, d'ailleurs), donc pas un choix possible.
Et puis Swing est pénible et lent, et si j'utilise Qt Jambi, ça ne va pas arranger les choses.

ou le moteur derrière firefox (dont le nom m'échappe, faut pas m'en vouloir, il est tard).

XUL. Mais il n'est pas du tout fait pour ça.

Ou .net, tiens...

Et les WinForms ne sont que mal gérés sous Mono, et si j'utilise du Mono avec du GTK# ou du Kimono/Qyoto (les bindings KDE et Qt pour le C#), ça ne va rien changer par rapport à la situation actuelle.

Il se trouve que pour pas mal d'éléments d'osx, il existe des alternatives.... Qui tourne même sous linux, par exemple

Mais aucunes ne répondent aux demandes.

C'est le rôle du packageur de fournir la solution.

Non, c'est le rôle de l'OS. L'OS ne le fait pas, donc il sux.

Si je te dis qu'une solution est possible avec un simple pkg, c'est qu'il y en a. X11 par exemple, va t'installer, ô surprise, des .so dans /usr/lib (de mémoire, pour le répertoire), de la conf dans /etc/X11..., fou non ? Et il se trouve même que OpenOffice.org en version 2 était même capable de la même "prouesse" à une époque. Il savait quand X11 était là ou pas, donc il bloquait l'installation.

Résolution des dépendances automatique = installer automatiquement X11. Si ce n'est pas possible à cause de la licence de l'implémentation de X11, c'est encore un point sur lequel OS X sux.

Au premier lancement, il allait chercher sagement les fonts systèmes dont il avait besoin, etc. Rien n'est impossible, c'est le boulot du dev & du packageur de fournir une solution.

Non, c'est le rôle de l'OS. L'OS ne le fait pas, donc il sux. GNU/Linux le fait très bien.

Il existe même des systèmes de packages qui gèrent les dépendances etc.

Fink? Ça a déjà été cité, je sais bien que ça existe, relis mon post en entier.

Tiens, un truc qui peut t'intéresser (ou pas), vu que tu ne connais pas *du tout* le monde mac : cherche i-installer par exemple...

->

i-Installer is unsupported software as of Jan 1, 2007.
[snip]
Bug reports can still be sent to me, but you will not get a reaction and it is uncertain if and when I will be paying attention to them. If it is something that does work for me (and thus something with your particular setup, I will most likely not pay any attention to them).
[snip]
i-Installer code is not particularly good. This is the result of the fact that it has been written as a pilot-project-gone-awry in combination with the fact that certain aspects of the environment (Mac OS X) played foul with my original architecture ideas (it just did not work at that time). Mac OS X has improved since, but i-Installer would have to be rewritten to benefit. That is only going to happen if I win the lottery and do not have to work for al living anymore...

Pas très prometteur, ce truc.

que dire. Un logiciel ne pourra jamais être aussi bon qu'avec des libs natives.

Alors vas-y, code-nous un EDI équivalent à KTIGCC, avec la même interface et tout, utilisant Cocoa.
Je n'ai jamais dit que ce n'était pas bienvenu (même si ça ne sera certainement pas l'EDI officiel étant donné que je ne peux pas le maintenir et que mon but est d'avoir le même code partout, ce qui se rapproche enfin de la réalité grâce à KDE 4).

Ca vaut pour macos, tout autant que pour linux (firefox sur kde, c'est un peu un contre sens d'une certaine manière, par exemple), et sous windows (gtk/kde sous windows). Et si l'application est pensée pour le multiplateforme dès le départ, changer de toolkit (de gtk à kde à autre) devrait être un jeu d'enfant.

C'est un mythe, ça. Romain a essayé le multi-frontend pour TiLP, il a laissé tomber parce que ce n'était pas maintenable, donc c'est repassé à GTK+ partout.

Note qu'il me semble qu'on n'a *jamais* parlé des makefiles des projets individuels... On n'a jamais causé d'utilisateurs qui vont aller jouer avec as dans leur makefile.Juste que tu déconseilles une personne voulant faire un IDE par dessus tigcc, d'utiliser les mêmes méthodes que ktigcc par exemple, c'est à dire, passer par gcc, as, ld-tigcc etc. Et je trouve que cet avis est pour moi une erreur. Il n'y a aucune raison pour qu'un tel IDE n'ait pas à le faire, si les specs/docs sont là, et sont claires, maintenues..., alors à chaque changement, il suffit de reporter les modifs qui vont bien. Encore une fois, c'est le rôle du mainteneur...

Une fois de plus, si l'EDI utilise ces trucs, ça passe encore tant que l'EDI est mis à jour si TIGCC change (mais c'est le rôle du mainteneur de l'EDI de se rendre compte de ces changements, pas le mien). C'est dans les makefiles perso que ça me dérange. Mais utiliser tigcc est plus sûr même pour les EDIs.

Tu sais, Gimp, sous mac, n'a jamais percé, pour plusieurs raisons :
* il lui faut X11. (ca a été longtemps un frein pour OpenOffice.org), meme si ça s'installe avec le dvd fourni avec l'os...
* il lui faut gtk, qui n'est pas natif, et qui ne s'integre pas à mac os.
* il est long à charger, parce qu'il n'utilise pas du natif (pareil pour OOo)* les packageurs de gimp n'ont je crois jamais compris que créer un framework, ou simplement, faire un pkg qui installe un bout en sys, et le reste sur l'app, leur permettait de proposer des package standalone en meme temps que des packages d'upgrade...

Ben, si vous ne voulez pas d'une application portable, c'est votre problème, mais alors ne venez pas râler qu'il n'y a soi-disant pas de version Mac, il y en a une, mais vous ne la voulez pas.

Conseil d'amis: si vous avez des projets créatifs et/ou hors du commun, faites les sans en parler, puis publiez les. Vous éviterez ainsi un temps précieux en batailles verbales inutiles avec Kevin.

En même temps, ça en prend plus que ça pour me décourager...

./32 : pas faux

allez, un pti dernier pour la route

Kevin Kofler (./31) :
Il est là le problème, pas la peine de chercher plus loin.

Oui, je sais que le problème vient de là, simplement, elle montre une des limites de ton type d'install.

Kevin Kofler (./31) :
Pourquoi OS X n'est-il pas capable de marcher de cette manière? OS X est clairement technologiquement inférieur.

Non, c'est que OOo avait fait le choix de ne pas forcer l'utilisation d'un X11 par rapport à un autre, donc il laissait le choix : celui de macports, celui de fink, ou celui d'osx, à l'utilisateur de faire l'installation.

Kevin Kofler (./31) :
Non, c'est le rôle de l'OS. L'OS ne le fait pas, donc il sux.

Non, ce n'est pas le rôle de l'OS. L'OS te propose une solution, si elle ne te plait pas, c'est pas son problème, l'avantage ici, c'est qu'osx étant un unix, il donne plus de facilités que windows pour s'adapter...

Kevin Kofler (./31) :
Pas très prometteur, ce truc.

parce que l'utilité de ce truc est sous osx, très limitée. Je sais très bien que c'est plus maintenu, si ça avait été utile, c'est sous licence BSD, tout le monde peut reprendre le projet. Si ça n'a pas été fait, c'est que c'est pas utile.

ps pour killerX : je sais pas si tu connais/si tu as, mais tu peux jeter un oeil du côté des bundle pour textmate (éditeur non libre, pas gratuit, mais f*****g génial), sinon on doit pouvoir faire le même genre de chose et intégrer tigcc à xcode directement, ce qui simplifierait énormément, pas besoin d'IDE spécifique, on prend celui du système

./12: en ligne de commande, il n'y a pas que `tigcc`, il y a aussi `tprbuilder`.

kim (./34) :
Oui, je sais que le problème vient de là, simplement, elle montre une des limites de ton type d'install.

Ben, on est en 2008, Internet est quasiment omniprésent.

Non, c'est que OOo avait fait le choix de ne pas forcer l'utilisation d'un X11 par rapport à un autre, donc il laissait le choix : celui de macports, celui de fink, ou celui d'osx, à l'utilisateur de faire l'installation.

Mouais... Il reste le fait que c'est peu pratique par rapport à un GNU/Linux où je fais yum install openoffice.org-\* et il m'installe toutes les dépendances automatiquement, y compris X11 si ça n'y est pas encore (enfin, du moins les libs qui servent pour un ssh -X - mais sur un système de bureau, X11 est déjà préinstallé évidemment, on ne vous met pas un environnement propriétaire et non portable, nous!).

Et le fait qu'il y a plusieurs implémentations montre que le système manque d'intégration. Sous Fedora, j'ai X.Org X11 et il fait partie intégrale du système.

Kevin Kofler (./31) :
Non, c'est le rôle de l'OS. L'OS ne le fait pas, donc il sux.

Non, ce n'est pas le rôle de l'OS.

Pourtant GNU/Linux le fait. Donc OS X est moins bien que GNU/Linux cqfd.

L'OS te propose une solution, si elle ne te plait pas, c'est pas son problème

Justement il n'en propose pas. Il n'y a rien de comparable à apt ou yum dans OS X.

l'avantage ici, c'est qu'osx étant un unix, il donne plus de facilités que windows pour s'adapter...

Oui, il y a des systèmes comme Fink et MacPorts qui font leur possible pour combler les lacunes profondes de OS X. Malheureusement la plupart du temps ça se base sur les sources, pas les binaires (Fink a des binaires (.deb), mais pas à jour, MacPorts est entièrement basé sur les sources, une tentative de faire des RPMs n'a jamais été complétée), donc ce n'est pas très pratique. Sous la plupart des distributions GNU/Linux, la résolution des dépendances se fait sur les binaires, donc on ne perd pas son temps à recompiler ce qu'on n'a pas modifié.

Kevin Kofler (./31) :
Pas très prometteur, ce truc.

parce que l'utilité de ce truc est sous osx, très limitée. Je sais très bien que c'est plus maintenu, si ça avait été utile, c'est sous licence BSD, tout le monde peut reprendre le projet. Si ça n'a pas été fait, c'est que c'est pas utile.

Donc si un logiciel n'est pas maintenu, c'est que toute l'idée derrière ne sert à rien? DOS (la version originale - je sais qu'il y a FreeDOS) n'est pas maintenu, donc un système d'exploitation ne sert à rien? VTI n'est pas maintenu, donc un émulateur de calculatrices TI ne sert à rien? C'est vraiment n'importe quoi ce raisonnement.

kim (./35) :
ps pour killerX : je sais pas si tu connais/si tu as, mais tu peux jeter un oeil du côté des bundle pour textmate (éditeur non libre, pas gratuit, mais f*****g génial), sinon on doit pouvoir faire le même genre de chose et intégrer tigcc à xcode directement, ce qui simplifierait énormément, pas besoin d'IDE spécifique, on prend celui du système

Une adaptation d'un EDI qui n'a pas été développé spécifiquement pour TIGCC sera forcément inférieur à KTIGCC. Pas de compatibilité des fichiers projet avec d'autres plateformes, interface totalement différente des autres plateformes (et de toute la documentation) et manque d'intégration. Cf. les autres topics où ça a été proposé.

Et s'il faut payer pour utiliser la solution que tu proposes, ça sux carrément.

Lionel Debroux (./36) :
./12: en ligne de commande, il n'y a pas que `tigcc`, il y a aussi `tprbuilder`.

tprbuilder n'est utilisable qu'en conjonction avec un EDI (et l'utilité est très limitée maintenant qu'il y a des EDIs partout - ça a été écrit pour pouvoir compiler des projets TIGCC IDE sous *nix quand il n'y avait pas encore KTIGCC - bref, tprbuilder est déprécié). Il ne doit y avoir que toi à écrire des .tpr à la main, le format n'est pas du tout fait pour.

`tprbuilder` est déprécié alors qu'il permet de faire des choses que ne permet pas KTIGCC, comme par exemple être scripté ? J'aime bien cette notion de "déprécié"

Je sais que tu as déjà proposé de rendre scriptable KTIGCC (plus exactement, KTIGCC 2, mais celui-là ne m'est d'aucune utilité, parce que la distro que j'utilise, basée sur ce qui deviendra bientôt Debian stable, ne proposera pas KDE 4.x avant un temps certain), mais je pense qu'il y a plus urgent que ça à faire dans TIGCC...

Kevin Kofler (./37) :
Et s'il faut payer pour utiliser la solution que tu proposes, ça sux carrément.

Xcode est sur tous les cd d'installation d'OS X... et est téléchargeable gratuitement sur le site d'apple...

Kevin Kofler (./25) :
Un logiciel portable utilise des bibliothèques portables, évidemment. Le problème est que OS X ne propose d'office en grande partie que des libs propriétaires et monoplateformes, évidemment ces libs ne sont pas exploitables dans les applications multiplateformes.

Heu... OpenGL, libxml2, libxslt, libZ, libm, libtcl, libssl, libexpat, libcrypto, libcups, libpam, libbz2, OpenAL, libicu, GLUT et plein d'autre que je passe... C'est proprio ça ? et bien sur monoplateforme ?

kim (./28) :
* les packageurs de gimp n'ont je crois jamais compris que créer un framework, ou simplement, faire un pkg qui installe un bout en sys, et le reste sur l'app, leur permettait de proposer des package standalone en meme temps que des packages d'upgrade...

Et l'utilisation de package permet aussi une desinstallation propre !

Kevin Kofler (./31) :
Qt respecte le look&feel de la plateforme

Heu, réponse TRES courte : NON

Kevin Kofler (./31) :
qui du coup va mal aller avec le KDE 3 utilisant X11

Kevin Kofler (./31) :
Et l'argument de la place n'est pas aussi important sur un ordinateur

Heu, c'est pas toi qui 20 posts avant gueulais sur les applications qui font "plusieurs Go" ?

Kevin Kofler (./25) :
Ben, c'est une résolution automatique des dépendances, sous-optimale parce que c'est l'installeur qui doit faire tout le boulot alors que ça devrait être le système d'exploitation

Kevin Kofler (./31) :
Il est là le problème

Kevin Kofler (./31) :
Non, c'est le rôle de l'OS. L'OS ne le fait pas, donc il sux.

Kevin Kofler (./37) :
Pourtant GNU/Linux le fait.

Ha oui ? Linux le fait ? Il me semblait que c'était une application, genre apt, yum, emerge...

Bizzare si c'est Linux (le kernel hein) qui fait ça, pourquoi c'est pas standardisé ?

Franchement, arrête de dire des conneries plus grosse que l'Himalaya...

Kevin Kofler (./31) :
C'est un mythe

Du tout, il y a pas mal d'exemples du contraire...

Lionel Debroux (./38) :
`tprbuilder` est déprécié alors qu'il permet de faire des choses que ne permet pas KTIGCC, comme par exemple être scripté ? J'aime bien cette notion de "déprécié"

Bah, ça ne sert à rien de scripter la compilation, c'est un clic dans l'EDI. Et tu sais déjà ce que je pense du système des 2n binaires (n étant le nombre de traductions) employé par certains logiciels TICT.

Je sais que tu as déjà proposé de rendre scriptable KTIGCC (plus exactement, KTIGCC 2, mais celui-là ne m'est d'aucune utilité, parce que la distro que j'utilise, basée sur ce qui deviendra bientôt Debian stable, ne proposera pas KDE 4.x avant un temps certain)

On peut packager les libs KDE 4 sur un système basé sur KDE 3, cf. Fedora 8.

Mais les plans ont changé, KTIGCC 2 n'aura pas de nouvelles fonctionnalités, ce sera juste un portage KDE 4 (il me faut déjà trop de temps pour le compléter sans rajouter de nouvelles fonctionnalités), une fois ce portage sorti, je prévois une version 3 avec la portabilité W32 (remplaçant ainsi TIGCC IDE) et avec de nouvelles fonctionnalités (qui du coup seront exploitables sur les 2 plateformes en même temps).

KillerX (./39) :

Kevin Kofler (./37) :
Et s'il faut payer pour utiliser la solution que tu proposes, ça sux carrément.

Xcode est sur tous les cd d'installation d'OS X... et est téléchargeable gratuitement sur le site d'apple...

C'était en référence à cette partie:

kim (./35) :
mais tu peux jeter un oeil du côté des bundle pour textmate (éditeur non libre, pas gratuit, mais f*****g génial)

Je sais que Xcode est gratuit pour ceux ayant déjà payé leur licence de OS X. Mais il reste toutes les autres raisons pour lesquelles ça reste inférieur à un EDI dédié.

Kevin Kofler (./41) :
Je sais que Xcode est gratuit pour ceux ayant déjà payé leur licence de OS X. Mais il reste toutes les autres raisons pour lesquelles ça reste inférieur à un EDI dédié.

C'est vrai qu'un IDE bien pensé, ou tout es intégré, capable de gerer un GDB distant (ou local) le tout intégré dans l'IDE, qui fait tout ce que fait TIGCC-IDE et meme plus (et me parle pas du transfers vers VTI&co ou RTI, ça n'a rien d'impossible, bref, non XCode est loin d'être inférieur a un truc codé a l'arache en delphi et meme C++/Qt/KDE

Godzil (./40) :
Heu... OpenGL, libxml2, libxslt, libZ, libm, libtcl, libssl, libexpat, libcrypto, libcups, libpam, libbz2, OpenAL, libicu, GLUT et plein d'autre que je passe... C'est proprio ça ? et bien sur monoplateforme ?

J'ai dit "en grande partie", pas entièrement. Je sais qu'il y a ces libs, mais elles:
1. ne sont pas suffisantes, par exemple le seul widget toolkit là dedans est Tcl/Tk qui laisse pas mal à désirer,
2. ne sont pas toujours compatibles avec les applications existantes, par exemple certaines de ces libs sont repackagées dans des frameworks, et Tcl/Tk est une version non-X11 qui n'est pas forcément compatible avec les applications écrites pour la version X11, c'est une des raisons pour lesquelles Fink et MacPorts remplacent certaines de ces libs,
3. ne sont souvent pas à jour (une autre raison de les remplacer), en général les mises à jour ne sont disponibles qu'avec les mises à jour de OS X, qui sont payantes.

Le plus grand problème dans OS X est qu'ils ont réinventé la roue pour leur interface graphique au lieu d'utiliser X11, ça crée des tonnes de problèmes. Leur excuse était que X11 "ne permet pas" leurs histoires d'effets de transparence etc., mais KWin 4.x et Compiz prouvent le contraire. Et X11 permet des choses que Aqua ne permet pas, par exemple la transparence réseau (ssh -X).

kim (./28) :
* les packageurs de gimp n'ont je crois jamais compris que créer un framework, ou simplement, faire un pkg qui installe un bout en sys, et le reste sur l'app, leur permettait de proposer des package standalone en meme temps que des packages d'upgrade...

Et l'utilisation de package permet aussi une desinstallation propre !

C'est clair, mais c'est pour ça qu'il faut un système de packages avec une résolution de dépendances!

Kevin Kofler (./31) :
Qt respecte le look&feel de la plateforme

Heu, réponse TRES courte : NON

Montre-moi des captures de Qt 4 / Mac (pas Qt/X11) et explique-moi où le look&feel n'est pas correct. (Et tant que tu y es, explique-le aussi à la division Qt Software de Nokia, comme ça ils le corrigeront. )

Kevin Kofler (./31) :
qui du coup va mal aller avec le KDE 3 utilisant X11

-> Voilà pourquoi il nous faut le portage KDE 4 (KTIGCC 2).
Mais il me faudra des personnes motivées pour tester le tout avec Qt/Mac et KDE/Mac!

Kevin Kofler (./31) :
Et l'argument de la place n'est pas aussi important sur un ordinateur

Heu, c'est pas toi qui 20 posts avant gueulais sur les applications qui font "plusieurs Go" ?

La solution n'est pas de ne pas utiliser les libs, mais de les partager entre toutes les applications qui les utilisent, avec la résolution et installation automatique des dépendances.

Ha oui ? Linux le fait ? Il me semblait que c'était une application, genre apt, yum, emerge...

Bizzare si c'est Linux (le kernel hein) qui fait ça, pourquoi c'est pas standardisé ?

J'ai dit "GNU/Linux", c'est-à-dire le système entier!

Et le problème est que OS X ne propose même pas une solution propriétaire pour la résolution des dépendances, il n'en propose aucune. (Et je lis des absurdités comme "c'est au packageur de le faire", c'est n'importe quoi, c'est une fonctionnalité essentielle pour faire de bons paquetages et ça ne marche correctement que si c'est géré centralement - si chaque packageur réinvente la roue, c'est mal parti pour partager les libs entre les paquetages faits par différentes personnes. De plus c'est une perte de temps de devoir faire ça à la main quand l'OS pourrait le faire.)

Franchement, arrête de dire des conneries plus grosse que l'Himalaya...

Lis ce que j'ai écrit avant de critiquer! GNU/Linux != Linux.

Kevin Kofler (./31) :
C'est un mythe

Du tout, il y a pas mal d'exemples du contraire...

Lesquels? Firefox? Ça utilise une lib d'abstraction (XUL) qui simule les widgets natifs, justement tu n'en veux pas de ces libs.

Demande à Romain de raconter son expérience avec le multi-frontends. Ce n'est pas maintenable à long terme, il est beaucoup plus efficace d'utiliser une solution multiplateforme comme Qt ou GTK+.

Godzil (./42) :
C'est vrai qu'un IDE bien pensé, ou tout es intégré

Tu parles de TIGCC IDE / KTIGCC là?

capable de gerer un GDB distant (ou local) le tout intégré dans l'IDE

Et ça marche avec le GDB intégré à TiEmu, ce truc? Je te souhaite bonne chance...

KTIGCC lance le programme dans le débogueur graphique Insight intégré à TiEmu, on a un débogueur graphique en un clic. Je ne vois pas l'intérêt d'intégrer ça directement à l'EDI, Insight est génial comme interface.

qui fait tout ce que fait TIGCC-IDE et meme plus (et me parle pas du transfers vers VTI&co ou RTI, ça n'a rien d'impossible

Alors code-nous le plugin.
Et la complétion des identifiants de TIGCCLIB en utilisant les informations de la documentation, c'est possible aussi? (Si oui, je veux voir le code!) Et les options de TIGCCLIB et ld-tigcc dans les options du projet? (Idem.) Et l'enregistrement des fichiers dans le charset de la calculatrice, de façon à ce que les chaînes de caractères contenant des caractères accentués s'affichent correctement sur la calculatrice? (Idem.) Etc. (il y en a d'autres, de fonctionnalités comme ça). KTIGCC et TIGCC IDE sont entièrement pensés pour TIGCC, du début à la fin, on ne peut pas atteindre ce niveau d'intégration avec un EDI générique.

bref, non XCode est loin d'être inférieur a un truc codé a l'arache en delphi et meme C++/Qt/KDE

Le fanboy a parlé.

Et <SARCASM>merci</SARCASM> pour le "a l'arache" (sic).

c'est à l'arrache, t'as même eu la flemme de te passer de KDE (je déconne )

Kevin Kofler (./43) :
Et X11 permet des choses que Aqua ne permet pas, par exemple la transparence réseau (ssh -X).

VNC tu connais ?

Kevin Kofler (./43) :
avec une résolution de dépendances!

Aucun interet

./45:

(et oui a l'arache pour la simple raison que ton "KTIGCC" n'est qu"un portage 1:1 de l'IDE delphi qui est un foutoir infâme développé en dépits du bon sens)

Et tout le reste la réponse est oui c'est faisable. Ha aussi et ce n'est pas a l'IDE de faire la conversion du charset, mais bel et bien a gcc/ld

Kevin Kofler (./43) :
ça crée des tonnes de problèmes. Leur excuse était que X11 "ne permet pas" leurs histoires d'effets de transparence etc., mais KWin 4.x et Compiz prouvent le contraire

Ha oui aussi, si Apple avait attendu Kwin4/Compiz ils seraient mort aujourd'hui et KWin4/Compiz ne serait pas ce qu'il est. Si KWin4/Compiz fait ce qu'il fait la, c'est bien a cause d'Apple. Et Apple fait ça (tout ces effets) depuis heu... 7 ans ? (enfin j'exagere, le moteur en était capable il y a 7 ans et plus, mais ils ne sont arrivé reelement que sur 10.3, soit il y a 5 ans)

KWin4/Compiz sont stable depuis combien de temps deja ? Jamais ? ho zut alors...

Godzil (./46) :
VNC tu connais ?

Ce n'est qu'un workaround pour l'absence de transparence réseau et c'est nul, les fenêtres distantes n'interagissent pas du tout avec les fenêtres locales, elles sont confinées à l'intérieur d'une fenêtre, bref ce n'est pas du tout le même confort d'utilisation.

Kevin Kofler (./43) :
avec une résolution de dépendances!

Aucun interet

Si. Cf. tous mes messages précédents.

(et oui a l'arache pour la simple raison que ton "KTIGCC" n'est qu"un portage 1:1 de l'IDE delphi qui est un foutoir infâme développé en dépits du bon sens)

Bah non, ce n'est pas un foutoir, c'est un environnement de développement intégré dans le vrai sens de ce terme, conçu du début à la fin dans le contexte de TIGCC, et proposant donc au mieux les fonctionnalités de TIGCC.

Et tout le reste la réponse est oui c'est faisable.

Prouve-le nous alors. J'attends ton code. C'est facile d'affirmer quelque chose.

Ha aussi et ce n'est pas a l'IDE de faire la conversion du charset, mais bel et bien a gcc/ld

Certainement pas au linker! GCC et/ou as, je veux bien, mais ce n'est pas codé et c'est plutôt compliqué de le faire, donc c'est l'EDI qui le fait et ça marche très bien. Et l'avantage est aussi que ça permet de transférer des projets entre plateformes sans problèmes de charsets même s'il y a des OS obsolètes qui n'utilisent pas l'UTF-8 par défaut (par exemple celui venant de Redmond) dans le mix.

Godzil (./47) :
Ha oui aussi, si Apple avait attendu Kwin4/Compiz ils seraient mort aujourd'hui et KWin4/Compiz ne serait pas ce qu'il est.

Ils auraient pu étendre eux-mêmes X11 de cette manière (extension Composite etc.) au lieu de réinventer la roue. Le grand avantage de la manière dont les choses sont faites sous GNU/Linux est que c'est compatible. Mais Apple fait exprès de sortir des trucs incompatibles pour avoir des applications exclusives.

Si KWin4/Compiz fait ce qu'il fait la, c'est bien a cause d'Apple.

Non, c'est parce que le monde du libre fait des progrès.

KWin4/Compiz sont stable depuis combien de temps deja ? Jamais ?

KWin 4 est stable depuis le 11 janvier 2008.

Forcement l'OS en question utilise de l'UTF16, et d'ailleurs, je paris que l'IDE Delphi ne l'utilise pas... Car il est codé avec les pieds

(et oui a l'arache pour la simple raison que ton "KTIGCC" n'est qu"un portage 1:1 de l'IDE delphi qui est un foutoir infâme développé en dépits du bon sens)

C'est excessif de dire "à l'arrache" pour KTIGCC, Kevin y a passé beaucoup de temps et je comprends qu'il mette un en réaction à ton post

Mais c'est un fait que KTIGCC n'est en rien une nouvelle feature de TIGCC ("presque" rien, en fait, si on prend comme progrès le support de plus de modèles de câbles vers TI réelle, feature dont je doute un peu de la large utilisation, parce que les émulateurs sont là pour prendre les coups à la place de la calculette réelle). En particulier, KTIGCC ne corrige pas les limitations fonctionnelles de l'IDE Delphi et des TPR associés.

Godzil (./46) :
VNC tu connais ?

Oui enfin, c'est quand même bien différent. VNC c'est du controle de bureau à distance. Si ssh avec X forward marchait nativement sur mac ça aurait résolu pas mal de mes problèmes pour porter une appli sur mac.

Godzil (./50) :
Forcement l'OS en question utilise de l'UTF16, et d'ailleurs

Je parle du format des fichiers, pas du format interne.

je paris que l'IDE Delphi ne l'utilise pas... Car il est codé avec les pieds

Non, car il est compatible 9x/Me.

Kevin Kofler (./44) :

Alors code-nous le plugin. Et la complétion des identifiants de TIGCCLIB en utilisant les informations de la documentation, c'est possible aussi?

Ben si la doc est bien faite, tu peux très bien l'utiliser avec Eclipse, ça c'est clair. Après, il faut voir comment est ta doc, s'il faut adapter javaDoc ou phpDoc ou un autre outil du type.

Kevin Kofler (./53) :

je paris que l'IDE Delphi ne l'utilise pas... Car il est codé avec les pieds

Non, car il est compatible 9x/Me.

Ha ? il faut conserver la compatibilitée avec un OS outdated et plus supporté par son constructeur ?

KWin4/Compiz sont stable depuis combien de temps deja ? Jamais ?

KWin 4 est stable depuis le 11 janvier 2008.

Tu as oublié "déclaré par ses développeurs" pour que ta phrase soit exacte
KDE 4.0 avait des bugs gênants, et les applications dépendant du framework KDE 4.x encore beaucoup plus. La version KDE 4.x de certaines applications qui utilisaient le framework KDE 3.x n'est encore qu'en alpha ou beta, d'ailleurs, bientôt un an après la sortie de KDE 4.0.

(bon se tropic se transforme en flameware :/ si un admin veux le déplacer quelque pars, ou faire un fork ())

./54: Eclipse et Netbeans ne sont ni natifs ni légers

La doc de TIGCC est un système spécifique à TIGCC, qui génère du HTML vieux style, et les fichiers nécessaires pour la compilation en CHM. Il y a aussi un convertisseur CHM -> DCF (format Qt, apparemment).

Lionel Debroux (./58) :
La doc de TIGCC est un système spécifique à TIGCC, qui génère du HTML vieux style, et les fichiers nécessaires pour la compilation en CHM. Il y a aussi un convertisseur CHM -> DCF (format Qt, apparemment).

D'ailleurs utiliser un *vrai* format ne serait pas un luxe je pense...

Ben, quel "vrai" format ? Quels avantages par rapport à l'existant (qui fonctionne pas mal, après avoir réalisé un changement simple pour corriger une grosse connerie qui était faite depuis très longtemps) ?
Si on change, il faudrait écrire un convertisseur automatique de HSF en le nouveau format...