je fais quelquechose comme :
int main()
{
string pattern;
...
cout << "entrez le pattern";
cin >> pattern;
cin.get(); // pour virer le enter du buffer pour apres
balayage cache
recherche du pattern
affochage
}
ok tout marche super
je rajoute juste un truc :
...
cin.get();
cout << pattern[0];
...
donc juste un affichage du premier caractere, un truc bien neutre quoi
et la , la recherche echoue et donne 0 resultats !!!
quelque soit le code de recherche, en quoi le simple fait d afficher le
premier caractere d une string peut il changer quoique ce soit ?????
une idee ? :-)
@+
ricky... je sais pas si les reveillons me reussissent moi :)
C'est un point de vue du problème. Un autre est qu'en C++, les choses simples doivent rester simples et les choses complexes doivent être possibles, sinon rendues simples. Il doit être possible d'enseigner C++ de manière simple ; de nos jours, les GUI sont devenus des domaines non-négligeables en programmation ; il doit être possible et relativement simple d'utiliser des notions de GUI dans un programme C++. Refuser de voir ce problème ne fait qu'encourager la confusion, des solutions « vendor lock-ins » qui bénéficient peu à l'utilisateur.
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution `normee', elle va ressembler pas mal a ce que fait qt.
(et je trouve que pour un `lock-in' des vendeurs, leurs conditions sont infiniment plus acceptables que la plupart des autres vendeurs)
In article <m365dw60hp.fsf@merlin.cs.tamu.edu>,
Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
C'est un point de vue du problème. Un autre est qu'en C++, les choses
simples doivent rester simples et les choses complexes doivent être
possibles, sinon rendues simples. Il doit être possible d'enseigner
C++ de manière simple ; de nos jours, les GUI sont devenus des
domaines non-négligeables en programmation ; il doit être possible et
relativement simple d'utiliser des notions de GUI dans un programme C++.
Refuser de voir ce problème ne fait qu'encourager la confusion, des
solutions « vendor lock-ins » qui bénéficient peu à l'utilisateur.
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution `normee',
elle va ressembler pas mal a ce que fait qt.
(et je trouve que pour un `lock-in' des vendeurs, leurs conditions sont
infiniment plus acceptables que la plupart des autres vendeurs)
C'est un point de vue du problème. Un autre est qu'en C++, les choses simples doivent rester simples et les choses complexes doivent être possibles, sinon rendues simples. Il doit être possible d'enseigner C++ de manière simple ; de nos jours, les GUI sont devenus des domaines non-négligeables en programmation ; il doit être possible et relativement simple d'utiliser des notions de GUI dans un programme C++. Refuser de voir ce problème ne fait qu'encourager la confusion, des solutions « vendor lock-ins » qui bénéficient peu à l'utilisateur.
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution `normee', elle va ressembler pas mal a ce que fait qt.
(et je trouve que pour un `lock-in' des vendeurs, leurs conditions sont infiniment plus acceptables que la plupart des autres vendeurs)
kanze
(Marc Espie) wrote in message news:<c1govl$1gln$...
In article , Gabriel Dos Reis wrote:
C'est un point de vue du problème. Un autre est qu'en C++, les choses simples doivent rester simples et les choses complexes doivent être possibles, sinon rendues simples. Il doit être possible d'enseigner C++ de manière simple ; de nos jours, les GUI sont devenus des domaines non-négligeables en programmation ; il doit être possible et relativement simple d'utiliser des notions de GUI dans un programme C++. Refuser de voir ce problème ne fait qu'encourager la confusion, des solutions « vendor lock-ins » qui bénéficient peu à l'utilisateur.
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution `normee', elle va ressembler pas mal a ce que fait qt.
Est-ce que ce n'est pas QT qui utilise un préprocesseur, plutôt que du C++ pûr ?
Sur le plan technique, d'après le très peu que j'ai vu, j'aime Fresco, mais ce n'est pas celui qui a le vent en poupe. Aussi, du fait qu'il y a moins d'utilisateurs, et moins de gens qui y travaillent, c'est probablement moins complet. Et enfin, ce n'est pas vraiment ce qu'on cherche pour une norme C++ -- l'un des arguments pour Fresco est son indépendance du langage, du fait que l'interface client est définie en Corba.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
espie@tetto.gentiane.org (Marc Espie) wrote in message
news:<c1govl$1gln$1@biggoron.nerim.net>...
In article <m365dw60hp.fsf@merlin.cs.tamu.edu>,
Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
C'est un point de vue du problème. Un autre est qu'en C++, les choses
simples doivent rester simples et les choses complexes doivent être
possibles, sinon rendues simples. Il doit être possible d'enseigner
C++ de manière simple ; de nos jours, les GUI sont devenus des
domaines non-négligeables en programmation ; il doit être possible et
relativement simple d'utiliser des notions de GUI dans un programme
C++. Refuser de voir ce problème ne fait qu'encourager la confusion,
des solutions « vendor lock-ins » qui bénéficient peu à
l'utilisateur.
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution
`normee', elle va ressembler pas mal a ce que fait qt.
Est-ce que ce n'est pas QT qui utilise un préprocesseur, plutôt que du
C++ pûr ?
Sur le plan technique, d'après le très peu que j'ai vu, j'aime Fresco,
mais ce n'est pas celui qui a le vent en poupe. Aussi, du fait qu'il y a
moins d'utilisateurs, et moins de gens qui y travaillent, c'est
probablement moins complet. Et enfin, ce n'est pas vraiment ce qu'on
cherche pour une norme C++ -- l'un des arguments pour Fresco est son
indépendance du langage, du fait que l'interface client est définie en
Corba.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
(Marc Espie) wrote in message news:<c1govl$1gln$...
In article , Gabriel Dos Reis wrote:
C'est un point de vue du problème. Un autre est qu'en C++, les choses simples doivent rester simples et les choses complexes doivent être possibles, sinon rendues simples. Il doit être possible d'enseigner C++ de manière simple ; de nos jours, les GUI sont devenus des domaines non-négligeables en programmation ; il doit être possible et relativement simple d'utiliser des notions de GUI dans un programme C++. Refuser de voir ce problème ne fait qu'encourager la confusion, des solutions « vendor lock-ins » qui bénéficient peu à l'utilisateur.
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution `normee', elle va ressembler pas mal a ce que fait qt.
Est-ce que ce n'est pas QT qui utilise un préprocesseur, plutôt que du C++ pûr ?
Sur le plan technique, d'après le très peu que j'ai vu, j'aime Fresco, mais ce n'est pas celui qui a le vent en poupe. Aussi, du fait qu'il y a moins d'utilisateurs, et moins de gens qui y travaillent, c'est probablement moins complet. Et enfin, ce n'est pas vraiment ce qu'on cherche pour une norme C++ -- l'un des arguments pour Fresco est son indépendance du langage, du fait que l'interface client est définie en Corba.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Richard Delorme
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution `normee', elle va ressembler pas mal a ce que fait qt.
Est-ce que ce n'est pas QT qui utilise un préprocesseur, plutôt que du C++ pûr ?
Oui, c'est lui qui utilise moc (pour Meta-Object-Compiler) et c'est peut-être là le point fort de Qt. Ça permet d'utiliser de nouveaux mots clés (signals, slots, emit) qui simplifient la programmation événementielle.
Sur le plan technique, d'après le très peu que j'ai vu, j'aime Fresco, mais ce n'est pas celui qui a le vent en poupe. Aussi, du fait qu'il y a moins d'utilisateurs, et moins de gens qui y travaillent, c'est probablement moins complet. Et enfin, ce n'est pas vraiment ce qu'on cherche pour une norme C++ -- l'un des arguments pour Fresco est son indépendance du langage, du fait que l'interface client est définie en Corba.
Le problème de Fresco est qu'il m'a l'air encore très expérimental. Sinon, un autre GUI bien pensé, simple et écrit en C++ est BeOS.
-- Richard
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution
`normee', elle va ressembler pas mal a ce que fait qt.
Est-ce que ce n'est pas QT qui utilise un préprocesseur, plutôt que du
C++ pûr ?
Oui, c'est lui qui utilise moc (pour Meta-Object-Compiler) et c'est
peut-être là le point fort de Qt. Ça permet d'utiliser de nouveaux mots
clés (signals, slots, emit) qui simplifient la programmation événementielle.
Sur le plan technique, d'après le très peu que j'ai vu, j'aime Fresco,
mais ce n'est pas celui qui a le vent en poupe. Aussi, du fait qu'il y a
moins d'utilisateurs, et moins de gens qui y travaillent, c'est
probablement moins complet. Et enfin, ce n'est pas vraiment ce qu'on
cherche pour une norme C++ -- l'un des arguments pour Fresco est son
indépendance du langage, du fait que l'interface client est définie en
Corba.
Le problème de Fresco est qu'il m'a l'air encore très expérimental.
Sinon, un autre GUI bien pensé, simple et écrit en C++ est BeOS.
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution `normee', elle va ressembler pas mal a ce que fait qt.
Est-ce que ce n'est pas QT qui utilise un préprocesseur, plutôt que du C++ pûr ?
Oui, c'est lui qui utilise moc (pour Meta-Object-Compiler) et c'est peut-être là le point fort de Qt. Ça permet d'utiliser de nouveaux mots clés (signals, slots, emit) qui simplifient la programmation événementielle.
Sur le plan technique, d'après le très peu que j'ai vu, j'aime Fresco, mais ce n'est pas celui qui a le vent en poupe. Aussi, du fait qu'il y a moins d'utilisateurs, et moins de gens qui y travaillent, c'est probablement moins complet. Et enfin, ce n'est pas vraiment ce qu'on cherche pour une norme C++ -- l'un des arguments pour Fresco est son indépendance du langage, du fait que l'interface client est définie en Corba.
Le problème de Fresco est qu'il m'a l'air encore très expérimental. Sinon, un autre GUI bien pensé, simple et écrit en C++ est BeOS.
-- Richard
Jean-Marc Bourguet
Richard Delorme writes:
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution `normee', elle va ressembler pas mal a ce que fait qt. Est-ce que ce n'est pas QT qui utilise un préprocesseur, plutôt que du
C++ pûr ?
Oui, c'est lui qui utilise moc (pour Meta-Object-Compiler) et c'est peut-être là le point fort de Qt. Ça permet d'utiliser de nouveaux mots clés (signals, slots, emit) qui simplifient la programmation événementielle.
Je n'ai regarde QT et gtkmm que de tres loin, mais qu'est-ce que ce "moc" apporte de plus que les signaux de libsig++ ou de boost? (A part peut-etre fonctionner sur des versions de compilateur en retard sur l'implementation de la norme).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Richard Delorme <abulmo@nospam.fr> writes:
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution
`normee', elle va ressembler pas mal a ce que fait qt.
Est-ce que ce n'est pas QT qui utilise un préprocesseur, plutôt que du
C++ pûr ?
Oui, c'est lui qui utilise moc (pour Meta-Object-Compiler) et c'est
peut-être là le point fort de Qt. Ça permet d'utiliser de nouveaux mots
clés (signals, slots, emit) qui simplifient la programmation événementielle.
Je n'ai regarde QT et gtkmm que de tres loin, mais qu'est-ce que ce
"moc" apporte de plus que les signaux de libsig++ ou de boost? (A
part peut-etre fonctionner sur des versions de compilateur en retard
sur l'implementation de la norme).
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution `normee', elle va ressembler pas mal a ce que fait qt. Est-ce que ce n'est pas QT qui utilise un préprocesseur, plutôt que du
C++ pûr ?
Oui, c'est lui qui utilise moc (pour Meta-Object-Compiler) et c'est peut-être là le point fort de Qt. Ça permet d'utiliser de nouveaux mots clés (signals, slots, emit) qui simplifient la programmation événementielle.
Je n'ai regarde QT et gtkmm que de tres loin, mais qu'est-ce que ce "moc" apporte de plus que les signaux de libsig++ ou de boost? (A part peut-etre fonctionner sur des versions de compilateur en retard sur l'implementation de la norme).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Richard Delorme
Richard Delorme writes:
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution `normee', elle va ressembler pas mal a ce que fait qt.
Est-ce que ce n'est pas QT qui utilise un préprocesseur, plutôt que du C++ pûr ?
Oui, c'est lui qui utilise moc (pour Meta-Object-Compiler) et c'est peut-être là le point fort de Qt. Ça permet d'utiliser de nouveaux mots clés (signals, slots, emit) qui simplifient la programmation événementielle.
Je n'ai regarde QT et gtkmm que de tres loin, mais qu'est-ce que ce "moc" apporte de plus que les signaux de libsig++ ou de boost? (A part peut-etre fonctionner sur des versions de compilateur en retard sur l'implementation de la norme).
En terme de fonctionnalité, on a la même chose dans boost ou libsig++, ou même dans une implémentation utilisant des callbacks classiques, mais, à mon avis, la syntaxe Qt est beaucoup plus simple.
-- Richard
Richard Delorme <abulmo@nospam.fr> writes:
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution
`normee', elle va ressembler pas mal a ce que fait qt.
Est-ce que ce n'est pas QT qui utilise un préprocesseur, plutôt que du
C++ pûr ?
Oui, c'est lui qui utilise moc (pour Meta-Object-Compiler) et c'est
peut-être là le point fort de Qt. Ça permet d'utiliser de nouveaux mots
clés (signals, slots, emit) qui simplifient la programmation événementielle.
Je n'ai regarde QT et gtkmm que de tres loin, mais qu'est-ce que ce
"moc" apporte de plus que les signaux de libsig++ ou de boost? (A
part peut-etre fonctionner sur des versions de compilateur en retard
sur l'implementation de la norme).
En terme de fonctionnalité, on a la même chose dans boost ou libsig++,
ou même dans une implémentation utilisant des callbacks classiques,
mais, à mon avis, la syntaxe Qt est beaucoup plus simple.
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution `normee', elle va ressembler pas mal a ce que fait qt.
Est-ce que ce n'est pas QT qui utilise un préprocesseur, plutôt que du C++ pûr ?
Oui, c'est lui qui utilise moc (pour Meta-Object-Compiler) et c'est peut-être là le point fort de Qt. Ça permet d'utiliser de nouveaux mots clés (signals, slots, emit) qui simplifient la programmation événementielle.
Je n'ai regarde QT et gtkmm que de tres loin, mais qu'est-ce que ce "moc" apporte de plus que les signaux de libsig++ ou de boost? (A part peut-etre fonctionner sur des versions de compilateur en retard sur l'implementation de la norme).
En terme de fonctionnalité, on a la même chose dans boost ou libsig++, ou même dans une implémentation utilisant des callbacks classiques, mais, à mon avis, la syntaxe Qt est beaucoup plus simple.
-- Richard
kanze
Richard Delorme wrote in message news:<403df601$0$5910$...
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution `normee', elle va ressembler pas mal a ce que fait qt.
Est-ce que ce n'est pas QT qui utilise un préprocesseur, plutôt que du C++ pûr ?
Oui, c'est lui qui utilise moc (pour Meta-Object-Compiler) et c'est peut-être là le point fort de Qt. Ça permet d'utiliser de nouveaux mots clés (signals, slots, emit) qui simplifient la programmation événementielle.
Il y a de pour et de contre. Mon expérience avec des GUI, c'est surtout en Java. Où on s'en tire très bien sans de nouveaux mots clés -- la seule vraie faiblesse de Java que j'ai trouvé ici, c'est que les collections (par exemple, des objets qui attendent un évenement) ne peuvent être que d'Object (et non, par exemple, Action). Problème qui n'existera pas en C++.
Sur le plan technique, d'après le très peu que j'ai vu, j'aime Fresco, mais ce n'est pas celui qui a le vent en poupe. Aussi, du fait qu'il y a moins d'utilisateurs, et moins de gens qui y travaillent, c'est probablement moins complet. Et enfin, ce n'est pas vraiment ce qu'on cherche pour une norme C++ -- l'un des arguments pour Fresco est son indépendance du langage, du fait que l'interface client est définie en Corba.
Le problème de Fresco est qu'il m'a l'air encore très expérimental.
En effet. En fait, le vrai problème, à mon avis, c'est qu'il est encore très expérimental tout en étant assez ancien. Après tout, Fresco, c'est le nouveau nom de Berlin, qui lui se base sur Interviews (qui est aussi l'inspiration de Java Swing -- donc, pas d'hier). Alors, ou bien, il n'y a pas assez de gens qui y travaillent pour le faire avancer, ou bien, ils s'y perdent dans le côté expérimental, sans se figer sur un résultat pratique. (Comme tu sais sans doute, quelque soit le programme, on peut toujours l'améliorer. Alors, si on veut qu'il soit utilisé, il vient un moment où il faut dire : c'est assez bon comme ça, malgré ses défauts, et qu'il faut le figer, pour s'adresser aux questions pratiques de la diffusion, de la documentation, de la formation, de la maintenance...)
Sinon, un autre GUI bien pensé, simple et écrit en C++ est BeOS.
Je ne le connais pas. À vrai dire, je n'ai rencontré Fresco qu'en rémontant la filière Interviews -- je trouve Swing pas trop mal fait dans l'ensemble (malgré quelques détails ratés), et je cherchais d'où il était venu, pour voir quelles autres idées qu'il a pû y avoir.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Richard Delorme <abulmo@nospam.fr> wrote in message
news:<403df601$0$5910$7a628cd7@news.club-internet.fr>...
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution
`normee', elle va ressembler pas mal a ce que fait qt.
Est-ce que ce n'est pas QT qui utilise un préprocesseur, plutôt que
du C++ pûr ?
Oui, c'est lui qui utilise moc (pour Meta-Object-Compiler) et c'est
peut-être là le point fort de Qt. Ça permet d'utiliser de nouveaux
mots clés (signals, slots, emit) qui simplifient la programmation
événementielle.
Il y a de pour et de contre. Mon expérience avec des GUI, c'est surtout
en Java. Où on s'en tire très bien sans de nouveaux mots clés -- la
seule vraie faiblesse de Java que j'ai trouvé ici, c'est que les
collections (par exemple, des objets qui attendent un évenement) ne
peuvent être que d'Object (et non, par exemple, Action). Problème qui
n'existera pas en C++.
Sur le plan technique, d'après le très peu que j'ai vu, j'aime
Fresco, mais ce n'est pas celui qui a le vent en poupe. Aussi, du
fait qu'il y a moins d'utilisateurs, et moins de gens qui y
travaillent, c'est probablement moins complet. Et enfin, ce n'est
pas vraiment ce qu'on cherche pour une norme C++ -- l'un des
arguments pour Fresco est son indépendance du langage, du fait que
l'interface client est définie en Corba.
Le problème de Fresco est qu'il m'a l'air encore très expérimental.
En effet. En fait, le vrai problème, à mon avis, c'est qu'il est encore
très expérimental tout en étant assez ancien. Après tout, Fresco, c'est
le nouveau nom de Berlin, qui lui se base sur Interviews (qui est aussi
l'inspiration de Java Swing -- donc, pas d'hier). Alors, ou bien, il n'y
a pas assez de gens qui y travaillent pour le faire avancer, ou bien,
ils s'y perdent dans le côté expérimental, sans se figer sur un résultat
pratique. (Comme tu sais sans doute, quelque soit le programme, on peut
toujours l'améliorer. Alors, si on veut qu'il soit utilisé, il vient un
moment où il faut dire : c'est assez bon comme ça, malgré ses défauts,
et qu'il faut le figer, pour s'adresser aux questions pratiques de la
diffusion, de la documentation, de la formation, de la maintenance...)
Sinon, un autre GUI bien pensé, simple et écrit en C++ est BeOS.
Je ne le connais pas. À vrai dire, je n'ai rencontré Fresco qu'en
rémontant la filière Interviews -- je trouve Swing pas trop mal fait
dans l'ensemble (malgré quelques détails ratés), et je cherchais d'où il
était venu, pour voir quelles autres idées qu'il a pû y avoir.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Richard Delorme wrote in message news:<403df601$0$5910$...
Moi j'aime bien qt. J'espere beaucoup que, s'il y a une solution `normee', elle va ressembler pas mal a ce que fait qt.
Est-ce que ce n'est pas QT qui utilise un préprocesseur, plutôt que du C++ pûr ?
Oui, c'est lui qui utilise moc (pour Meta-Object-Compiler) et c'est peut-être là le point fort de Qt. Ça permet d'utiliser de nouveaux mots clés (signals, slots, emit) qui simplifient la programmation événementielle.
Il y a de pour et de contre. Mon expérience avec des GUI, c'est surtout en Java. Où on s'en tire très bien sans de nouveaux mots clés -- la seule vraie faiblesse de Java que j'ai trouvé ici, c'est que les collections (par exemple, des objets qui attendent un évenement) ne peuvent être que d'Object (et non, par exemple, Action). Problème qui n'existera pas en C++.
Sur le plan technique, d'après le très peu que j'ai vu, j'aime Fresco, mais ce n'est pas celui qui a le vent en poupe. Aussi, du fait qu'il y a moins d'utilisateurs, et moins de gens qui y travaillent, c'est probablement moins complet. Et enfin, ce n'est pas vraiment ce qu'on cherche pour une norme C++ -- l'un des arguments pour Fresco est son indépendance du langage, du fait que l'interface client est définie en Corba.
Le problème de Fresco est qu'il m'a l'air encore très expérimental.
En effet. En fait, le vrai problème, à mon avis, c'est qu'il est encore très expérimental tout en étant assez ancien. Après tout, Fresco, c'est le nouveau nom de Berlin, qui lui se base sur Interviews (qui est aussi l'inspiration de Java Swing -- donc, pas d'hier). Alors, ou bien, il n'y a pas assez de gens qui y travaillent pour le faire avancer, ou bien, ils s'y perdent dans le côté expérimental, sans se figer sur un résultat pratique. (Comme tu sais sans doute, quelque soit le programme, on peut toujours l'améliorer. Alors, si on veut qu'il soit utilisé, il vient un moment où il faut dire : c'est assez bon comme ça, malgré ses défauts, et qu'il faut le figer, pour s'adresser aux questions pratiques de la diffusion, de la documentation, de la formation, de la maintenance...)
Sinon, un autre GUI bien pensé, simple et écrit en C++ est BeOS.
Je ne le connais pas. À vrai dire, je n'ai rencontré Fresco qu'en rémontant la filière Interviews -- je trouve Swing pas trop mal fait dans l'ensemble (malgré quelques détails ratés), et je cherchais d'où il était venu, pour voir quelles autres idées qu'il a pû y avoir.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
