270

Lionel Debroux (./226) :
J'avais bien démarré le logging du link dans le debugger.

... mais la sortie du link n'est pas correcte sad
"Hello World\x0D\x0A" est réduit à 9 caractères.


Ce bug est maintenant corrigé. Plus aucun octet n'est perdu lorsqu'on envoie des octets sur l'extérieur.

Il s'agissait d'une mauvaise interprétation de l'utilité du bit External Link Activity non documenté mais utilisé à partir d'AMS 208.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

271

Vu et vérifié, merci smile
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

272


* Si on appuie sur F11 lors du chargement (preloading débugger), au tout début ça fait crasher TiEmu, et vers la fin ça affiche les fenêtres du débogueur, mais elles sont toutes grisées et la calc semble fonctionner normalement (mais dur à reproduire ça, ça doit être à un moment très précis).

=> bug fixé.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

273

Pollux (./1) :
Voilà le récapitulatif des propositions faites dans le topic "Connextion avec TiEmu":

- fenêtre stack
* +4 / +2 / 0 / +2 / +4 / ... au lieu de -4 / -2 / 0 / +2 / +4 / ...


Explications de ce que tu attends parce que je vois pas là...
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

274

euh....
14:59 @Boo: Pollux n'a pas été vu depuis 175j18h (19:56:08) 14:59 Folco: !seen Pollux

tsss

275

Je pense qu'il veut que monter dans la fenêtre stack ait le même effet que descendre (on cache ce qui est devant %sp et on montre dans les 2 cas ce qui vient après %sp). Je ne vois pas trop l'utilité, je préfère le fonctionnement actuel.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

276

277

Une demande qui revient de temps en temps est de réécrire l'interface graphique de TIEmu (et TILP ?) dans un autre toolkit graphique. Ces demandes incluent parfois la création d'interfaces natives.
Il faut qu'on mette à plat sur la table les choix possibles, leurs avantages et inconvénients, sans oublier les facteurs "manpower nécessaire au changement" et "difficulté de maintenance" smile

(typiquement, Romain a déjà indiqué plusieurs fois que c'était le bazar de maintenir une interface native Windows _en plus_ de l'interface GTK+, et que la standardisation sur un toolkit graphique portable avait simplifié la maintenance. Faire plus d'une interface graphique n'est donc très probablement pas une bonne direction pour le projet.)
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

278

Pour l'instant TIEmu pour windows utilise seulement GTK+ c'est bien ça?
Je pense effectivement qu'il faut simplifier au maximum le "manpower" de maintenance et de développement.

Je suis plutôt pour garder GTK+ meme si j'ai eu un mal fou à installer TIEmu sur Vista...(installation de la bonne librairie gtk ni trop vieille ni trop recente, et installation de libglade... --> je crois que libglade aussi est requis )
Voyez plutôt mon dossier dédié à l'installation de TIEmu :
tromb Fichier joint : BF6E (repertoiregtk.jpg)

Donc ça serait peut-être bien de simplifier l'installation (si c'est possible mais je ne sais pas de quelle manière) car cela peut être déroutant pour certains qui pourrait abandonner l'installation de TIEmu.


PS:Chez moi le téléchargement automatique n'avait pas marché...

279

Pour l'instant TIEmu pour windows utilise seulement GTK+ c'est bien ça?

oui
L'autre option la plus viable pour un toolkit multi-plateformes est Qt.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

280

Quelle sont les limites de GTK+ qui poussent à vouloir "migrer" vers Qt par exemple?

Le probleme de compatibilité entre les versions?

C'est surtout pour savoir ce que l'on cherche exactement dans un autre toolkit...

Merci de votre réponse.

281

Le probleme de compatibilité entre les versions?

A priori, non, parce qu'au sein d'une même série de versions (4.x pour Qt, 2.x pour GTK+), les changements ne sont pas si importants que ça. En revanche, ils sont importants entre Qt 3.x et Qt 4.x, et GTK+ 1.2 (très vieux !) et GTK+ 2.x.

Sous Windows, Qt donne habituellement des applications au look & feel plus "natif", et plus rapides, que GTK+.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

282

Et concernant la difficulté/temps/manpower à migrer vers Qt par exemple...
-->Cela ne veut pas dire une refonte quasi complète?! eek

283

Si si, il faut refaire beaucoup de choses.
C'est bien pour ça que je demande à ceux qui voudraient Qt (ou une interface native, mais c'est encore plus compromis) expliquent pourquoi wink
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

284

Qt est beaucoup plus pratique pour développer avec que GTK+, mais maintenant que tout est déjà écrit en GTK+, je ne suis pas convaincu que ça vaille le coup. Et pour l'installation sous W32, ça revient plus ou moins au même.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

285

Est ce que ces applications ont une structure vaguement inspirée de MVC ou pas?

286

Non, elles ont plutôt une structure inspirée d'un plat de spaghetti
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

287

j'attends la réponse de roms, dussè-je lui demander par mail directement.

288

Demande-lui par mail directement, c'est plus sûr... Grâce à notre Kevinou adoré, Romain a écrit ne pas avoir l'intention de repasser ici: topics/122111-tilptiemu-arret-du-developpement/2#46 .
(c'était avant que Kevin condescende à modifier le nom de son fork, cependant).
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

289

Personnellement, je trouve que Qt4 est clairement plus pratique. il me vient en tête :
- le look est plus natif comme déjà précisé.
- clairement plus léger, simple a installer(il suffit de quelque DLL qui peuvent être jointes, ou on peut très facilement compiler en statique),
- le développement est facile a prendre en main. On peut passer d'un développement sous windows a un dev sous Linux ou autre très facilement(les mêmes outils sont directement dispo)
- C++ pour faire de l'objet c'est clairement mieux que le C

Après, en effet reste a voir si ça vaut le coup et la difficulté pour réaliser ça. Comme notre cher KK compte passer à KDE, il risque également d'essayer de passer a Qt, ça ferait un duplication d'efforts inutile.
avatar

290

Réécrire l'interface utilisateurs de Emu-TIGCC en Qt n'est actuellement pas prévu, pour l'instant je prévois juste de porter l'intégration KDE existante (dialogues de fichiers) vers KDE 4 (en gardant éventuellement aussi le code KDE 3 pour l'instant, mais on ne pourra compiler qu'un à la fois à cause des conflits de symboles). (L'intégration KDE 3 comporte aussi DCOP, mais on a D-Bus qui peut le remplacer et il existe un patch pour KTIGCC 1 pour utiliser D-Bus qu'on peut trouver dans ktigcc-patches.)

Au fait, voulez-vous un nouveau topic sous le nouveau nom pour Emu-TIGCC?
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

291

simple a installer(il suffit de quelque DLL qui peuvent être jointes

Les applications embarquant leur propre copie des DLLs GTK+ sont LA plus grosse source de problèmes entre TILP/TIEmu et ces application sous Windows, cela à cause du loader de Windows. En quoi Qt serait-il différent de ce point de vue-là ?
(Peut-être que sur les Windows >= XP, l'utilisation de manifests permet de résoudre le problème.)
Au fait, voulez-vous un nouveau topic sous le nouveau nom pour Emu-TIGCC?

Ben... ça me paraît être générateur d'une perte de temps pour tout le monde. Ca créerait _deux_ topics au lieu d'un seul commun pour consulter les feature requests et bug reports (dont la très grande majorité seront communs entre TIEmu et TIEmu-fork).
(faut pas se leurrer: chaque côté va regarder ce que les autres font. Du moins, si c'est observable, ce qui est le cas pour GCC4TI mais pas pour TIGCC.)
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

292

Ça s'appelle Emu-TIGCC, pas TiEmu-fork.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

293

Ca ne s'appelle pas, tant qu'il n'y a pas d'annonce officielle wink
On avait fait pareil pour GCC4TI: on utilisait "TIGCC-fork".
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

294

tigcc a changé de nom, il s'appelle gcc4ti, le tigcc actuel est un fork

et de toute , nous sommes tous des forks de kevin embarrassed

295

Lionel Debroux (./291) :
simple a installer(il suffit de quelque DLL qui peuvent être jointe
Les applications embarquant leur propre copie des DLLs GTK+ sont LA plus grosse source de problèmes entre TILP/TIEmu et ces application sous Windows, cela à cause du loader de Windows. En quoi Qt serait-il différent de ce point de vue-là ?
(Peut-être que sur les Windows >= XP, l'utilisation de manifests permet de résoudre le problème.)
Je suis loin d'être expert en DLL mais il me semble bien que si on pose les DLL qt dans le répertoire d'un l'exécutable, elles sont utilisées par l'exécutable et lui seul. Certes ca fait de la duplication de dll si on installe plusieurs appli Qt, mais comme Windows n'a pas de gestion de dépendance intégrée, ça me semble la meilleure solution pour éviter les casse tête que l'on a avec les applis GTK.

avatar

296

je sais pas quel est le comportement quand t'as une DLL avec le même nom et une version différente dans c:\windows ^^ il utilise laquelle là? c'est selon le PATH ou y'a des règles à la con qui lui font faire de la merde?

297

Il me semble bien que la prioritaire est celle dans le répertoire de l'exe.
avatar

298

Il me semble bien que la prioritaire est celle dans le répertoire de l'exe.

Je dirais que non: il me semble me souvenir que Wireshark (qui embarque GTK+, à moins d'avoir changé récemment) et TIEmu rentraient en interaction s'ils étaient démarrés dans un certain ordre.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

299

Bizarre il me semblait avoir lu quelque part que l'ordre était:
1) Répertoire de l'exe
2) Répertoire courant
3) Répertoire System32
4) Répertoire Windows
5) Répertoires du %PATH%
avatar

300

bienvenue dans le dll-hell, c'est pas pour rien que ça s'appelle comme ça grin