TIGCC 0.95 Beta 5 - Page 7

BiHi :
Tu vas le faire en C++ Kevin ? (Qt utilise le C++ et si j'ai bien compris tu vas utiliser Qt)

Entre de l'objet en un langage fait pour (Qt) et de l'objet en un langage pas fait pour (GTK), je préfère encore l'objet en un langage fait pour. En revanche, je n'exclus pas la possibilité d'écrire une grande partie du code en "plain old" C. Et je ne vais pas forcément utiliser les fonctionnalités objet du C++ pour autre chose que les appels à Qt. (Mais peut-être que le code Delphi de Sebastian se traduit bien en C++ objet, bref c'est à voir.)

GoldenCrystal> L'intérêt d'utiliser Qt c'est que le portage de l'IDE sera pas seulement sous linux, mais aussi sous MacOS X.

Voilà une autre manière de résumer les choses. Mais il n'y a pas que OS X, il y a pratiquement tous les *nix possibles et imaginables sur tout un paquet de plateformes que ça concerne. OS X n'est "que" le plus utilisé parmi ceux-là.
Cela dit, je compte utiliser des fonctionnalités KDE par-ci par-là, donc le look&feel ne sera pas entièrement natif sous OS X (mais ça tournera, les kdelibs ont été portées!). Par exemple, je vais utiliser les dialogues de fichiers de KDE (parce qu'ironiquement ceux de Qt sont natifs partout sauf sous Linux/KDE, bref j'ai le choix entre les dialogues natifs sous Linux et non-natifs sous OS X ou l'inverse ).

Kevin Kofler :
Par exemple, je vais utiliser les dialogues de fichiers de KDE (parce qu'ironiquement ceux de Qt sont natifs partout sauf sous Linux/KDE, bref j'ai le choix entre les dialogues natifs sous Linux et non-natifs sous OS X ou l'inverse ).

Ou tu peux utiliser les dialogues KDE sous Linux, et ceux de Qt sur les autres plateformes, c'est encore plus simple à mon avis.

Oui, et il y a même des solutions pour automatiser cela.
Mais ma priorité n°1 est de faire quelque chose qui marche bien sous KDE. Pour les dialogues natifs pour OS X, je verrai après (parce qu'après tout, même si j'ai "beaucoup" d'utilisateurs sous OS X, ce n'est pas ma plateforme primaire vu que je ne l'ai même pas). Quant à Win32, je pense que l'IDE de Sebastian reste la meilleure solution pour Win32, donc je ne prévois pas de portage Win32 de ma version Qt/KDE actuellement.

Je viens de faire tree view, splitter et barre d'état, donc il y a une nouvelle capture d'écran.
La fenêtre principale est pratiquement finie maintenant. L'éditeur de texte est toujours un KTextEdit en placeholder. Je vais le remplacer soit par un KatePart, soit par un éditeur de textes à coloration syntaxique personnalisé plus tard. Mais je vais d'abord travailler sur la fonctionnalité de base, pour que je puisse sortir au moins une version alpha dans un délai raisonnable (probablement sans coloration syntaxique: quant à elle, elle va venir, mais plus tard).

Super Kevin

./181 >

Pour le C++ : Y changera jamais...

Pour l'IDE:

1) TIGCC IDE sur FreeBSD...

2) Faire un KDevelop modifié ne serait-il pas plus facile et tout aussi efficace ?

Au fait, j'aimerais pouvoir faire du code avec gcc et as et
sortir un fichier .tib.
Il me faudrait donc un outil comme maketib mais fonctionnant sur du COFF...

Comment devrais-je faire ? Prendre les sources de maketib et essayer l'équivalent pour
du COFF ? Ou faire un outil qui fait le contraire d'objcopy et convertit du COFF en format A68k,
puis lancer maketib dessus ?

Tu peux faire comme moi. Tout faire avec a68k et utilise s2asm pour convertir de as en a68k.

PpHd > Merci
Ca marche bien au fait ? Oui, question conne mais
je vais peut-être avoir à faire du hack très méchant,
est-ce que c'est un convertisseur "parfait" ou non ?

Non. Il est loin d'etre parfait. Il suffit pour PedroM. Mais je ne m'avancerais pas plus loin.

Où est-ce que ça risquerait de coincer ?
(Si je vois que ça me suffit, je l'utiliserai)

Tu essayes, tu verras

Il ne traite pas toutes la syntaxe (riche et complexe) de as. Mais s2asm est assez facile a corriger en cas de pb.

Bon, ok, je verrai.
Au pire je convertirai à la main.

Et script Perl powa, pour ce genre de petites manips.

Snow Tiger :
Pour le C++ : Y changera jamais...

D'ailleurs, il y a déjà le premier hack non-objet. QT Designer ne me permet pas de rajouter des variables à la classe MainForm, donc je les ai mises en static dans le module. De toute façon, de fenêtre principale, il n'y en a qu'une.

2) Faire un KDevelop modifié ne serait-il pas plus facile et tout aussi efficace ?

Ben, il y a déjà quelqu'un qui a essayé de porter une IDE existante et voici le résultat: une alpha qui est loin d'être finie et déjà obsolète (elle en est toujours à TIGCC 0.94). Bref, non.

Snow Tiger :
Au fait, j'aimerais pouvoir faire du code avec gcc et as et
sortir un fichier .tib. Il me faudrait donc un outil comme maketib mais fonctionnant sur du COFF...

Tu prends les sources de ld-tigcc et tu rajoutes l'exportation en format TIB. Comme ça, je ne me serai pas fatigué pour rien à rajouter le support de l'exportation multi-formats. (Je l'ai rajouté pour le target Fargo, mais je suis le seul qui l'utilise, celui-là. )
Ça fait longtemps que je dis à PpHd de faire ça (je pense même me rappeler de lui avoir déjà proposé de faire moi-même les modifications du linker), mais il utilise toujours ses hacks affreux et non-supportés (source A68k qui dépasse le maximum des lignes). Je vais finir par mettre une erreur pure et dure si on dépasse le maximum des lignes, pour:
* corriger les bogues aléatoires qu'il y a dans cette situation. On n'a qu'à ne pas dépasser le maximum documenté.
* essayer de forcer PpHd à faire le travail nécessaire sur le linker.

Comment devrais-je faire ? Prendre les sources de maketib et essayer l'équivalent pour
du COFF ? Ou faire un outil qui fait le contraire d'objcopy et convertit du COFF en format A68k, puis lancer maketib dessus ?

Si tu trouves une copie de notre m68k-amigaos-objcopy, tu peux en principe aussi convertir dans l'autre sens avec. Mais je ne sais pas du tout si ça marche. Et je te conseille plutôt de travailler avec ld-tigcc.

OK, je vais voir. Mais pour compiler ld-tigcc, il me faut quoi ? (J'ai Dev-C++, vous
utilisez mingw non ?)

Snow Tiger :
OK, je vais voir. Mais pour compiler ld-tigcc, il me faut quoi ? (J'ai Dev-C++, vous utilisez mingw non ?)

J'utilise en effet MSYS.
Cela dit, je pense que tu peux t'en sortir assez facilement avec Dev-C++, il te faudra juste ajouter tous les fichiers .c (et aussi les .h si tu veux pouvoir les éditer facilement) à ton projet. Vu que le compilateur est le même, il ne devrait pas y avoir de problèmes.

OK, très bien.
Hum, est-ce que j'aurais besoin de connaître le format COFF ?
Si oui, où je peux trouver celui de TIGCC ? Le format COFF n'est pas
très clairement défini, surtout au niveau du relogement, donc....

Snow Tiger
: Hum, est-ce que j'aurais besoin de connaître le format COFF ?

Normalement non, vu que tu ne travailleras que sur l'exportation. L'importation COFF est déjà là. Tu ne devras travailler que sur nos structures internes, qui sont bien documentées dans nos headers.

Si oui, où je peux trouver celui de TIGCC ? Le format COFF n'est pas très clairement défini, surtout au niveau du relogement, donc....

Il y a la DJGPP COFF spec et la spec officielle de M$. Cette dernière te demande d'accepter un EULA stupide sur ce que tu feras avec cette information, probablement pas valide légalement, mais je ne te conseille quand-même pas d'y toucher si tu peux éviter. Et puis il y a nos sources.
Mais de toute façon, tu n'as pas besoin de connaître le format COFF, notre linker est suffisamment modulaire pour ça!

OK, je m'y met dès que possible.

Kevin Kofler
:

Snow Tiger :
Pour le C++ : Y changera jamais...

D'ailleurs, il y a déjà le premier hack non-objet. QT Designer ne me permet pas de rajouter des variables à la classe MainForm, donc je les ai mises en static dans le module. De toute façon, de fenêtre principale, il n'y en a qu'une.

Et si tu faisais une classe dérivée de Mainform avec tes trucs à toi, ce serait peut-être plus propre

Mais du coup, je ne peux plus mettre les routines qui travaillent dessus dans le .h prévu pour (oui, du code dans un .h , et ce ne sont même-pas des inlines - le hack n'est pas de moi, cette fois-ci, mais de Trolltech, je ne fais qu'utiliser ce que QT Designer me prépare automatiquement).

Et de toute façon, je n'ai rien à f**tre de l'objet "propre".

QT designer genere du code pas vraiment super propre. T'est obligé de fairez avec? ca doit pas être trop du de faire ca proprement a la main.
J'avais commencé a fair mon editeur de pack-archives avec QTDesign mais je suis repassé a la main.

Kevin>
Bah, si tu conçois tout en statique et que pour une raison X ou Y tu veux pouvoir avoir plusieurs instances d'une fonctionnalité donnée, t'es dans la merde... (genre, pouvoir ouvrir plusieurs projets à la fois mais tout en gardant un certain lien entre ces projets, ce qui permettrait de tout recompiler d'un seul coup et de pouvoir faire des rechercher/remplacer sur ces deux projets)

Après, si QT Designer est mal conçu, c'est effectivement peut-être l'un des moyens les plus simples de contourner ça (ça doit peut-être encore être possible en faisant une classe abstraite pour tes variables à toi (donc dans un .cpp séparé) et en faisant dériver la classe de QT de cette classe-là, mais ça peut devenir lourd s'il y a trop d'interactions entre ces deux classes-là...).

Pollux :
Kevin> Bah, si tu conçois tout en statique et que pour une raison X ou Y tu veux pouvoir avoir plusieurs instances d'une fonctionnalité donnée, t'es dans la merde... (genre, pouvoir ouvrir plusieurs projets à la fois mais tout en gardant un certain lien entre ces projets, ce qui permettrait de tout recompiler d'un seul coup et de pouvoir faire des rechercher/remplacer sur ces deux projets)

Il y a une seule fenêtre principale dans l'IDE de Sebastian, donc il y aura une seule fenêtre principale dans la mienne. Je ne vais rien mettre d'autre que ce qu'il y a dans l'IDE de Sebastian.

Après, si QT Designer est mal conçu, c'est effectivement peut-être l'un des moyens les plus simples de contourner ça (ça doit peut-être encore être possible en faisant une classe abstraite pour tes variables à toi (donc dans un .cpp séparé) et en faisant dériver la classe de QT de cette classe-là, mais ça peut devenir lourd s'il y a trop d'interactions entre ces deux classes-là...).

Changer la classe de laquelle QT Designer dérive (ou en rajouter une deuxième en héritage multiple), ce n'est pas possible non plus.

Uther
: QT designer genere du code pas vraiment super propre. T'est obligé de fairez avec? ca doit pas être trop du de faire ca proprement a la main.

Ben, vu que je n'ai jamais fait du Qt avant, le RAD m'avance bien.
Cela dit, j'ai déjà quelques lignes de code, et j'ai donc déjà commencé à prendre confiance avec le modèle d'objets de Qt. (J'apprends vite, heureusement.)

Il y a une seule fenêtre principale dans l'IDE de Sebastian, donc il y aura une seule fenêtre principale dans la mienne. Je ne vais rien mettre d'autre que ce qu'il y a dans l'IDE de Sebastian.

Oui, c'est bien ce que j'avais cru comprendre C un peu dommage de prendre une structure figée, je trouve...

Mais ça a 3 gros avantages:
* Ça m'évite de devoir m'occuper du design de l'interface au sens strict. Le "design" ne consiste qu'à copier l'interface existante.
* Ça me donne un point de repère clair où je veux arriver, et quand je peux considérer une certaine feature comme terminée.
* Et surtout ça permettra aux utilisateurs de passer de l'une à l'autre (dans les 2 sens!) sans aucune difficulté!