1

voila, aujourd'hui g appris le delphi au taff tritop
c vraiment trop bidon comme langage
avatar
納 豆パワー!
I becamed a natto!!!1!one!

2

pencil
et cette belle interface avec huit mille fenêtres -> hummm!
avatar
fabetal_ > Hier, je me suis fait monter par un pote
redangel > et en chevals, ça donne quoi?
Nil> OMG I think I'm gay

3

-

4

Mais c'est super Visual Studio pour faire des dialogues etc.

5

jamais fait des app fenetre avec la lib de base de vcpp (s7il y en a une), j'utilise wxwindows (dla merde en fait aussi grin)
avatar
納 豆パワー!
I becamed a natto!!!1!one!

6

dla merde OUI, mais dla merde PORTABLE grin
avatar
fabetal_ > Hier, je me suis fait monter par un pote
redangel > et en chevals, ça donne quoi?
Nil> OMG I think I'm gay

7

-

8

par contre, ya tellement de possibilites ds delphi que tu sais pas koi choisir grin
avatar
納 豆パワー!
I becamed a natto!!!1!one!

9

j'ai fais du delphi et du vc++ et vc++ powaat largement plus mieux bien!

10

-

11

Mais c'est super Visual Studio pour faire des dialogues etc.
Pareil, quand t'as utilisé un peu Qt3 Designer, l'édition de boîtes de VC c'est de la merde en tube. Et je ne te parle même pas du passage des messages.

12

Finalement l'aide de delphi en japonais... hem...triso
avatar
納 豆パワー!
I becamed a natto!!!1!one!

13

Le passage des messages, c'est un coup a prendre ... au moins, c'est toujours pareil grin
Sinon, je ne connais pas vraiment Qt3 Designer sad

14

-

15

nEUrOO: qt designer te permet de dessiner des fenetres, définir les contraintes de redimensionnement (je connais pas delphi, mais je suppose qu'il doit le faire, c'est normalement une fonction de base), définir les événements et les actions.
Après, il s'intègre dans un projet (dans l'ide que tu veux, borland, visual studio, kdevelop, notepad) fait en Qt, qui remplace les messages par des signaux. Les signaux aussi c'est tout le temps pareil, et c'est beaucoup plus souple que les messages.
Qt inclut aussi le support pour l'internationalisation, la localisation et est portable à de nombreux systèmes, y compris certains systèmes embarqués comme des téléphones portables et des PDA.

16

Un boite de dialogue en MFC ca se fait en 5 secondes.. l'ajout d'un bouton et d'un evenement 2 sec...

17

Mouahahahahaaa. On voit que t'as jamais rien utilisé d'autre. Je ne parle pas d'une boite de dialogue bidon. T'as omis un certain nombre de détails dans mon post grin

"définir les contraintes de redimensionnement "

"définir les événements et les actions" => je n'entends pas par là la mise de code dans une fonction figée, mais l'attribution éventuellement dynamique d'un ensemble de handlers non prédéterminé pour un ou plusieurs événements. (c'était dit là : "Qt, qui remplace les messages par des signaux", mais comme tu as probablement jamais utilisé la sémantique slots-signaux, je comprends que tu l'aies pas vu)

"Qt inclut aussi le support pour l'internationalisation, la localisation et est portable à de nombreux systèmes, y compris certains systèmes embarqués comme des téléphones portables et des PDA."

Et encore j'ai oublié de parler de la gestion déplorable (inexistante ?) par mfc des boîtes à onglets, des différentes zones masquables, la sémantique objet foireuse (depuis quand faut faire un create après avoir fait un new ?), et j'en passe.

Et j'ai également oublié de préciser que Qt supporte en standard des interfaces de plugins génériques pour tes programmes, s'intègre tout seul avec opengl, est capable d'accéder à des bases de données locales et distantes sans que tu n'écrives une ligne de code pour le gérer, et est utilisable en C++/C/python/tcl/perl/PHP/ruby/caml/guile/scheme/java.
ok je suis peut-être un peu aggressif, mais comparer qt à mfc c'est comme comparer une course avec Carl Lewis à un cross des collèges. Je pense que ça l'aurait un peu vexé quand même.

18

Mouahahahahaaa. On voit que t'as jamais rien utilisé d'autre. Je ne parle pas d'une boite de dialogue bidon. T'as omis un certain nombre de détails dans mon post

... t'aime bien affirmer des conneries pour rien dire?

Apres Qt ca peut etre bien ou non perso je m'en fou... Kde supporte Qt et rien que ca ca me repugnesmile (ok c pas constructif, c juste un troll).

Perso pour les applis directement utilisables sur pda... je trouve ca inutile, car il faut certainement revoir l'interface graphique pour qu'elle soit mieux adapté à l'écran.
Les boites a onglets sont gérables etc... et j'ai troujours tout trouvé en mfc (composants activx etc..) utilisable directement et facilement.

De toute maniere j'aime pas les interfaces comme qt gtk etc.. quand je suis sous win, je veux l'api win quand je suis sous mac etc... parce que ce bordel (dont le principal auteur est linux) fait qu'on se retrouve avec une interface globale crade non normalisé et différente à chaque programme. (trop bien les apps a la fois X / qt / gtk .. sous nux j'adore ...).
Apres on me dit t'as qu'a utilisé kde t'aura que qt... mais alors la j'envoie chier...


19

... t'aime bien affirmer des conneries pour rien dire?
Hmm, à part "On voit que t'as jamais rien utilisé d'autre" je vois pas ce qui peut être faux. Et encore je pense ne pas être loin du vrai.
Apres Qt ca peut etre bien ou non perso je m'en fou... Kde supporte Qt et rien que ca ca me repugne
Nan c'est dans l'autre sens. Qt supporte Kde. Mais sinon effectivement je vois pas le rapport.
Perso pour les applis directement utilisables sur pda... je trouve ca inutile, car il faut certainement revoir l'interface graphique pour qu'elle soit mieux adapté à l'écran.
- il n'est pas nécessaire de revoir l'interface, Qt s'en occupe tout seul.
- Qt ne fait pas que du dessin, il fait abstraction pour la totalité des éléments du système.
Les boites a onglets sont gérables etc... et j'ai troujours tout trouvé en mfc (composants activx etc..) utilisable directement et facilement.
La gestion du contrôle d'onglets des mfc est déplorable. Tu es obligé de masquer et cacher toi-même les composants de chaque page.
quand je suis sous win, je veux l'api win quand je suis sous mac etc...
C'est exactement le contraire de la portabilité ce que tu cherches à faire.
parce que ce bordel
tu parles de quel bordel exactement ? parce que si je suis l'enchainement, c'est l'incompatibilité des différentes api le bordel. Dans ce cas je suis d'accord.
dont le principal auteur est linux
Que vient faire linux là-dedans ? Ce n'est qu'un pauvre noyau qui ne demande rien à personne, et qui est encore moins concerné par le graphisme.
on se retrouve avec une interface globale crade non normalisé et différente à chaque programme
Bien ! Tu veux la normalisation ? Ca tombe bien Qt l'apporte. Tout ce que tu développes en Qt utilisera les mêmes abstractions, les mêmes interfaces, et ce quel que soit le programme et quelle que soit la plateforme. Je vois pas ce qu'on peut demander de mieux.
trop bien les apps a la fois X / qt / gtk .. sous nux j'adore ...
- il n'existe pas à ma connaissance d'application faisant usage à la fois de qt et de gtk.
- Quand à X ça n'a aucun rapport, ce n'est pas un toolkit graphique, et Qt et gtk fournissent justement une abstraction au protocole sous-jacent. Le programme proprement dit n'utilise jamais Xlibs.
- Et le sous nux n'a aucun rapport non plus, puisque les applications qt tournent aussi bien sous Mac, sous X11 (donc hpux, gnu/linux, solaris, ...), sous Windows, ... sans changer le moindre caractère dans le code.

20

JS: Va voir un peu ce que fait Qt, je suis sur le cul pour sa simplicité là :]

21

t'as pas compris ce que je voulais dire...
quand t'es sous windows, une application bien porté est une application qui reprend l'api du system... et sous windows comme sous mac os, il y a une api de référence... qt sous windows c'est ridicule... d'ailleur sous nux avec gnome aussi... (je prefere gnome à kde mais là n'est pas le rapport... d'ailleur c pas pour ca que j'aime gnome).
je pourais dev toute mes apps avec l'api que j'ai fait avec sdl triso c portable sur plus de machine que qt, et en plus c bcp plus skinable... mais ca risque de dérouter un peu l'utilisateur et surcharger le system...

L'exemple sous linux c'est qu'il n'y a pas d'api de référence..et que par conséquence il n'y a aucune normalisation et qu'on se retrouve avec des apps sous gtk X11 qt... d'ailleur qt est peut etre pour toi géniale, mais pas forcement pour les tous les utilisateurs..
et puis j'ai deja programmé des apps sous X qui utilise ni qt ni gtk mais simplement X à l'aide de Xlib (quel joli non love).

22

JS: Va voir un peu ce que fait Qt, je suis sur le cul pour sa simplicité là :]
.
> je critique pas la simplicité d'ailleur j'ai déja utilisé qt avec python mais ca rien a voir avec c bien mal beau pas beau simple pas simple..

23

Mais avec Qt, tu utilises l'interface win sous win et l'interface mac sous mac.
Et Qt essaie au maximum en général, quand c'est possible, d'utiliser directement l'API du système sur lequel l'appli tourne.
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

24

heu il y a des composants qui fonctionnent de manieres différentes sous chaque plateforme.. qt propose une surcouche qui utilise au maximum l'api standard, tout en ne l'etant pas...
enfin c comme le java et les igraphiques...
d'ailleur les gas qui programme en delphi et qui s'amuse à imposer la couleur des composants, je trouve cela tout aussi ridicule...


25

ha et puis j'oubliai....
trop bien la licence qt.

26

./23> oui. Et tu utilises le protocole X11 sous X11.
mais pas forcement pour les tous les utilisateurs..
Explique-moi comment l'utilisateur voit que l'application utilise qt ?

[edit: euh je réponds ici à ./24 et 24 parce que là je fais un gros upload et je mets 3 minutes à reloader la page]
./24> non, rien à voir avec java. Quand tu utilises swing, c'est Java qui dessine tout, il laisse pas windows faire les dessins. Quand tu utilises Qt, Qt n'est pas plus éloigné de l'API windows que les mfc. Il fait réellement du Windows natif.

./25> Elle a quoi la license qt ? Elle est très bien.

27

JS> ton argument était que tu voulais que les interfaces des applications soient uniformes sur un même système, c'est le cas avec Qt, le fait que Qt est une surcouche de l'API standard est autre chose, n'essaie pas de te racrocher à ça...

Surtout que c'est un fabuleux avantage qui permet d'écrire des programmes compatibles entre toutes les plate-formes supportées par Qt.
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

28

JS> ton argument était que tu voulais que les interfaces des applications soient uniformes sur un même système, c'est le cas avec Qt, le fait que Qt est une surcouche de l'API standard est autre chose, n'essaie pas de te racrocher à ça...

heu tu vois toujours pas ou je veux en venir?
surcouche -> lourdeur & fonctionnement différent (légérement different parfois, mais différent).
et donc je suis quasiment sur que l'interactivité prog/user et prog/prog est différente

29

Sauf que là on n'est pas sur TI...
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

30

surcouche -> lourdeur & fonctionnement différent
N'imp. Qt n'apporte pas plus de lourdeur que les mfc (moins en fait, mais bon on va pas se mettre à mesurer les us).
(légérement different parfois, mais différent)
Nan ! Les applications Qt pour windows tournent en windows natif !

au fait et mon ./26 ?