Connexion avec TiEmu - Page 2

> Ce n'est pas un bogue, on n'a pas le droit de mettre -v dans les options du compilateur tout simplement.
Ah bon, pourquoi ? L'exit status n'est pas suffisant pour savoir s'il y a eu un problème ou pas ?
J'imagine que ce "-v" est un reste du temps où il n'y avait pas KTIGCC, justement: ça sert à avoir les statistiques du programme.

> et si tu mets -I ../../lib dans les options du compilateur?
C'est pas beau, mais bien sûr, cela fonctionne.

> Sinon, la solution correcte n'est pas un symlink, mais carrément une copie.
... avec les problèmes de mise à jour de l'un et pas de l'autre que cela pose
Un hardlink ? A ma connaissance, cela ne fonctionne pas non plus sous Windows, ce qui reste un problème pour "exttst".

Zephyr (./30) :
Qu'il y ait un installeur n'est pas très grave si il ne fait que ce qu'aurait fait une simple copie des fichiers dans leurs dossiers respectifs (i.e si il ne modifie pas le système, ce que fait GTK).

Quand il y a un installeur, en général, c'est parce que justement copier les fichiers dans un dossier ne suffit pas, sinon il n'y aurait pas besoin d'installeur!

Presque tous les installeurs touchent au répertoire %WINSYSDIR% (c:\windows\system32). Par exemple, celui de M$ Office fait ça. En l'occurrence, GTK+ ne fait même pas ça, il s'installe proprement dans un dossier à part (sélectionnable par l'utilisateur, par défaut c:\GTK), donc il touche moins au système que ces installeurs!

Une application en QT ne requiert pas de modifier son système pour fonctionner.

Si. Il faudra aussi installer un runtime Qt pour KTIGCC 2.

Lionel Debroux (./31) :
> Ce n'est pas un bogue, on n'a pas le droit de mettre -v dans les options du compilateur tout simplement.Ah bon, pourquoi ? L'exit status n'est pas suffisant pour savoir s'il y a eu un problème ou pas ?

Pas sûr.

J'imagine que ce "-v" est un reste du temps où il n'y avait pas KTIGCC, justement: ça sert à avoir les statistiques du programme.

Les flags du compilateur sont le mauvais endroit pour mettre ça alors vu que c'est le linker qui a besoin d'être verbose. Passer ça à la ligne de commande du tprbuilder (ce qui te donne aussi l'invocation exacte de tigcc) serait quand-même plus propre.

Kevin Kofler (./32) :
[Presque tous les installeurs touchent au répertoire %WINSYSDIR% (c:\windows\system32). Par exemple, celui de M$ Office fait ça. En l'occurrence, GTK+ ne fait même pas ça, il s'installe proprement dans un dossier à part (sélectionnable par l'utilisateur, par défaut c:\GTK), donc il touche moins au système que ces installeurs!

"Presque tous", certainement pas (ou alors j'aimerais bien une preuve); en revanche je suis d'accord pour dire que l'installation (voire toute la structure) de MS Office est pourrie, et il me semble que c'est principalement du au fait que l'application doit s'intégrer au système pour autoriser ses fonctionnalités (automation objets par exemple) dans d'autres programmes. Mais ça reste pourri, tout comme GTK.

Si. Il faudra aussi installer un runtime Qt pour KTIGCC 2.

Ah, je ne sais pas ce qu'il faut pour KTIGCC (si il faut installer encore un truc de plus, ça sera tout aussi pourri que TiEmu, et ça sera une raison pour maintenir un fork du TIGCC original), mais il me semble avoir déjà lancé des applications QT sans rien avoir installé sur mon système. Et quoi qu'il en soit, l'exemple de Firefox reste valide. Ou bien wxWidget dont vous parliez tout à l'heure, mais celui-ci produit des exécutables énormes.

KVIrc est une application QT, et je n'ai pas le souvenir d'avoir installé un runtime QT.
Sinon j'ai trouvé un TheGimp qui ne requiert pas GTK : http://www.mode83.net/gimp/ (et même que l'installeur enlève le GTK+ s'il est présent). Depuis, GTK(+) est un joli souvenir (de même que TiEmu :])

> sera une raison pour maintenir un fork du TIGCC original
Un fork du TIGCC _IDE_ original
Le reste de TIGCC ne dépend pas de Qt/GTK, donc cette raison-là n'est pas valide pour forker le reste de TIGCC.

Zephyr (./34) :
et il me semble que c'est principalement du au fait que l'application doit s'intégrer au système pour autoriser ses fonctionnalités (automation objets par exemple) dans d'autres programmes.

TiEmu doit faire ça aussi (interface automation OLE pour TIGCC IDE).

Mais ça reste pourri, tout comme GTK.

Tu n'utilises pas de traîtement de texte alors? Parce que OpenOffice.org utilise aussi un installeur...

Ah, je ne sais pas ce qu'il faut pour KTIGCC (si il faut installer encore un truc de plus, ça sera tout aussi pourri que TiEmu, et ça sera une raison pour maintenir un fork du TIGCC original), mais il me semble avoir déjà lancé des applications QT sans rien avoir installé sur mon système.

Il y en a sans doûte qui linkent Qt statiquement (l'installeur de KDE 4 pour Window$ fait ça), mais il faut recompiler Qt pour ça, et ce n'est pas la solution choisie par le portage de KDE 4 (sauf pour l'installeur). KTIGCC 2 va probablement utiliser les runtimes Qt 4 et KDE 4 du projet kde-windows.

Et quoi qu'il en soit, l'exemple de Firefox reste valide.

Firefox a aussi besoin d'un installeur, sinon il n'y aurait pas besoin de la version spéciale "Portable Firefox".

Ou bien wxWidget dont vous parliez tout à l'heure, mais celui-ci produit des exécutables énormes.

C'est normal si tu linkes toutes les libs statiquement, tu auras la même chose avec un GTK+ statique aussi.

Lionel Debroux (./36) :
> sera une raison pour maintenir un fork du TIGCC original
Un fork du TIGCC _IDE_ original

On n'a personne pour maintenir TIGCC IDE maintenant (et ça fait des mois que je cherche un mainteneur pour les composants Delphi, c'est trop tard maintenant, la suppression de tous les composants Delphi de TIGCC restants (remplacement par du C ou du C++) est déjà décidée), alors je ne vois pas d'où viendraient les développeurs Delphi pour un fork.

PS: La personne devra aussi forker le linker parce que l'interface DLL qui ne sert que pour ces composants Delphi sera supprimée.

Kevin Kofler (./37) :
Tu n'utilises pas de traîtement de texte alors? Parce que OpenOffice.org utilise aussi un installeur...

Pas le choix, mais disons qu'Office m'est bien plus utile que TiEmu, et surtout il n'existe pas d'alternative de la même qualité (pas la peine de parler de OpenOffice.org), donc je n'ai malheureusement pas le choix. Pour TiEmu, si : j'ai VTI.

Il y en a sans doûte qui linkent Qt statiquement (l'installeur de KDE 4 pour Window$ fait ça), mais il faut recompiler Qt pour ça, et ce n'est pas la solution choisie par le portage de KDE 4 (sauf pour l'installeur). KTIGCC 2 va probablement utiliser les runtimes Qt 4 et KDE 4 du projet kde-windows.

Firefox a aussi besoin d'un installeur, sinon il n'y aurait pas besoin de la version spéciale "Portable Firefox".

Oui mais comme dit précédemment, un installeur qui ne fait que de la copie de fichiers (et pour preuve justement, cette version spéciale)

C'est normal si tu linkes toutes les libs statiquement, tu auras la même chose avec un GTK+ statique aussi.

C'est un moindre mal, si ça apporte un affranchissement des dépendances (surtout compte tenue de l'augmentation de place qui est dérisoire comparée aux tailles des disques dur actuels)

Tiens, même Portable Firefox utilise un installeur (mais est transportable une fois installé).
Et ils utilisent un lanceur spécial pour éviter d'écrire dans les répertoires système.

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.

Ça revient à dire que tu n'acceptes que les frameworks M$ vu que c'est ceux-là qui vont se retrouver livrés avec Window$.
On ne risque pas de les utiliser ceux-là, pour plusieurs raisons:
* pas portables (rien que ça les retire déjà de notre considération)
* pas libres
* pas cross-compilables (je compile tous mes binaires Win32 sous Fedora)
Si on utilisait du .NET, ce serait du Mono avec GTK#. Donc une fois de plus GTK+ que tu détestes tant.

Zephyr (./39) :
Pas le choix, mais disons qu'Office m'est bien plus utile que TiEmu, et surtout il n'existe pas d'alternative de la même qualité (pas la peine de parler de OpenOffice.org), donc je n'ai malheureusement pas le choix. Pour TiEmu, si : j'ai VTI.

À ce titre-là, Notepad est une alternative à Word.

Kevin Kofler (./41) :
Ça revient à dire que tu n'acceptes que les frameworks M$ vu que c'est ceux-là qui vont se retrouver livrés avec Window$.

Ben c'est leur système et leur framework... un peu logique qu'il soit intégré non ? (btw, l'écriture correcte est "Windows")

À ce titre-là, Notepad est une alternative à Word.

En quoi Notepad est une alternative à Word ?

Tu peux taper du texte dedans. C'est loin d'avoir les mêmes fonctionnalités, mais VTI est loin d'avoir les fonctionnalités de TiEmu aussi!

VTI et TiEmu ont le même but, et à quelques fonctionnalités près, ils proposent la même base de services. La comparaison avec Notepad et Word me semble totalement à coté de la plaque, puisque ce sont des logiciels dont les cadres d'utilisation n'ont déjà strictement rien à voir...

Zephyr (./44) :
VTI et TiEmu ont le même but, et à quelques fonctionnalités près, ils proposent la même base de services.

"quelques fonctionnalités" comme:
* l'émulation des calculatrices actuelles (HW2 émulée correctement, TI-89 Titanium, Voyage 200)
* le débogueur C, essentiel pour les développeurs
* l'émulation correcte du matériel, qui fait que des logiciels qui ne marchent pas sur VTI marchent sur TiEmu, et qui pour un programmeur est aussi essentielle (par exemple, les programmes qui ne marchent que sur HW1 marchent sur VTI sans broncher, et boguent sur toute calculatrice réelle récente)
* le transfert avec les calculatrices réelles à travers le SilverLink (mais malheureusement pas le DirectLink, il y a des raisons techniques qui font qu'on ne pourra probablement pas proposer ça).
et j'en ai sans doûte oubliées. Les fonctionnalités proposées n'ont vraiment rien à voir!

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.

Le grand avantage de OpenOffice.org est la licence, ici c'est TiEmu qui a la licence libre, VTI contient plein de sources encombrées (sous des licences non-libres peut-être même pas compatibles entre elles, j'avais regardé VTI à un moment pour le débogueur de TIGCC, mais le nombre de problèmes de licence faisait que la moitié des sources était à jeter, et l'autre moitié était l'interface utilisateurs utilisant les classes propriétaires Borland, donc il ne restait plus rien ).

Kevin Kofler (./47) :
Le grand avantage de OpenOffice.org est la licence

Ça effectivement, c'est vrai (enfin pas tellement le fait que la licence soit différente, mais plutôt la conséquence : il est gratuit).

ici c'est TiEmu qui a la licence libre, VTI contient plein de sources encombrées (sous des licences non-libres peut-être même pas compatibles entre elles, j'avais regardé VTI à un moment pour le débogueur de TIGCC, mais le nombre de problèmes de licence faisait que la moitié des sources était à jeter, et l'autre moitié était l'interface utilisateurs utilisant les classes propriétaires Borland, donc il ne restait plus rien ).

On ne va pas relancer ici le troll sur le libre, mais pour faire simple : si je veux développer un programme sur Ti et que j'ai besoin d'un émulateur, je me fiche totalement du fait qu'il soit libre ou pas, du moment qu'il est gratuit (et encore, si l'un des deux est payant mais nettement mieux, je le prendrai).

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

Moi, monsieur !

> enfin pas tellement le fait que la licence soit différente, mais plutôt la conséquence: il est gratuit
Absolument rien à voir
En français, il n'y a aucune confusion entre "libre" et "gratuit", contrairement à "free" et "free" en anglais.
On peut parfaitement avoir du logiciel libre payant. Refuser l'usage commercial est une restriction non libre, c'est pour ça que la licence classique de TICT est incompatible avec la GPL.

Où est-ce que j'ai dit qu'être libre était équivalent à être gratuit ?

[edit] au fait, tu devrais utiliser la balise [cite], c'est bien plus lisible que tes ">" où la séparation entre le texte cité et ton propre texte n'est pas nette, et ça ne pose pas de problèmes avec les retours à la ligne.

(J'aime pas les "cite"...)

Où est-ce que j'ai dit qu'être libre était équivalent à être gratuit ?

Ben, dans ./48, que j'ai repris dans ./50, tu mets explicitement "il est gratuit" comme conséquence du fait que la licence soit différente. Et cette licence est libre: http://www.openoffice.org/about_us/new.html , "Licenses OpenOffice.org use the LGPL (GNU Lesser General Public License). See Licenses and Licensing FAQ."

Et alors ? Il est gratuit oui, mais c'est pas forcément lié au fait que la licence soit libre, il se trouve que là comme souvent c'est le cas, mais il ne me semble pas avoir établi le lien nulle part...

(tu n'aimes peut-être pas, mais comme tout le monde les utilise ici, c'est la façon la plus lisible de citer quelqu'un; qui plus est ta méthode pour citer rend tes posts incompréhensible quand comme moi on garde la fenêtre de son navigateur assez peu large, et que les lignes citées précédées de ">" vont à la ligne et ne sont donc plus précédées du tout)

Pour contribuer à la discussion au bout de laquelle personne ne se mettra d'accord (tiens ça faisait longtemps ) :
Comme indiqué en ./46, il suffit d'un défaut dans une application pour qu'elle laisse un mauvais goût, quoiqu'il y ait de l'autre côté de la balance, ça ne s'équilibre malheureusement pas comme ça.
Le défaut pour ma part est ergonomique (GTK+ mal intégré à Windows, multi-fenêtre polluant, etc.) Pourtant toutes les fonctionnalités dont je rêvais, que VTI n'avait pas où qu'il n'y avait pas dans les premières versions de TiEmu y sont - avec Roms c'est de l'on-demand. Parfois je me sens même coupable de lui avoir demandé de bosser sur des trucs, mais de préférer plus souvent VTI à l'utilisation...

Pour le multi-fenêtre, il faut s'y habituer, mais c'est vraiment la seule manière de proposer toutes ces informations sans les rendre minuscules (genre désassemblage de 2 lignes à la fois en police de taille 8).

On a déjà réduit à un minimum le nombre de fenêtres ouvertes par défaut. S'il y en a toujours trop, je peux aussi cacher la console GDB de Insight par défaut (Insight ne l'affiche pas par défaut). Mais du tout en une fenêtre, je ne vois vraiment pas comment faire.

Bof, il suffit d'utiliser un windows manager digne de ce nom. Une application n'a pas à cacher les défaults et lacunes des windows manager.

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]

On peut utiliser du X11 et du Win32 pour reparenter les fenêtres. Mais ce n'est pas vraiment une solution. Je préfère encore les fenêtres séparées aux fenêtres dans d'autres fenêtres (MDI).

Mais ce n'est pas vraiment une solution.

Ce serait mieux que rien, surtout sous Windows, où on préfère habituellement le MDI aux fenêtres séparées
J'ai déjà fait un peu de X11 il y a deux ans, mais je ne me souviens pas d'avoir reparenté des fenêtres. C'est si compliqué que ça ?

[EDIT: +s]

de toute façon le MDI ne serait pas adapté non plus, ce qu'il faut c'est simplement des toolbars dockables ^^ (c'est par exemple ce que fait visual studio)