Connexion avec TiEmu - Page 3

Pollux (./60) :
ce qu'il faut c'est simplement des toolbars dockables ^^ (c'est par exemple ce que fait visual studio)

Et Qt le fait très bien ça d'ailleurs

Martial Demolins (./62) :
et surtout le SR avec chacun de ses bits X = 0/1 (merci de l'info!!!   ...)

Ben c'est utile, il faudrait juste que ça prenne moins de place.

Martial Demolins (./62) :
la fenêtre des registre, divisable par 4

Comment? (Dessine-nous un mockup.)

et surtout le SR avec chacun de ses bits X = 0/1 (merci de l'info!!! ...)

Tu fais peut-être la conversion hexa->binaire en une microseconde dans ta tête et connais tous les numéros de bit pour chaque flag par cœur, mais ce n'est pas le cas de tout le monde.
Je trouve cette information très pratique et utile, et ce n'est pas ça qui prend la place de toute façon (mais les 14 registres).

la fenêtre des registre, divisable par 4

Comment? (Dessine-nous un mockup.)

VTI est probablement assez proche de ce qu'il a dans l'idée.
Il est vrai que la police plus grosse que sous VTI, et l'espace important entre les lignes, facilitent la lecture - mais ces différences augmentent aussi très nettement la taille de la fenêtre de registres.

Les modifs de l'UI qu'un certain nombre de personnes veulent sont implémentables - mais pour que ça vaille le coup de le faire, il faut que l'idée soit acceptée par les mainteneurs, et que le patch soit accepté - ce qui n'est pas forcément immédiat.
Encore une fois, on ne parle pas de remplacer purement et simplement l'interface actuelle de TIEmu par une interface plus proche de celle de VTI. On parle juste de proposer les deux, pour que tout le monde soit plus content.

[EDIT: tant qu'on est dans les feature/enhancement requests... est-ce que je suis le seul dont l'affichage de tous les zéros non nécessaires par le nouveau désassembleur des versions récentes de TIEmu change les habitudes ?]

Zephyr (./30) :
J'étais résolument contre .NET quand c'était encore une dépendance; ce n'est que depuis l'arrivée de Vista que je considère ce framework comme utilisable. Quand au fait que TiEmu installe GTK automatiquement, encore heureux, il manquerait plus qu'il faille installer tout les composants à la main... mais ça n'en reste pas moins une dépendance.

Mais je ne comprends pas ce qui te pose problème : de toute façon, pour installer un logiciel sous windows, il te faut lancer cet installateur. Si celui-ci installe plein de sous-dépendances, tu n'as pas à t'en préoccuper ?
Quelle différence y a-t-il entre lancer un installateur pour installer un logiciel, et lancer un installateur pour installer un logiciel et ses dépendances ? Dans tous les cas, tu fais à peu de choses près pareil, non ?

Pour exécuter des programmes Qt sous windows, il suffit d'avoir les DLLs.

Lionel Debroux (./65) :
[EDIT: tant qu'on est dans les feature/enhancement requests... est-ce que je suis le seul dont l'affichage de tous les zéros non nécessaires par le nouveau désassembleur des versions récentes de TIEmu change les habitudes ?]

Tu parles de la version sans GDB là? La version GDB propose la même syntaxe (type GNU as) depuis longtemps.

Les changements dans la sortie de la version sans GDB ne sont probablement pas voulus, mais dus au passage au désassembleur tiré de VTI à celui intégré à UAE (pour des raisons de licence). Je suis prêt à corriger ça, mais comme je n'utilise pas la version sans GDB, il faudra que tu m'indiques au moins qu'est-ce qui ne va pas exactement (un patch serait encore mieux, mais s'il te plaît évite le copier-coller du code du désassembleur non-libre de VTI).

Sinon, ce qu'on pourrait essayer de faire éventuellement, c'est compiler le désassembleur de GDB sans le reste de GDB, comme je le fais dans dasm-tigcc.

Sasume (./67) :
Pour exécuter des programmes Qt sous windows, il suffit d'avoir les DLLs.

Oui, par exemple: http://download.cegit.de/kde-windows/qt/single/qt-mingw-4.3.0-1-bin.zip

./68: en effet, j'utilise toujours la version sans GDB.
Passe encore de mettre une taille aux instructions pour lesquelles on n'en met habituellement pas (RTE.L au lieu de RTE... bof), mais
LEA.L (PC,$0010) [...], A1
MOVE.W #$000C,D1
change les habitudes de lecture. Mais peut-être suis-je le seul que ça embête

Sasume (./66) :
Mais je ne comprends pas ce qui te pose problème : de toute façon, pour installer un logiciel sous windows, il te faut lancer cet installateur. Si celui-ci installe plein de sous-dépendances, tu n'as pas à t'en préoccuper ?

Si, je veux savoir exactement ce qui est installé sur mon système; l'installeur est un moindre mal, le mode d'installation que je trouve le plus propre est celui de MacOS X (un seul fichier à copier), et les applications en .zip sont un moindre mal. On ne va pas relancer le débat ici, mais je te rappelle que je suis résolument contre le principe des dépendances.

Sasume (./67) :
Pour exécuter des programmes Qt sous windows, il suffit d'avoir les DLLs.

Si on peut les mettre dans le même répertoire que l'application qui en a besoin, alors c'est pas trop mal comme solution.

Lionel Debroux (./69) :
LEA.L (PC,$0010) [...], A1
MOVE.W #$000C,D1
change les habitudes de lecture. Mais peut-être suis-je le seul que ça embête

C'est sans doûte facile à changer. Il doit y avoir un caractère à virer dans un format string (ou peut-être plusieurs) en fait.

Je vais quand-même demander l'avis de Romain et lui demander de corriger ça (vu qu'il utilise habituellement la version sans GDB, donc il est mieux placé pour tester que moi).

Zephyr (./70) :
Si on peut les mettre dans le même répertoire que l'application qui en a besoin, alors c'est pas trop mal comme solution.

Tu peux faire ça avec GTK+ aussi en principe. Mais après, si tu essaies de lancer plusieurs applications qui utilisent des versions différentes de GTK+ à la fois, le cache de DLL (qui fonctionne par nom du fichier seulement, sans le chemin d'accès, conception catastrophique de M$) va faire que les versions entrent en conflit et font tout boguer. C'est pour ça qu'il est plus sûr d'avoir une version partagée de GTK+ utilisée par tout le monde. Il en est de même pour Qt et n'importe quelle autre DLL qui existe en plusieurs versions. De toute façon, ça a aussi l'avantage de réduire la place consommée sur le disque dur.

Et sinon, je rappelle que TiEmu doit aussi enregistrer son interface de communication entre processus. (On utilise actuellement de l'automation OLE.)

Kevin Kofler (./72) :
Tu peux faire ça avec GTK+ aussi en principe. Mais après, si tu essaies de lancer plusieurs applications qui utilisent des versions différentes de GTK+ à la fois, le cache de DLL (qui fonctionne par nom du fichier seulement, sans le chemin d'accès, conception catastrophique de M$) va faire que les versions entrent en conflit et font tout boguer. C'est pour ça qu'il est plus sûr d'avoir une version partagée de GTK+ utilisée par tout le monde. Il en est de même pour Qt et n'importe quelle autre DLL qui existe en plusieurs versions.

Effectivement, erreur de conception, mais il n'y a pas moyen de forcer par exemple l'effacement du cache pour éviter ces erreurs ? Parcequ'avoir des DLL dans le dossier de l'application serait vraiment une bonne alternative à l'installation de GTK je trouve.

De toute façon, ça a aussi l'avantage de réduire la place consommée sur le disque dur.

On est pas sur Ti, à vouloir gagner quelques ko voire quelques mo; un disque dur d'entrée de gamme fait déjà plus de 100go actuellement

Lionel Debroux (./17) :
@Martial: tu as oublié la portabilité de l'émulateur

A part ça:
> - Interface du déboggueur complètement à revoir (prendre modèle sur VTI)
Assez d'accord. La séparation en fenêtres n'a pas que des atouts, et l'interface du debugger est lente, même sous GNU/Linux et sans le debugger C. Peut-être que ça irait mieux si j'utilisais Gnome et pas KDE, mais l'assez lourd Gnome sux
J'imagine que GTK ne fournit pas un moyen de regrouper plusieurs fenêtres en une (ou que seules des versions de GTK un peu trop récentes le font) ?> - demande des programmes pas trop buggués pour le débogage, sinon il plante

Je reconnait que le debugger pourrait être meilleur et qu'il est lent mais GTK ne fourni pas de MDI. Pour çà, il faut utiliser GNome et je m'y refuse catégoriquement (pas portable et lourd).

Pas mal des libs GNOME ont été portées pour Win32 avec le portage de Evolution, peut-être que la lib qui fait le MDI en fait partie?

Ceci dit, je reste de l'avis que le MDI n'est pas la solution qu'on cherche.

[cite] Kevin Kofler (./25) :

Lionel Debroux (./17) :

J'imagine que GTK ne fournit pas un moyen de regrouper plusieurs fenêtres en une (ou que seules des versions de GTK un peu trop récentes le font) ?

Si et c'est même dispo en option dans TiEmu: lancer le debugger, aller dans la fenetre Source, menu Windows et cocher 'Group Windows.' Sauver la conf et relancer l'ému.

Zephyr (./46) :
Bah oui, je pourrais probablement faire une liste encore bien plus longue sur le manque de fonctionnalités d'OpenOffice par rapport à Word; ça n'empêche pas un bon nombre de personnes de les comparer d'une part, et même parfois de préférer le 1er. TiEmu a surement plein d'avantages (j'espère bien, sinon quel était l'intérêt de le développer ?), seulement sa dépendance à GTK suffit à largement les contrebalancer toutes, et à me faire préférer VTI.

J'admets que ces dépendances m'ont, par le passé causé des soucis et m'en cause parfois. Mais, c'est le prix à payer pour être portable. A l'époque où j'ai commencé à coder pour les TI (1999), il n'existait qu'un seul toolkit portable et libre: GTK. Qt n'était pas libre et wxWidget était une daube (et reste, à mon sens une daube car il calque l'API des MFC).
Lors de la sortie de QT4, j'ai envisagé le passage à Qt avec le GFM. Kevin m'a fait remarqué que le runtime QT4 était a peu près aussi gros que GTK. Le manque de temps (1 femme/2 enfants) pour m'investir sur un nouveau TK m'a fait rester sur GTK.

En clair et comme souvent, il n'existe pas de solutions miracles, juste des compromis.

Lionel Debroux (./57) :
J'ai regardé _rapidement_ l'API GTK+ dans la référence, et je n'ai pas vu de truc permettant de grouper plusieurs fenêtres séparées...
Mais ça fait longtemps qu'il y en a qui pensent que ça pourrait être utile, en particulier sous Windows: http://advogato.org/article/287.html date de 2001, quand même...
[EDIT: le lien que j'ai posté traite aussi de ./56]

gtk_window_set_transient_for(...)

<<
Dialog windows should be set transient for the main application window they were spawned from. This allows window managers to e.g. keep the dialog on top of the main window, or center the dialog over the main window. gtk_dialog_new_with_buttons() and other convenience functions in GTK+ will sometimes call gtk_window_set_transient_for() on your behalf.

On Windows, this function will and put the child window on top of the parent, much as the window manager would have done on X.
>>

Mais, c'est un hack léger.

roms (./77) :
Lors de la sortie de QT4, j'ai envisagé le passage à Qt avec le GFM. Kevin m'a fait remarqué que le runtime QT4 était a peu près aussi gros que GTK. Le manque de temps (1 femme/2 enfants) pour m'investir sur un nouveau TK m'a fait rester sur GTK.

C'est dommage, avec QT par exemple TiEmu aurait pu devenir réellement utilisable sous Windows :/

roms (./76) :
Si et c'est même dispo en option dans TiEmu: lancer le debugger, aller dans la fenetre Source, menu Windows et cocher 'Group Windows.' Sauver la conf et relancer l'ému.

Ce n'est pas ce qu'il entend par "grouper", je pense. Il me semble qu'il attend plutôt quelque chose du type MDI.

Martial Demolins (./62) :
Non, non et non, l'interface du débugueur n'est pas bien foutue. Comment exliquer qu'elle tienne dans une fenêtre de 200*300 pixels sous VTI, alors qu'elle ne tienne pas sous sur un écran 1800*1024

polices trop grosses?

Zephyr (./79) :
C'est dommage, avec QT par exemple TiEmu aurait pu devenir réellement utilisable sous Windows :/

Je préfère personnellement Qt à GTK+ (en tant qu'utilisateur de KDE), mais franchement je ne vois pas ce que ça changerait dans ce cas, c'est aussi un widget toolkit à installer et le runtime a à peu près la même taille.

Bah faut voir en fonction des bugs dont tu parles, mais personnellement je n'ai jamais installé le moindre "toolkit" pour faire fonctionner des applications en QT, et pourtant elles ont toujours fonctionné sans problème.

Zephyr (./79) :

roms (./77) :
Lors de la sortie de QT4, j'ai envisagé le passage à Qt avec le GFM. Kevin m'a fait remarqué que le runtime QT4 était a peu près aussi gros que GTK. Le manque de temps (1 femme/2 enfants) pour m'investir sur un nouveau TK m'a fait rester sur GTK.

C'est dommage, avec QT par exemple TiEmu aurait pu devenir réellement utilisable sous Windows :/

Je sais mais j'ai fait un choix de TK. Le remettre en question veut dire mettre à la poubelle des journées de développement/test et refaire la même chose avec QT.

Mes journées ne font que 24heures :-(

Zephyr (./83) :
Bah faut voir en fonction des bugs dont tu parles, mais personnellement je n'ai jamais installé le moindre "toolkit" pour faire fonctionner des applications en QT, et pourtant elles ont toujours fonctionné sans problème.

Je ne sais pas pour Romain, mais de mon côté, il n'est pas question de m'amuser à recompiler Qt (d'autant plus que c'est sans doute le bordel avec un cross-compilateur et que je n'utilise plus Window$) juste pour avoir une version statique et je ne retiens pas une bonne idée de distribuer des copies des DLLs (parce que ça élimine tout l'intérêt des DLLs), donc si je distribue des binaires utilisant Qt (et ça va venir bientôt avec KTIGCC 2), ça sera vraisemblablement avec le runtime partagé proposé par le projet kde-windows (KTIGCC 2 utilisera aussi les kdelibs, d'ailleurs).

C'est d'autant plus dommage pour KTIGCC2, il aurait été tellement plus simple à utiliser en "stand alone"...

Passe sous Linux, tu n'auras pas tous ces problèmes.

C'est ça oué, quelle bonne idée

Zephyr (./86) :
C'est d'autant plus dommage pour KTIGCC2, il aurait été tellement plus simple à utiliser en "stand alone"...

Je ne peux pas faire du standalone, il utilise la KatePart qui est une KPart, donc obligatoirement chargée en temps d'exécution.

ben ça peut très bien être chargé dynamiquement ^^ ce que veut dire Zephyr c'est qu'il faut pas qu'il y ait de dépendances vers d'autres packages qui pourraient potentiellement casser en cas d'upgrade d'un autre programme (i.e. que la dll soit dans le répertoire du programme et pas dans un répertoire partagé)


(euh sinon Kevin "doute" ne prend pas d'accent circonflexe [je me demande si je t'avais pas déjà dit ça y a lgtps d'ailleurs ])