kdewin foutage de geule - Page 3

Thibaut (./56) :
Kevin : Ce qui serait pas mal, c'est d'arrêter le développement de TIGCC pour Windows pour ne garder que Linux. Si la programmation sur TI68k avait encore la côte, ça permettrait à pas mal de jeunes de découvrir Linux

Ça revient un peu à ça, le fait de concentrer tout sur KTIGCC, la version W32 ne serait plus qu'un portage de la version *nix.

Pour revenir sur terre, que veux-tu dire là :

Qt Designer est très bien en tant qu'éditeur de formulaires, mais catastrophique en tant qu'EDI

?

Qt Designer est prévu pour éditer des dialogues ou des fenêtres. Sous Qt 3, il a aussi un minimum de fonctionnalités d'un EDI (gestion de projets, éditeur de code), mais il manque plein de fonctionnalités (par exemple impossible de compiler depuis Qt Designer) et l'éditeur est pourri (on voit clairement que ce n'est pas une KatePart...), donc c'est limite inutilisable en tant qu'EDI. Ces fonctionnalités d'EDI ont été complètement retirées de Qt Designer 4, il ne fait plus que ce pour quoi il a été conçu: éditer des dialogues/fenêtres.

Kevin Kofler (./59) :
Et on ne peut pas supporter des OS antiques pour toute éternité, tu t'attends qu'on gère la version 3.1 aussi tant qu'on y est? (À titre d'information, cette version n'a jamais été supportée par TIGCC, et elle était plus récente à l'époque que Me, l'OS le plus récent parmi ceux prévus pour l'abandon, l'est maintenant: 1999-1992=7 années, 2008-2000=8 années. 95 a carrément 13 années!!!) Je trouve normal que les logiciels récents ne tournent pas sur les OS antiques, surtout si ces OS ne sont plus du tout supportés par leur producteur. Même un OS de 8 années (2000) est actuellement supporté par KDE! Je ne vois pas quoi demander de plus.

Et d'un autre côté, quand on parle de prog TI, tu dis qu'il faut garder la compatibilité avec des kernels antiques comme UniOS ou DoorsOS 2 poids, 2 mesures ?

Thibaut (./60) :
squalyl et Flanker : Il y a plein d'excellents programmes GPL qui sont portés vers Windows. Je ne suis pas stratège, mais je vois ça comme une erreur.Si Linux veut continuer sa progression, ne doit-il pas s'enrichir en qualité et en quantité, de façon exclusive ? Si tout est disponible sur Windows, système que tout le monde a, qui ira essayer Linux ?

Ah oué, c'est clair que c'est une IDE pour calculette obsolète qui va faire changer le monde

En plus, les portages pour Windows sont souvent bogués (qui que soit le responsable), ce qui n'est pas bon pour l'image du logiciel libre.

Ils n'ont qu'à faire des logiciels moins buggués...

Thibaut (./60) :
C'est quoi que vous appelez un éditeur de formulaire ?

Formulaire = fenêtre ou dialogue dans ce contexte. Désolé, j'ai été impregné du vocabulaire de VB à une époque, c'est difficile de m'en débarasser. C'est clair qu'à part dans le monde de Visual Studio et de .NET, pratiquement personne n'utilise ce terme bizarre.

OK. Ils comptent faire un vrai RAD à terme ?
Est-ce que y'a une suite de développement du même genre sous Gnome ?

Flanker : Je ne suis pas contre discuter sérieusement...

tu donnes pas cette image.

un EDI Qt est inutile, y'en a déja plein en plus.

Il n'y a absolument rien dans Qt, GTK+ ou wxWidgets qui te permettait de faire la même chose (du genre, QSyntaxHighlighter) ?

Utiliser KDE faisait partie de mes spécifications de départ, donc je n'ai même pas regardé ailleurs.

Si c'était dans la spec que tu t'es fixée, forcément...
C'est difficile de prévoir l'avenir, et je ne sais pas si j'aurais fait mieux à ta place, mais ce n'était manifestement pas une bonne idée de te fixer ça dans la spec. Cf. la difficulté d'installation pour la grosse majorité d'utilisateurs Windowsiens, plus élevée que si tu avais écrit en Qt.

Mais je te signale quand-même que QSyntaxHighlighter n'existait pas à l'époque.

OK.

Kevin Kofler (./51) :
Il était aussi clair dès le départ que le logiciel n'allait pas rester Qt-only: les dialogues de fichiers KDE sont nettement plus pratiques que ceux de Qt/X11, l'intégration au système (toujours dans le contexte *nix) est meilleure avec KDE

Tu veux dire qu'on a le choix entre faire un programme Qt-only mal intégré à Linux ou un programme KDE très mal intégré à Windows ? C'est pas possible de compiler un programme Qt avec un switch genre --use-kde pour qu'il s'intègre bien au système sans dépendre de libs spécifiques à la plateforme ?

squalyl : Ah bon. Ma question n'apparaît pas sérieuse ? Je crois surtout que Flanker ne veut pas la prendre au sérieux. yAronet est un terrain de jeu pour certains... C'est tellement rigolo de poster des au lieu de chercher à comprendre ce que dit l'autre.

Il existe déjà des suites de développement complètement intégrées pour KDE ? A ma connaissance, l'ensemble le plus abouti est QTdesigner + KDevelop, mais on n'a pas encore d'IDE complet (comme C++Builder, VisualC++, NetBeans, etc). C'est ce qu'on appelle un RAD je crois.

Il était aussi clair dès le départ que le logiciel n'allait pas rester Qt-only: les dialogues de fichiers KDE sont nettement plus pratiques que ceux de Qt/X11, l'intégration au système (toujours dans le contexte *nix) est meilleure avec KDE

Tu veux dire qu'on a le choix entre faire un programme Qt-only mal intégré à Linux ou un programme KDE très mal intégré à Windows ?

Hmm, Kevin, c'est quoi qui te semble si pratique dans les dialogues de fichier KDE (ceux de Kate, par exemple), par rapport à ceux de Qt/X11 (ceux de LyX, par exemple) ?
LyX n'utilise manifestement pas un menu KDE, mais pour autant, l'intégration est loin d'être mauvaise. Dans LyX, il y a plusieurs options quand on clique droit sur un fichier / répertoire.
En tout cas, l'intégration est meilleure que celle de GTK+ pur et son gros dialogue pas toujours pratique (exemple SciTE) ou wxWidgets (exemple Audacity), qui utilise GTK+ sous *nix.

il doit vouloir utiliser les KIO machin, c'est vrai que c'est über pratique d'éditer un projet tigcc SANS FICHIERS RELATIFS sur un montage sftp ou samba

moi je renonce à la discussion.

Voyons, on _peut_ mettre des chemins relatifs dans un projet TIGCC
Certes, ça donne un projet qui builde avec l'IDE et pas avec tprbuilder (ou le contraire, suivant le sens dans lequel on fait la modif), ce comportement ne suivant pas ce que font divers autres IDE... mais la compatibilité antérieure, c'est mieux !


Sérieusement, Kevin (parce que là, on écrit plein de trucs qui ne font rien qu'à te vexer ): j'aimerais que tu répondes à ./71.

Et une interface façon Turbo-C, ça pèse combien ?

Kochise

Que veux-tu dire par "interface façon Turbo-C" ?

Gné ?

Fenêtré DOS

Kochise

sur falcon ça doit le faire mais sur un OS moderne on peut faire un truc léger et mieux que ça quand même

Lionel Debroux (./71) :
Hmm, Kevin, c'est quoi qui te semble si pratique dans les dialogues de fichier KDE (ceux de Kate, par exemple), par rapport à ceux de Qt/X11 (ceux de LyX, par exemple) ?

Le look&feel est différent de celui de KDE (=> mauvaise intégration système) et il ne respecte pas les réglages de KDE, notamment clic simple vs. double. À l'époque de Qt 3, c'était encore pire, il manquait par exemple la barre des lieux favoris à gauche, et les icônes étaient codées en dur (impossible d'utiliser les icônes KDE - Qt 4 s'intègre mieux là), bref on se croyait vraiment en 1995!

Mais de toute façon, la dépendance KDE de KTIGCC va beaucoup plus loin que les dialogues de fichiers. J'utilise des classes K* de partout, il y a plein de classes utiles dans KDE qu'il n'y a pas dans Qt pur. Et remplacer la KatePart par un autre composant reviendrait à réécrire une grande partie de l'application. Bref, ça ne sert à rien de discuter de ça, la dépendance KDE n'est pas optionnelle. Et puis je ne vois pas du tout l'intérêt, étant donné que KDE 4 est (ou plutôt sera, pour être plus honnêtes) multiplateforme.

En tout cas, l'intégration est meilleure que celle de GTK+ pur et son gros dialogue pas toujours pratique (exemple SciTE) ou wxWidgets (exemple Audacity), qui utilise GTK+ sous *nix.

Je sais bien que le dialogue de fichiers de GTK+ est catastrophique, c'est bien pour ça que les logiciels LPG peuvent utiliser les dialogues KDE (et W32 aussi, d'ailleurs).

Pollux (./69) :
Tu veux dire qu'on a le choix entre faire un programme Qt-only mal intégré à Linux ou un programme KDE très mal intégré à Windows ?

Je te signale que KFileDialog peut utiliser le dialogue natif W32 dans KDE 4.1. (C'est le réglage par défaut, modifiable par l'utilisateur s'il veut pouvoir utiliser la transparence réseau KIO dans les applications qui la gèrent.) D'ailleurs, le thème par défaut est aussi le style natif, comme dans une application Qt pure. Bref, je ne vois pas du tout comment une application KDE "s'intègrerait mal".

squalyl (./72) :
il doit vouloir utiliser les KIO machin, c'est vrai que c'est über pratique d'éditer un projet tigcc SANS FICHIERS RELATIFS sur un montage sftp ou samba

Désolé de te décevoir, mais KTIGCC ne gère (à l'heure actuelle) pas la transparence réseau.

merci de toutes ces infos.

Il n'y a pas de clones libres de delphi ?

Il y a Lazarus, mais le code de TIGCC IDE ne compile pas du tout avec, il y a notamment plein d'appels à l'API W32 de partout, et la dernière fois que j'ai essayé, il y avait aussi des problèmes de syntaxe.

Et sinon, je signale que Lazarus utilise GTK+ sur toutes les plateformes, bref, ce n'est pas du "natif" au même point que Delphi non plus.

Kevin Kofler (./79) :

Pollux (./69) :
Tu veux dire qu'on a le choix entre faire un programme Qt-only mal intégré à Linux ou un programme KDE très mal intégré à Windows ?

Je te signale que KFileDialog peut utiliser le dialogue natif W32 dans KDE 4.1. (C'est le réglage par défaut, modifiable par l'utilisateur s'il veut pouvoir utiliser la transparence réseau KIO dans les applications qui la gèrent.) D'ailleurs, le thème par défaut est aussi le style natif, comme dans une application Qt pure. Bref, je ne vois pas du tout comment une application KDE "s'intègrerait mal".

Je ne parlais pas de ça, je pensais surtout à la lourdeur hallucinante (un framework de 200 Mo pour un petit éditeur de texte ?)

C'est un framework au même niveau que la JRE ou .NET (bon OK, il n'y a pas la VM, mais il y a la librairie de classes, qui est de loin le composant le plus grand dans une JRE), frameworks qui mesurent aussi dans l'ordre de 100 MO au moins.

Mais ça reste 200Mo à installer pour un simple éditeur de texte, quelle qu'en soit la raison

KTIGCC n'est pas un simple éditeur de textes, c'est un EDI avec coloration syntaxique, complétion (avec connaissance des fonctions de TIGCCLIB), gestion de projets, compilation depuis l'EDI, intégration avec l'émulateur et débogueur TiEmu en un clic, possibilité de tester les logiciels sur la calculatrice réelle en un clic, dialogues d'options du projet contenant toutes les options de TIGCC (sauf celles réservées à l'usage avancé, genre NO_CALC_DETECT) etc.

Kevin Kofler (./85) :
C'est un framework au même niveau que la JRE ou .NET (bon OK, il n'y a pas la VM, mais il y a la librairie de classes, qui est de loin le composant le plus grand dans une JRE), frameworks qui mesurent aussi dans l'ordre de 100 MO au moins.

installeur de Java : 15 Mo
installeur de .NET 2.0 : 22 Mo

C'est pas vraiment le même ordre de grandeur

Ouai et ca prend combien de ram sous Windows? parce que ces lib s'il y a une dépendance il doit bien les charger non?

Tout n'est pas chargé par KTIGCC, il y a des libs dans les kdelibs que KTIGCC ne charge pas (mais ils sont dans le paquetage kdelibs, donc j'ai dû les compter dans la taille à télécharger), il y a aussi pas mal de cette taille qui est prise par des icônes, qui évidemment ne sont pas toutes chargées en même temps.