Packager des binaires pour Mac - Page 3

Nil (./54) :
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.

C'est un format spécial, en gros un INI dont une des sections est du HTML (les autres sections sont des Key=Value classiques).

Godzil (./55) :
Ha ? il faut conserver la compatibilitée avec un OS outdated et plus supporté par son constructeur ?

Non, j'explique juste pourquoi les logiciels W32 n'utilisent souvent pas l'UTF-16 en interne, il faudrait réécrire pas mal de code pour changer ça dans un logiciel existant. Cette compatibilité ne sera plus présente quand TIGCC IDE sera remplacée par KTIGCC 3, parce que kdewin ne supporte pas ces versions obsolètes du système d'exploitation.

Lionel Debroux (./56) :
Tu as oublié "déclaré par ses développeurs" pour que ta phrase soit exacte

C'est ma définition de "stable".

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.

Tu peux utiliser les versions KDE 3 de ces applications, elles marchent très bien sous KDE 4.

Ben ceux cité par Nil par exemple, on a aussi tout ce qui est spécialisé doc, genre DITA etc...

TIGCC fait l'inverse de la plupart des solutions de doc: génération des headers à partir de la doc (solution type programmation littérale). Si on veut changer, il n'y a pas que le format à changer, il y a tout le paradigme de documentation
Je ne suis pas contre le changement, mais il faut que la nouvelle solution ait des avantages significatifs par rapport à l'ancienne (qui fonctionne pas mal, après un petit changement, comme je l'ai écrit). Pas comme KTIGCC 3 vs. TIGCC IDE pour les utilisateurs de Windows, je veux dire.

Ben moi je vois ne serait-ce qu'un truc : se débarrasser d'un format proprio (comme le TPR d'ailleurs, plus proprio tu meurs )

Sinon tu as aussi le fait que certain outils sont vraiment "pro" que c'est facilement integrable dans des IDE plus "classiques" qu'on peu generer du HTML, PDF, & autres formats sans avoir besoin de le coder...

Kevin Kofler (./48) :

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.

Pas besoin de te le prouver moi meme :

http://maxao.free.fr/xcode-plugin-interface/

(comme le TPR d'ailleurs, plus proprio tu meurs )

Ouais, c'est vrai
En termes de diffusion, c'est beaucoup plus facile de se passer des HS* (il y a plusieurs formats similaires, qui diffèrent par les infos utilisées dans leurs sections - leurs DTDs, quoi) que du TPR, puisque les utilisateurs de TIGCC n'utilisent pas les HS*.

Tant qu'on est à faire ce genre de changements, il faut voir si on n'aurait pas envie d'utilisations que le système actuel ne permet pas: ça peut influer sur la façon de faire le nouveau système.
Sans aller chercher dans des solutions existantes (qui n'auront pas forcément une flexibilité suffisante pour remplacer le système ad-hoc actuel), la transformation de la doc en XML permettrait d'utiliser des feuilles XSLT, qui permettent ensuite de cibler beaucoup de choses. Ce qui n'empêche pas de mettre un peu de code de glue par-dessus XSLT, si certaines opérations sont pénibles ou irréalisables avec XSLT seul.

DITA est du XML (par exemple)

Godzil (./65) :
Pas besoin de te le prouver moi meme :

http://maxao.free.fr/xcode-plugin-interface/

Et ben, comme je le pensais, impossible de convertir le charset des fichiers à l'ouverture et à l'enregistrement comme le fait KTIGCC. Les possibilités de ces plugins sont très limitées.

Bon puisque tu veux des preuves concretes :


Fichier joint : (Image 1.png)


(et j'ai fait bien mieux qu'un simple plugin)

Mais voyons, un screenshot, ce n'est pas une preuve concrète
Tu aurais très bien pu le trafiquer

Me suis fait chier a faire des icones expres pour alors hein

Kevin Kofler (./31) :

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.

Un IDE avec XUL est tout a fait faisable. cf http://www.openkomodo.com/
Ce n'est pas parceque XUL a été créé par mozilla qu'il n'est pas adapté à d'autre chose que du web. C'est comme si je disais que GTK qui vient de the gimp n'était utile que pour faire du traitement d'image.

[troll](oué enfin GTK aurais pu y rester )[/troll]

Bizarrement, je m'attendait à cette réponse, mais je me demandait vraiment qui sortirait ça en premier.

bon bref, on pars vraiment a la dérive :/ (bah pour le troll)

en même temps, le HS est arrivé tôt (je dirais, à la louche : ./14 ^^ ) donc on n'est plus à ça près, si ?

C'est pas faux :/ et devinons qui l'a lancé ?

Ca vous étonne ?

Godzil (./70) :
Bon puisque tu veux des preuves concretes :

Fichier joint : (Image 1.png)
(et j'ai fait bien mieux qu'un simple plugin)

Ce n'est qu'un simple template, c'est loin de gérer toutes les fonctionnalités spéciales TIGCC de KTIGCC (celles citées dans ce topic, par exemple).

C'est plus qu'un simple template, derriere il y a gestion de tigcc et autres options qui vont avec (le tout dans la fenetre de pref, mais #flemme# d'en faire un screen) et aussi, mais la impossible de tester utilisation du gdb "distant" et autres choses comme les keywords coloring & co

bref non ce nest pas un template mais bien une plateforme suplémentaire complete

Fichier joint : (Image 2.png)

Au meme titre que l'iPhone est une "plateforme" et qu'on peu le debugguer

Même une "plateforme supplémentaire complète" ne peut pas gérer les fonctionnalités comme le transcodage à l'ouverture et à l'enregistrement.

Et l'intégration avec GDB a de fortes chances de ne pas marcher avec la version intégrée à TiEmu.

Et elle sort d'où ta "plateforme supplémentaire"? C'est le vieux plugin d'Adam Thayer qui n'est plus maintenu depuis un sacré temps?

./82 : qu'est ce que tu appelles "transcodage à l'ouverture et à l'enregistrement" ? Tu veux dire ouvrir du code source uniformément, que ce soit de l'ascii, de l'utf8, 16, du windows-latin-1 etc., et sauvegarder dans le même format ?

Je maintiens que c'est le role de GCC (ou au pire de l'équivalent de CPP) de faire ce boulot et pas de l'IDE, sinon bonjour les problèmes lors qu'on l'utilise pour X raisons en ligne de commande...

Kevin Kofler (./82) :
Et elle sort d'où ta "plateforme supplémentaire"? C'est le vieux plugin d'Adam Thayer qui n'est plus maintenu depuis un sacré temps?

Sa ne risque pas, car ce qu'il avais fait est si je m'abuse qu'un template utilise les makefile, ce qui n'est pas le cas ici, et les plate-forme n'existait pas a cette epoque car leur support a été ajouté spécialement pour l'iPhone, donc il y a moins de 6/7 mois

Sinon je n'ai pas a répondre à ta question. Cette plateforme existe point barre

de toute façon le C est en ascii non?

kim (./83) :
./82 : qu'est ce que tu appelles "transcodage à l'ouverture et à l'enregistrement" ? Tu veux dire ouvrir du code source uniformément, que ce soit de l'ascii, de l'utf8, 16, du windows-latin-1 etc., et sauvegarder dans le même format ?

Non, je veux dire ouvrir et enregistrer le code source uniformément en le charset de la calculatrice (ISO-8859-1 modifié, notamment avec les lettres grèques).

Godzil (./84) :
Je maintiens que c'est le role de GCC (ou au pire de l'équivalent de CPP) de faire ce boulot et pas de l'IDE, sinon bonjour les problèmes lors qu'on l'utilise pour X raisons en ligne de commande...

Justement, les fichiers sont enregistrés en le charset de la calculatrice, donc ça marche aussi en ligne de commande.

Sinon je n'ai pas a répondre à ta question. Cette plateforme existe point barre

Tu as montré qu'elle existe, mais pas ce qu'elle est capable de faire, et en particulier ça ne montre en rien que ce qu'elle est capable de faire est équivalent à KTIGCC de quelle manière que ce soit (et je suis pratiquement sûr que ça ne l'est pas).

squalyl (./85) :
de toute façon le C est en ascii non?

Pas à l'intérieur des chaînes de caractères.

Kevin Kofler (./86) :

kim (./83) :
./82 : qu'est ce que tu appelles "transcodage à l'ouverture et à l'enregistrement" ? Tu veux dire ouvrir du code source uniformément, que ce soit de l'ascii, de l'utf8, 16, du windows-latin-1 etc., et sauvegarder dans le même format ?

Non, je veux dire ouvrir et enregistrer le code source uniformément en le charset de la calculatrice (ISO-8859-1 modifié, notamment avec les lettres grèques).

Godzil (./84) :
Je maintiens que c'est le role de GCC (ou au pire de l'équivalent de CPP) de faire ce boulot et pas de l'IDE, sinon bonjour les problèmes lors qu'on l'utilise pour X raisons en ligne de commande...

Justement, les fichiers sont enregistrés en le charset de la calculatrice, donc ça marche aussi en ligne de commande.

Autant dire que ça casse completement la compatibilitée avec tout autre editeur. Ca sent la "feature" pour empecher d'utiliser d'autre éditeurs...

Kevin Kofler (./86) :

Sinon je n'ai pas a répondre à ta question. Cette plateforme existe point barre

Tu as montré qu'elle existe, mais pas ce qu'elle est capable de faire, et en particulier ça ne montre en rien que ce qu'elle est capable de faire est équivalent à KTIGCC de quelle manière que ce soit (et je suis pratiquement sûr que ça ne l'est pas).

Et tu as tord, de toute maniere tu n'as pas de mac, donc je peut rien te "prouver" directement.

Série de captures? Screencast en Ogg Theora?

100 balles un mars aussi hein...

Godzil > C'est une plateforme que tu as faite? Si oui, l'as-tu releasée? Si non, où te l'es-tu procurée?