Folco (./61) :
Parce que si la communication de "TIGCC" -> VTI est rétablie, le code est là, il ne suffirait à l'équipe que de fournir un petit script dans le genre que t'as posté pour me permettre ça (parce qu'encore une fois, la structure de mes programmes m'empêchent l'envoi direct). 
Tu vas m'expliquer comment tu veux faire du SendMessage dans un script...
Ximoon (./62) :
Features request que vous devez déjà avoir :- Fichiers sources en feuilles MDI (argument de Kevin pour refuser : "je trouve ça inutile")
Je trouve ça inutile parce que l'arborescence du projet sert déjà de tabs, donc pourquoi rajouter une autre barre de tabs (et les tabs sont supérieurs au MDI classique)?
_ Pouvoir ouvrir plusieurs projets à la fois (argument de Kevin pour refuser : "je trouve ça inutile")
Je pourrais éventuellement rajouter ça dans le futur lointain (KTIGCC 3 ou 4), mais ça nécessite des changements structurels à KTIGCC (et aussi à TIGCC IDE, mais il est prévu que KTIGCC 3 le remplacera), c'est loin d'être trivial. Pour l'instant, il suffit d'ouvrir plusieurs sessions de l'EDI (et j'ai corrigé les problèmes qu'il y avait avec KTIGCC sous cette utilisation).
Uther (./65) :
./58 > Je vais pas de passer tes argument un par un mais soit ça correspond plutôt à des défaut pour moi(notamment le système de tpr), soit l'intérêt est vraiment anecdotique comparé ou confort que peut apporter un IDE de qualité.
Il y a un sous-entendu qui me dérange là...
Et si tu es tellement convaincu que XYZ est mieux comme EDI, vas-y, code-nous l'intégration avec XYZ.
Un autre problème est que personne n'est d'accord sur le XYZ à choisir, j'ai vu des propositions d'utiliser à peu près tout, à la fois des propositions sérieuses (mais quand-même inexploitables à cause des arguments déjà cités) comme Eclipse, Code::Blocks, KDevelop (mais KDevelop 3 serait le bordel sous W32, il faut Cygwin, KDE 3 et un portage non officiel de Qt 3, probablement aussi X11 (aucune idée si ça marche avec la version sans X11 du portage de Qt 3)) etc., et des propositions peu pratiques car monoplateformes comme Visual Studio et XCode (ça voudrait dire qu'on devrait s'intégrer à plusieurs EDIs).
Bref, si j'avais choisi X, je suis sûr que j'aurais quand-même tout le monde qui me demande pourquoi je n'ai pas choisi Y. Bref, je me retrouverais à devoir intégrer TIGCC à plusieurs EDIs (surtout si je fais plaisir à ceux qui me demandent du Visual Studio ou du XCode), donc faire plusieurs fois le travail et avec des interfaces totalement différentes et des fichiers projet totalement incompatibles. De plus, je n'ai pas Visual Studio ni XCode, ils ne tournent pas sous GNU/Linux.
- L'intérêt serait de pouvoir également exécuter via un paramètre '-run' par exemple.
Cf
./18 (mais ça nécessite TiEmu, logique, VTI n'a pas d'interface IPC; et sous W32, il faut avoir compilé TiEmu avec D-Bus activé - je compte le faire un de ces jours, mais ça voudra dire au revoir 9x/Me et NT 4 qui ne sont pas supportés par D-Bus, je ne peux pas continuer à supporter ces systèmes obsolètes datant de 8 années ou plus, toutes les libs dont je me sers les ont abandonnés depuis longtemps (c'est pour ça que le GTK+ de TiEmu est antique) et ils ne reçoivent plus aucune mise à jour, même pas pour les trous de sécurité critiques - et des binaires de Qt avec D-Bus (cf. projet kdewin)).
- Ca nécessite Tiemu.
Faux (pour TiLP 2), il y a aussi
--cable=VTi.
- Je sais pas si ça c'est amélioré mais, à l'époque ou j'avais essayé de le faire, ça marchait plutôt mal(voire pas du tout).
Il faut avoir configuré TiEmu pour le link TiEmu, port #1.
c'est indispensable pour des gros projets (la lib+les tests par ex.)
