TiEmu: fiture ricouaistes - Page 10

Vu et vérifié, merci

* 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é.

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à...

euh....

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

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.

Je t'ai rajouté ça aujourd'hui Romain : https://sourceforge.net/tracker/?func=detail&aid=2788897&group_id=23169&atid=377680
désolé

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"

(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.)

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 :
Fichier joint : (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é...

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

L'autre option la plus viable pour un toolkit multi-plateformes est Qt.

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.

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+.

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

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

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.

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

Non, elles ont plutôt une structure inspirée d'un plat de spaghetti…

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

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).

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.

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?

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.)

Ça s'appelle Emu-TIGCC, pas TiEmu-fork.

Ca ne s'appelle pas, tant qu'il n'y a pas d'annonce officielle
On avait fait pareil pour GCC4TI: on utilisait "TIGCC-fork".

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

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.

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?

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

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.

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%

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