TiLP/TiEmu: arrêt du développement - Page 7

Au fait, je vois plein de contradictions et de mauvaise foi dans vos arguments. Pour en montrer un exemple dans l'argumentation de squalyl:

Je dis:

Kevin Kofler (./169) :
tous les gens qui peuvent utiliser VTI peuvent aussi utiliser TiEmu

Il me répond:

squalyl (./170) :
sauf quand ils cherchent vti dans google, ou qu'un pote le leur passe.

Donc il nous prétend qu'il est impossible d'utiliser TiEmu si on a déjà VTI (c'est bien ça que l'usage de "sauf" à mon affirmation qu'ils peuvent utiliser TiEmu veut dire! Si ce n'est pas ça qu'il a voulu dire, alors il est tenu à regarder "sauf" dans un dictionnaire ). Alors évidemment (cette affirmation étant on ne peut plus fausse) je réponds:

Kevin Kofler (./172) :
Les émulateurs ne s'excluent pas l'un l'autre, ils peuvent facilement installer TiEmu (ou bientôt Emu-TIGCC) en plus de VTI.

C'est-à-dire: si l'utilisateur a déjà VTI (émulateur non supporté), ça ne lui empêche pas d'installer aussi un émulateur supporté (TiEmu/Emu-TIGCC), qui sera celui utilisé par TIGCC. Il n'est même pas obligé de supprimer VTI (même si ça ne fait pas de mal). Et là tout d'un coup il nous sort:

squalyl (./177) :
2 si tu oses dire "en plus de vti" pourquoi n'est il plus supporté?

Quel rapport avec la discussion au dessus? C'est au mieux un argument à côté de la plaque, voire carrément une contradiction. Je dis "en plus de VTI" parce qu'il n'y a aucune obligation de supprimer VTI pour installer un émulateur supporté, c'est tout. Je n'ai jamais prétendu autre chose!

Et en plus il m'accuse d'incohérences alors que ce que j'ai dit est parfaitement cohérent et que c'est sa réponse qui est totalement incohérente avec celle d'avant!

Godzil (./180) :

Kevin Kofler (./179) :
L'utilisateur ne perd aucune fonctionnalité en passant du couple (vieux TIGCC, VTI) au couple (nouveau TIGCC, TiEmu ou Emu-TIGCC).

Si l'utilisateur Windows (aka au moins 90% des (ex) utilisateurs de tigcc) n'ont plus un soft utilisant une IHM NATIVE, Legere, et j'en passe

Le fait d'utiliser GTK+ est un détail d'implémentation, plein de logiciels utilisent des contrôles IHM non-natifs, même Office! En pratique, on ne remarque que peu ou pas la différence de nos jours, grâce au "thème natif" (qui utilise l'API de theming du système d'exploitation pour l'affichage).

quel détail, plusieurs dizaines de Mo quand même!

open office est plus joli que gtk.

tiemu est moche.

Kevin Kofler (./180) :

J'en ai rien a foutre de ton avis, on parle pas de toi kevin kofler centre de l'autriche mais bien de tous les autres.

Ce n'est pas un avis personnel, c'est un fait appuyé entre autre par mon expérience personnelle (qui prouve que je ne parle pas sans savoir).

merci de m'apprendre le français, je voulais dire la situation suivante
"hé machin comment tu fais pour exécuter des programmes ti sur un PC?"
"bah heu chais pas prends vti c'est ça qu'il utilise mon pote" ( "vé-té-hi" plus facile à prononcer et à retenir que té-hi-hé-mu, en plus)
(tu peux pas nier ce genre de comportement, dans le même genre y'en a qui en sont toujours à preos 0.71)

Kevin Kofler (./180) :
As-tu déjà essayé de déboguer un programme C avec le débogueur de VTI? Non?

oui. je trouve que tiemu a ENORMEMENT grossi sous prétexte d'intégrer Insight, ce qui tire tcltk (©redhat, décidément t'as des actions chez eux ou quoi )
C'est un problème de choix de développement.

Kevin Kofler (./182) :
Donc il nous prétend qu'il est impossible d'utiliser TiEmu si on a déjà VTI (c'est bien ça que l'usage de "sauf" à mon affirmation qu'ils peuvent utiliser TiEmu veut dire! Si ce n'est pas ça qu'il a voulu dire, alors il est tenu à regarder "sauf" dans un dictionnaire )

Kevin Kofler (./182) :
Et en plus il m'accuse d'incohérences alors que ce que j'ai dit est parfaitement cohérent et que c'est sa réponse qui est totalement incohérente avec celle d'avant!

c'est parfaitement cohérent mais tu te régales de tourner mes paroles à ton avantage, ho ho ho

Vous pouvez pas faire une compilation spéciale windows pour Ti-Emu qui appelerait l'API windows pour avoir une interface simple et en un seul exe? Parce que c'est le seul point positif de VTI et c'est vrai que c'est relou d'installer GTK de merde sous windows.

je crois que ça se faisait au début mais apparemment l'archi interne de l'appli supporte mal plusieurs ihm donc ça a été viré. (haa le mvc j'en ai chié au début mais ça roxe )

C'est très ch**** de faire une même appli avec deux toolkits graphiques différents, c'est pour ça que Romain a arrêté de le faire dans TILP.

Y'a un truc que je me demande depuis longtemps : il n'existe pas de toolkit qui ne chercherait pas à réinventer la roue et à faire le café, mais qui se contenterait de wrapper simplement les fonctions natives ?

Les applications visées ne sont pas très lourdes sur le plan IHM, et les primitives utilisées (fenêtres, boutons, menus...) existent nativement aussi bien sous Windows que sous Linux. Pareil pour le modèle événementiel de base (savoir si on a cliqué sur un objet, etc.).

Pourquoi ça n'existe pas ?

C'est plus ou moins ce que fait wxWidget. Le problème c'est que les widget systèmes n'ont pas un comportement très compatible.

Donc, plus on veut quelque chose avec un fonctionnement facile, puissant et un comportement identique quel que soit le système, plus on finit fatalement par réinventer la roue comme Qt et Gtk sous Windows.

Je dirais que wxWidget est un mauvais exemple. Par contre Qt 4 est quand même une très bonne bibliothèque puisque porter un programme sous Windows, MacOSX et Linux ne demande aucun effort supplémentaire du programmeur.

Et GTK est supayr moche, j'ai toujours regretté que le choix de Romain se soit porté sur ce toolkit.

Pourtant Qt fait la même chose que GTK+, ils utilisent aussi seulement les fonctions d'affichage natives. Ils le font mieux (à peu près tout est mieux fait dans Qt que dans GTK+ ), mais il n'y a pas de différence fondamentale à ce niveau.

squalyl (./184) :
merci de m'apprendre le français, je voulais dire la situation suivante
"hé machin comment tu fais pour exécuter des programmes ti sur un PC?"
"bah heu chais pas prends vti c'est ça qu'il utilise mon pote" ( "vé-té-hi" plus facile à prononcer et à retenir que té-hi-hé-mu, en plus)(tu peux pas nier ce genre de comportement, dans le même genre y'en a qui en sont toujours à preos 0.71)

Et bah, même si un débutant essaie d'abord VTI suite aux mauvais conseils d'une autre personne, ça ne l'empêche pas de passer à un émulateur plus puissant et s'intégrant à TIGCC par la suite.

C'est quoi ton problème? Que l'utilisateur qui essaie d'utiliser TIGCC avec VTI n'y arrivera pas? TIGCC dit clairement qu'il faut TiEmu (ce sera bientôt Emu-TIGCC), pas VTI, il suffit de savoir lire, on apprend ça autour de l'âge de 6 ans en général, parfois avant, parfois après, mais c'est quand-même un prérequis pour programmer.

oui. je trouve que tiemu a ENORMEMENT grossi sous prétexte d'intégrer Insight, ce qui tire tcltk

Je te parle de confort d'utilisation, tu me parles de taille, ça n'a aucun rapport.

L'ordinateur n'est pas une calculatrice de poche, il y a de la place pour un logiciel puissant.

©redhat, décidément t'as des actions chez eux ou quoi

Non.

C'est un problème de choix de développement.

Dis-moi comment j'aurais pu obtenir une interface à GDB de la même qualité de Insight en un temps raisonnable? J'ai aussi évalué les frontends GTK+ et KDE et même DDD, j'ai vu que non seulement ils proposent moins de fonctionnalités (par exemple, les interfaces graphiques ne permettent en général pas de rentrer des commandes GDB), mais en plus ils tournent hors processus, ce qui n'allait pas du tout avec la manière de laquelle GDB est intégré à TiEmu, ça aurait compliqué de beaucoup l'interopérabilité et l'intégration entre les 2 débogueurs (bas niveau ("style VTI") et haut niveau (GDB)).

c'est parfaitement cohérent

Non, c'est incohérent, tu utilises des mots dans un sens différent de leur sens réel.

mais tu te régales de tourner mes paroles à ton avantage, ho ho ho

Non, je donne leur sens aux mots. Exprime-toi plus clairement si tu veux que je comprenne. N'oublie pas que tu parles à un étranger.

squalyl (./184) :
(©redhat, décidément t'as des actions chez eux ou quoi )

ya pas d'argent dans le monde de Kevin

Zerosquare (./188) :
Y'a un truc que je me demande depuis longtemps : il n'existe pas de toolkit qui ne chercherait pas à réinventer la roue et à faire le café, mais qui se contenterait de wrapper simplement les fonctions natives ?

SWT \o/

C'est en Java.

Godzil (./180) :
tu aurais tu plutot les nommer

KevinEmu
KevinLP
KevinGcc

(et ça serait assez représentatif, en plus )

(mais je suis curieux de voir s'il va faire la même chose avec Fedora : dégoûter tous les autres programmeurs de Fedora \o/ )

Kevin Kofler (./195) :
C'est en Java.

C'est sacrément mieux que GTK.

Mais ce n'est pas Made In Kevin

Kevin Kofler (./192) :
Je te parle de confort d'utilisation, tu me parles de taille, ça n'a aucun rapport.

oh si, tu sens pas de confort à télécharger un truc léger sur lequel tu n'as qu'à cliquer pour que ça se lance? oui évidemment apt-get se charge de tout, mais je te rappelle que l'utilisateur moyen de tigcc est sous windows.

Kevin Kofler (./192) :
Dis-moi comment j'aurais pu obtenir une interface à GDB de la même qualité de Insight en un temps raisonnable?

on ne peut pas et c'est justement ça le problème. Tu as voulu faire entrer un cube dans un trou rond pour gagner du temps. TiEmu est un outil dédié, il a sa place à coté d'un debugger dédié, pas d'un outil générique. Même si ça prend plus de temps.

Nil (./197) :
C'est sacrément mieux que GTK.

Carrément.

Nil (./194) :

Zerosquare (./188) :
Y'a un truc que je me demande depuis longtemps : il n'existe pas de toolkit qui ne chercherait pas à réinventer la roue et à faire le café, mais qui se contenterait de wrapper simplement les fonctions natives ?

SWT \o/

Il réinventa pas l'intégralité mais au moins une bonne moitié de la roue.

C'est symptomatique du problème des toolkits multi-plateformes. Si on veut faire un toolkit avancé, il y a forcément des chose qui ne sont pas possibles de la même manière suivant les toolkits natifs, et donc soit on limite les fonctionnalités, soit un fait du code commun. SWT se voulant un toolkit avancé, il y a pas mal de chose qui sont refaite quelle que soit la plateforme(les onglets par exemples)

Oui, je te l'accorde, mais c'est quand même sacrément moins contraignant (il y a une JVM sur tous les PC OEM ou presque, et la plupart des gens en installent une par la suite) et plus agréable pour l'utilisateur que GTK. Enfin, je trouve.

geogeo (./201) :
Oui, je te l'accorde, mais c'est quand même sacrément moins contraignant (il y a une JVM sur tous les PC OEM ou presque, et la plupart des gens en installent une par la suite) et plus agréable pour l'utilisateur que GTK. Enfin, je trouve.

Pour moi, quitte a faire du java autant utiliser Swing qui a le mérite d'avoir un look&feel natif pas mauvais et de ne pas ajouter de dépendances supplémentaires.

geogeo (./190) :
Je dirais que wxWidget est un mauvais exemple. Par contre Qt 4 est quand même une très bonne bibliothèque puisque porter un programme sous Windows, MacOSX et Linux ne demande aucun effort supplémentaire du programmeur.

C'est quoi, pour toi, le problème avec wxWidget?

Uther (./202) :

geogeo (./201) :
Oui, je te l'accorde, mais c'est quand même sacrément moins contraignant (il y a une JVM sur tous les PC OEM ou presque, et la plupart des gens en installent une par la suite) et plus agréable pour l'utilisateur que GTK. Enfin, je trouve.

Pour moi, quitte a faire du java autant utiliser Swing qui a le mérite d'avoir un look&feel natif pas mauvais et de ne pas ajouter de dépendances supplémentaires

Yep c'est vrai (d'ailleurs, j'utilise généralement Swing). Mais on parle d'appels à des composants vraiment natifs, et si je ne m'abuse, seul SWT permet ça, non ?

Nil (./197) :
[SWT ]est sacrément mieux que GTK.

Sous l'OS que j'utilise, c'est une surcouche à GTK+, donc ça peut difficilement être "sacrément mieux".

squalyl (./199) :
oh si, tu sens pas de confort à télécharger un truc léger sur lequel tu n'as qu'à cliquer pour que ça se lance?

Ce n'est pas directement lié à la taille ça, mais au processus d'installation. L'installeur de TiEmu essaie de faire tout pour toi, il te télécharge même automatiquement GTK+ si tu ne l'as pas ou pas en une version suffisante. Si ça ne marche pas, c'est un problème à corriger. (Je suis au courant d'un problème avec Pidgin qui installe un runtime GTK+ sans l'enregistrer correctement dans la registry, soi-disant "pour éviter les conflits avec d'autres applications", du coup TiEmu ne se lance pas. Il y aura un workaround pour ça dans la prochaine version de mon installeur (probablement la première version de Emu-TIGCC, à moins que je n'en fasse un pour TiEmu 3.03).)

Kevin Kofler (./192) :
Dis-moi comment j'aurais pu obtenir une interface à GDB de la même qualité de Insight en un temps raisonnable?

on ne peut pas et c'est justement ça le problème. Tu as voulu faire entrer un cube dans un trou rond pour gagner du temps. TiEmu est un outil dédié, il a sa place à coté d'un debugger dédié, pas d'un outil générique. Même si ça prend plus de temps.

Es-tu volontaire pour passer les prochaines années à développer ça? Si oui, j'attends ton résultat en 2014. En attendant, Insight remplit très bien la tâche demandée.

Uther (./202) :
Pour moi, quitte a faire du java autant utiliser Swing qui a le mérite d'avoir un look&feel natif pas mauvais et de ne pas ajouter de dépendances supplémentaires.

Swing sux! Problème nº1: Le look&feel natif n'est pas par défaut, le développeur doit l'activer manuellement. C'est totalement à l'envers et ça fait que plein de programmes traînent avec un look&feel non natif. Problème nº2: Il n'y a pas de look&feel natif sous GNU/Linux, du moins dans OpenJDK. (On trouve des références parlant d'un look&feel GTK+, mais ce look&feel n'est pas présent dans la version actuelle de OpenJDK.) Problème nº3: Ça rame à fond!

Nil (./203) :

Uther (./202) :

geogeo (./201) :
Oui, je te l'accorde, mais c'est quand même sacrément moins contraignant (il y a une JVM sur tous les PC OEM ou presque, et la plupart des gens en installent une par la suite) et plus agréable pour l'utilisateur que GTK. Enfin, je trouve.

Pour moi, quitte a faire du java autant utiliser Swing qui a le mérite d'avoir un look&feel natif pas mauvais et de ne pas ajouter de dépendances supplémentaires

Yep c'est vrai (d'ailleurs, j'utilise généralement Swing). Mais on parle d'appels à des composants vraiment natifs, et si je ne m'abuse, seul SWT permet ça, non ?

Comme je disais SWT n'est qu'a moitié natif, une bonne partie des ses composants sont non natifs.

Kevin Kofler (./204) :
Swing sux! Problème nº1: Le look&feel natif n'est pas par défaut, le développeur doit l'activer manuellement. C'est totalement à l'envers et ça fait que plein de programmes traînent avec un look&feel non natif. Problème nº2: Il n'y a pas de look&feel natif sous GNU/Linux, du moins dans OpenJDK. (On trouve des références parlant d'un look&feel GTK+, mais ce look&feel n'est pas présent dans la version actuelle de OpenJDK.) Problème nº3: Ça rame à fond!

1: C'est au développeur de choisir s'il veux un look natif. J'aurais aussi préféré avoir un l&f système par défaut mais au fond ce n'est qu'un détail réglé en une ligne de code.
2: Ça, c'est un problème d'open JDK pas de Java
3: C'est une légende urbaine. Un programme bien fait ne rame pas. En tout cas pas plus que l'équivalent SWT.


Ceci dit pour revenir au sujet le code de Tiemu étant en C. je pense qu'un toolkit comme Qt ou wxWidget est clairement plus adapté que le Java.

Kevin Kofler (./205) :
Le look&feel natif n'est pas par défaut, le développeur doit l'activer manuellement.

on t'a déja expliqué que c'est pour avoir le même L&F partout.

Sinon c'est vrai que penser à écrire
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); c'est vachement dur

et sinon j'ai jamais fait de programme swing qui rame.

Kevin Kofler (./204) :

Nil (./197) :
[SWT ]est sacrément mieux que GTK.

Sous l'OS que j'utilise, c'est une surcouche à GTK+, donc ça peut difficilement être "sacrément mieux".

Ce qui touche hmmm... 5% des utilisateurs ? Enfin, on a bien compris que tu faisais des programmes pour toi, que tu mettais de façon princière à disposition de la communauté (et non l'inverse). C'est mal "mal", remarque. Mais faut arrêter de vouloir faire croire l'inverse.

Uther (./205) :
3: C'est une légende urbaine. Un programme bien fait ne rame pas. En tout cas pas plus que l'équivalent SWT.

Quand j'utilisais encore Me, j'ai utilisé quelques apps Swing, elles ramaient tous à fond, leakaient de la mémoire et finissaient rapidement les ressources système.

squalyl (./206) :
on t'a déja expliqué que c'est pour avoir le même L&F partout.

… ce qui n'est pas un avantage.

Sinon c'est vrai que penser à écrire
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); c'est vachement dur

On dirait que oui vu le nombre de programmes qui ne le font pas.

Enfin, le pire, ce sont les programmes qui forcent des look&feels perso qu'aucun autre programme n'utilise… Cette inculture paraît particulièrement diffusée dans le monde Swing, ce genre de crétinisme est rare avec Qt.

Kevin Kofler (./208) :

Uther (./205) :
3: C'est une légende urbaine. Un programme bien fait ne rame pas. En tout cas pas plus que l'équivalent SWT.

Quand j'utilisais encore Me, j'ai utilisé quelques apps Swing, elles ramaient tous à fond, leakaient de la mémoire et finissaient rapidement les ressources système.

Tu sais que Windows et Java ont légèrement évolué depuis 2000 ? Ça fait pas loin de 10 ans... Finalement, t'es un peu obsolète

Kevin Kofler (./208) :
Enfin, le pire, ce sont les programmes qui forcent des look&feels perso qu'aucun autre programme n'utilise… Cette inculture paraît particulièrement diffusée dans le monde Swing, ce genre de crétinisme est rare avec Qt.

Non, le pire, ce sont les programmes de 2 Mo qui font télécharger 200 Mo de dépendances

Kevin Kofler (./208) :


Enfin, le pire, ce sont les programmes qui forcent des look&feels perso qu'aucun autre programme n'utilise… Cette inculture paraît particulièrement diffusée dans le monde Swing, ce genre de crétinisme est rare avec Qt.

Tu veux dire GTK ou QT sous Windows ? \o/