je cherche un gestionnaire de fenêtre/framework écrit en C++ pour win32
capable d'être compilé sous MSC, GNU ou Borland (genre MFC) : que me
conseilleriez vous ?
Merci.
>en court, depuis le début je ne vois pas en quoi un lib. IHM serait >plus compilo-dépendante que n'importe quelle autre lib.
Moi non plus. Le seul truc, c'est que plus une bibliothèque est grosse, plus elle a de chances de contenir du code incorrect. Et les bibliothèques d'IHM sont généralement assez grosses.
>; et "compilo >dépendant" sous windows, où les rares survivants ont toujours copi és >au define près le compilo MS, ça fait très peu de dépendances.
Ça dépend ce que tu entends par "survivant". On trouve du code compilable sous VC++ 6, qui n'est compatible ni avec g++, ni avec Borland C++ 5.x, ni avec VC++ 2003.
On Jun 19, 1:20 am, Fabien LE LEZ <grams...@gramster.com> wrote:
On Thu, 19 Jun 2008 00:01:44 +0200, Sylvain SF
<sylv...@boiteaspam.info>:
>en court, depuis le début je ne vois pas en quoi un lib. IHM serait
>plus compilo-dépendante que n'importe quelle autre lib.
Moi non plus. Le seul truc, c'est que plus une bibliothèque est
grosse, plus elle a de chances de contenir du code incorrect. Et les
bibliothèques d'IHM sont généralement assez grosses.
>; et "compilo
>dépendant" sous windows, où les rares survivants ont toujours copi és
>au define près le compilo MS, ça fait très peu de dépendances.
Ça dépend ce que tu entends par "survivant". On trouve du code
compilable sous VC++ 6, qui n'est compatible ni avec g++, ni avec
Borland C++ 5.x, ni avec VC++ 2003.
>en court, depuis le début je ne vois pas en quoi un lib. IHM serait >plus compilo-dépendante que n'importe quelle autre lib.
Moi non plus. Le seul truc, c'est que plus une bibliothèque est grosse, plus elle a de chances de contenir du code incorrect. Et les bibliothèques d'IHM sont généralement assez grosses.
>; et "compilo >dépendant" sous windows, où les rares survivants ont toujours copi és >au define près le compilo MS, ça fait très peu de dépendances.
Ça dépend ce que tu entends par "survivant". On trouve du code compilable sous VC++ 6, qui n'est compatible ni avec g++, ni avec Borland C++ 5.x, ni avec VC++ 2003.
James Kanze
On Jun 19, 1:20 am, Fabien LE LEZ wrote:
On Thu, 19 Jun 2008 00:01:44 +0200, Sylvain SF :
>en court, depuis le début je ne vois pas en quoi un lib. IHM >serait plus compilo-dépendante que n'importe quelle autre >lib.
Moi non plus. Le seul truc, c'est que plus une bibliothèque est grosse, plus elle a de chances de contenir du code incorrect. Et les bibliothèques d'IHM sont généralement assez grosses.
Il y a aussi le fait que les bibliothèques d'IMH font forcément appel à des fonctionalités propres au système ; le code qui marche sous Windows ne marche pas sous X, et vice versa. Ce qui réduit les chances qu'elle a été portée à un autre compilateur : si j'ai du code qui ne fonctionne que sous Windows, g++ n'est plus un cible important.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jun 19, 1:20 am, Fabien LE LEZ <grams...@gramster.com> wrote:
On Thu, 19 Jun 2008 00:01:44 +0200, Sylvain SF
<sylv...@boiteaspam.info>:
>en court, depuis le début je ne vois pas en quoi un lib. IHM
>serait plus compilo-dépendante que n'importe quelle autre
>lib.
Moi non plus. Le seul truc, c'est que plus une bibliothèque
est grosse, plus elle a de chances de contenir du code
incorrect. Et les bibliothèques d'IHM sont généralement assez
grosses.
Il y a aussi le fait que les bibliothèques d'IMH font forcément
appel à des fonctionalités propres au système ; le code qui
marche sous Windows ne marche pas sous X, et vice versa. Ce qui
réduit les chances qu'elle a été portée à un autre
compilateur : si j'ai du code qui ne fonctionne que sous
Windows, g++ n'est plus un cible important.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
>en court, depuis le début je ne vois pas en quoi un lib. IHM >serait plus compilo-dépendante que n'importe quelle autre >lib.
Moi non plus. Le seul truc, c'est que plus une bibliothèque est grosse, plus elle a de chances de contenir du code incorrect. Et les bibliothèques d'IHM sont généralement assez grosses.
Il y a aussi le fait que les bibliothèques d'IMH font forcément appel à des fonctionalités propres au système ; le code qui marche sous Windows ne marche pas sous X, et vice versa. Ce qui réduit les chances qu'elle a été portée à un autre compilateur : si j'ai du code qui ne fonctionne que sous Windows, g++ n'est plus un cible important.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Patrick 'Zener' Brunet
Bonsoir
"Christian PANEL" a écrit dans le message de news: 48567e6b$0$4643$
je cherche un gestionnaire de fenêtre/framework écrit en C++ pour win32 capable d'être compilé sous MSC, GNU ou Borland (genre MFC) : que me conseilleriez vous ?
Ca dépend de ce que vous voulez faire exactement.
Il ne suffit pas que ça se compile ni même que ce soit fonctionnel. Il faut encore que ça respecte les règles de style, explicites ou implicites, de la plateforme visée.
Ce qui inclut tout le look mais aussi les accélérateurs clavier, l'intégration complète aux menus et autres toolboxes du système, etc.
Et la seule bonne réponse à tout ça, c'est le même outil que celui qui a été utilisé pour faire tout le reste de l'IHM du système, ou celle que chaque utilisateur a choisie si ce choix existe.
J'ai déjà vu des librairies fondées sur le principe du dénominateur commun, mais objectivement, il est à craindre qu'elles soient parsemées de trous d'implémentation, car on ne peut pas mettre dans le même outil des choses parfois antagonistes. On en arrive toujours à se satisfaire d'avoir réussi l'essentiel...
Et je ne parle pas de la mode des skins, absolument superflus voire aberrants pour l'ergonomie, mais donc parfaitement indispensables pour un nombre croissant d'utilisateurs :o)
AMHA la meilleure solution est de découpler autant que possible le moteur du logiciel de son IHM, en prenant un maximum de recul au niveau du moteur et de son interface formelle, et l'IHM devient alors un produit annexe, aussi interchangeable que possible, et dépouillé au maximum de l'intelligence du process. Les technologies de linkage dynamique pour de tels composants sont assez au point...
Ce qui vous permet de traiter l'IHM comme un sous-produit +/- ludique, transposable, sous-traitable, parallélisable, testable séparément, évaluable par des experts en look & feel et autres critères de mode, que l'aspect technique du produit n'intéresse pas, etc.
-- Cordialement. -- * Patrick BRUNET www.ipzb.fr * E-mail: lien sur http://zener131.free.fr/ContactMe
Bonsoir
"Christian PANEL" <c.panel@free.fr> a écrit dans le message de news:
48567e6b$0$4643$426a74cc@news.free.fr...
je cherche un gestionnaire de fenêtre/framework écrit en C++ pour win32
capable d'être compilé sous MSC, GNU ou Borland (genre MFC) : que me
conseilleriez vous ?
Ca dépend de ce que vous voulez faire exactement.
Il ne suffit pas que ça se compile ni même que ce soit fonctionnel. Il faut
encore que ça respecte les règles de style, explicites ou implicites, de la
plateforme visée.
Ce qui inclut tout le look mais aussi les accélérateurs clavier,
l'intégration complète aux menus et autres toolboxes du système, etc.
Et la seule bonne réponse à tout ça, c'est le même outil que celui qui a été
utilisé pour faire tout le reste de l'IHM du système, ou celle que chaque
utilisateur a choisie si ce choix existe.
J'ai déjà vu des librairies fondées sur le principe du dénominateur commun,
mais objectivement, il est à craindre qu'elles soient parsemées de trous
d'implémentation, car on ne peut pas mettre dans le même outil des choses
parfois antagonistes. On en arrive toujours à se satisfaire d'avoir réussi
l'essentiel...
Et je ne parle pas de la mode des skins, absolument superflus voire
aberrants pour l'ergonomie, mais donc parfaitement indispensables pour un
nombre croissant d'utilisateurs :o)
AMHA la meilleure solution est de découpler autant que possible le moteur du
logiciel de son IHM, en prenant un maximum de recul au niveau du moteur et
de son interface formelle, et l'IHM devient alors un produit annexe, aussi
interchangeable que possible, et dépouillé au maximum de l'intelligence du
process. Les technologies de linkage dynamique pour de tels composants sont
assez au point...
Ce qui vous permet de traiter l'IHM comme un sous-produit +/- ludique,
transposable, sous-traitable, parallélisable, testable séparément, évaluable
par des experts en look & feel et autres critères de mode, que l'aspect
technique du produit n'intéresse pas, etc.
--
Cordialement.
--
* Patrick BRUNET www.ipzb.fr
* E-mail: lien sur http://zener131.free.fr/ContactMe
"Christian PANEL" a écrit dans le message de news: 48567e6b$0$4643$
je cherche un gestionnaire de fenêtre/framework écrit en C++ pour win32 capable d'être compilé sous MSC, GNU ou Borland (genre MFC) : que me conseilleriez vous ?
Ca dépend de ce que vous voulez faire exactement.
Il ne suffit pas que ça se compile ni même que ce soit fonctionnel. Il faut encore que ça respecte les règles de style, explicites ou implicites, de la plateforme visée.
Ce qui inclut tout le look mais aussi les accélérateurs clavier, l'intégration complète aux menus et autres toolboxes du système, etc.
Et la seule bonne réponse à tout ça, c'est le même outil que celui qui a été utilisé pour faire tout le reste de l'IHM du système, ou celle que chaque utilisateur a choisie si ce choix existe.
J'ai déjà vu des librairies fondées sur le principe du dénominateur commun, mais objectivement, il est à craindre qu'elles soient parsemées de trous d'implémentation, car on ne peut pas mettre dans le même outil des choses parfois antagonistes. On en arrive toujours à se satisfaire d'avoir réussi l'essentiel...
Et je ne parle pas de la mode des skins, absolument superflus voire aberrants pour l'ergonomie, mais donc parfaitement indispensables pour un nombre croissant d'utilisateurs :o)
AMHA la meilleure solution est de découpler autant que possible le moteur du logiciel de son IHM, en prenant un maximum de recul au niveau du moteur et de son interface formelle, et l'IHM devient alors un produit annexe, aussi interchangeable que possible, et dépouillé au maximum de l'intelligence du process. Les technologies de linkage dynamique pour de tels composants sont assez au point...
Ce qui vous permet de traiter l'IHM comme un sous-produit +/- ludique, transposable, sous-traitable, parallélisable, testable séparément, évaluable par des experts en look & feel et autres critères de mode, que l'aspect technique du produit n'intéresse pas, etc.
-- Cordialement. -- * Patrick BRUNET www.ipzb.fr * E-mail: lien sur http://zener131.free.fr/ContactMe
Fabien LE LEZ
On Thu, 19 Jun 2008 19:25:01 +0200, "Patrick 'Zener' Brunet" :
AMHA la meilleure solution est de découpler autant que possible le moteur du logiciel de son IHM
Pas forcément évident quand 90 % du code sert à gérer directement l'IHM...
On Thu, 19 Jun 2008 19:25:01 +0200, "Patrick 'Zener' Brunet" :
AMHA la meilleure solution est de découpler autant que possible le moteur du
logiciel de son IHM
Pas forcément évident quand 90 % du code sert à gérer directement
l'IHM...
On Thu, 19 Jun 2008 19:25:01 +0200, "Patrick 'Zener' Brunet" :
AMHA la meilleure solution est de découpler autant que possible le moteur du logiciel de son IHM
Pas forcément évident quand 90 % du code sert à gérer directement l'IHM...
Patrick 'Zener' Brunet
Bonsoir.
"Fabien LE LEZ" a écrit dans le message de news:
On Thu, 19 Jun 2008 19:25:01 +0200, "Patrick 'Zener' Brunet" :
>AMHA la meilleure solution est de découpler autant que possible >le moteur du logiciel de son IHM
Pas forcément évident quand 90 % du code sert à gérer directement l'IHM...
L'application est une démo des richesses de l'environnement graphique ?
Un bouton/menu/icône etc, c'est une représentation d'un verbe de l'interface. Une checkbox c'est un switch binaire ou ternaire. Un group de radiobuttons ou une listbox simple, c'est un enum...
Et c'est plus ou moins la même chose pour les retours.
Ensuite il y a la structure logique des blocs de données entrés par l'interface graphique ou représentés par l'interface... Même si votre retour est un texte décoré ou un beau dessin vectoriel, il y a là-dedans une partie conceptuelle qui peut rester portable, et une partie spécifique qui est son portage final sur les primitives graphiques de la cible.
Et ce qui vaut pour l'IHM peut d'ailleurs se généraliser au pilotage par une console, par des macros, par des commandes réseau, etc.
Il y a forcément un moteur au milieu qui accomplit une tâche utile, sinon l'ensemble ne sert pas à grand chose.
Certes les transpositions en entrée ou en sortie au niveau de l'interface peuvent représenter un certain volume de traitement, mais s'il peut être volumineux, il a intérêt à rester aussi "stupide" que possible, et ce n'est souvent que le remplissage de callbacks, démons ou autres éléments d'une "application" telle que les wizards (ou le copier-coller) savent très bien la générer. Ce qui coûte cher AMHA, ce n'est pas le gros bête code obtenu par copier-coller (vive les macros !), c'est le code intrinsèquement complexe du "moteur".
Evidemment, l'erreur à ne pas commettre est de suivre cette partie des exemples de projets qui consiste à ventiler la logique process de son logiciel dans les démons et classes d'IHM en question... Outre le fait que ce code est généralement moche et assez inmaintenable à la main, on est alors sûr d'obtenir un gros machin indivisible.
Mais on peut très bien ne pas suivre cette pratique et cloisonner complètement. Référencer la typologie du code portable dans celui de l'IHM et surtout pas le contraire, etc.
-- Cordialement. -- * Patrick BRUNET www.ipzb.fr * E-mail: lien sur http://zener131.free.fr/ContactMe
Bonsoir.
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
3nrm54p7rj8r5mil6rs7n5kod0vb8sio30@4ax.com...
On Thu, 19 Jun 2008 19:25:01 +0200, "Patrick 'Zener' Brunet" :
>AMHA la meilleure solution est de découpler autant que possible
>le moteur du logiciel de son IHM
Pas forcément évident quand 90 % du code sert à gérer
directement l'IHM...
L'application est une démo des richesses de l'environnement graphique ?
Un bouton/menu/icône etc, c'est une représentation d'un verbe de
l'interface.
Une checkbox c'est un switch binaire ou ternaire.
Un group de radiobuttons ou une listbox simple, c'est un enum...
Et c'est plus ou moins la même chose pour les retours.
Ensuite il y a la structure logique des blocs de données entrés par
l'interface graphique ou représentés par l'interface...
Même si votre retour est un texte décoré ou un beau dessin vectoriel, il y a
là-dedans une partie conceptuelle qui peut rester portable, et une partie
spécifique qui est son portage final sur les primitives graphiques de la
cible.
Et ce qui vaut pour l'IHM peut d'ailleurs se généraliser au pilotage par une
console, par des macros, par des commandes réseau, etc.
Il y a forcément un moteur au milieu qui accomplit une tâche utile, sinon
l'ensemble ne sert pas à grand chose.
Certes les transpositions en entrée ou en sortie au niveau de l'interface
peuvent représenter un certain volume de traitement, mais s'il peut être
volumineux, il a intérêt à rester aussi "stupide" que possible, et ce n'est
souvent que le remplissage de callbacks, démons ou autres éléments d'une
"application" telle que les wizards (ou le copier-coller) savent très bien
la générer.
Ce qui coûte cher AMHA, ce n'est pas le gros bête code obtenu par
copier-coller (vive les macros !), c'est le code intrinsèquement complexe du
"moteur".
Evidemment, l'erreur à ne pas commettre est de suivre cette partie des
exemples de projets qui consiste à ventiler la logique process de son
logiciel dans les démons et classes d'IHM en question...
Outre le fait que ce code est généralement moche et assez inmaintenable à la
main, on est alors sûr d'obtenir un gros machin indivisible.
Mais on peut très bien ne pas suivre cette pratique et cloisonner
complètement. Référencer la typologie du code portable dans celui de l'IHM
et surtout pas le contraire, etc.
--
Cordialement.
--
* Patrick BRUNET www.ipzb.fr
* E-mail: lien sur http://zener131.free.fr/ContactMe
On Thu, 19 Jun 2008 19:25:01 +0200, "Patrick 'Zener' Brunet" :
>AMHA la meilleure solution est de découpler autant que possible >le moteur du logiciel de son IHM
Pas forcément évident quand 90 % du code sert à gérer directement l'IHM...
L'application est une démo des richesses de l'environnement graphique ?
Un bouton/menu/icône etc, c'est une représentation d'un verbe de l'interface. Une checkbox c'est un switch binaire ou ternaire. Un group de radiobuttons ou une listbox simple, c'est un enum...
Et c'est plus ou moins la même chose pour les retours.
Ensuite il y a la structure logique des blocs de données entrés par l'interface graphique ou représentés par l'interface... Même si votre retour est un texte décoré ou un beau dessin vectoriel, il y a là-dedans une partie conceptuelle qui peut rester portable, et une partie spécifique qui est son portage final sur les primitives graphiques de la cible.
Et ce qui vaut pour l'IHM peut d'ailleurs se généraliser au pilotage par une console, par des macros, par des commandes réseau, etc.
Il y a forcément un moteur au milieu qui accomplit une tâche utile, sinon l'ensemble ne sert pas à grand chose.
Certes les transpositions en entrée ou en sortie au niveau de l'interface peuvent représenter un certain volume de traitement, mais s'il peut être volumineux, il a intérêt à rester aussi "stupide" que possible, et ce n'est souvent que le remplissage de callbacks, démons ou autres éléments d'une "application" telle que les wizards (ou le copier-coller) savent très bien la générer. Ce qui coûte cher AMHA, ce n'est pas le gros bête code obtenu par copier-coller (vive les macros !), c'est le code intrinsèquement complexe du "moteur".
Evidemment, l'erreur à ne pas commettre est de suivre cette partie des exemples de projets qui consiste à ventiler la logique process de son logiciel dans les démons et classes d'IHM en question... Outre le fait que ce code est généralement moche et assez inmaintenable à la main, on est alors sûr d'obtenir un gros machin indivisible.
Mais on peut très bien ne pas suivre cette pratique et cloisonner complètement. Référencer la typologie du code portable dans celui de l'IHM et surtout pas le contraire, etc.
-- Cordialement. -- * Patrick BRUNET www.ipzb.fr * E-mail: lien sur http://zener131.free.fr/ContactMe
Alp Mestan
On 16 juin, 16:53, "Christian PANEL" wrote:
Bonjour,
je cherche un gestionnaire de fenêtre/framework écrit en C++ pour win3 2 capable d'être compilé sous MSC, GNU ou Borland (genre MFC) : que me conseilleriez vous ? Merci.
Sans hésiter Qt.
On 16 juin, 16:53, "Christian PANEL" <c.pa...@free.fr> wrote:
Bonjour,
je cherche un gestionnaire de fenêtre/framework écrit en C++ pour win3 2
capable d'être compilé sous MSC, GNU ou Borland (genre MFC) : que me
conseilleriez vous ?
Merci.
je cherche un gestionnaire de fenêtre/framework écrit en C++ pour win3 2 capable d'être compilé sous MSC, GNU ou Borland (genre MFC) : que me conseilleriez vous ? Merci.
Sans hésiter Qt.
John Deuf
Christian PANEL :
je cherche un gestionnaire de fenêtre/framework écrit en C++ pour win32 capable d'être compilé sous MSC, GNU ou Borland (genre MFC) : que me conseilleriez vous ?
http://www.torjo.com/win32gui/
C'est le plus "c++" des frameworks GUI, un peu sur le modèle de la STL. Il permet d'écrire un IHM en très peu de ligne.
-- John Deuf
Christian PANEL :
je cherche un gestionnaire de fenêtre/framework écrit en C++ pour win32
capable d'être compilé sous MSC, GNU ou Borland (genre MFC) : que me
conseilleriez vous ?
http://www.torjo.com/win32gui/
C'est le plus "c++" des frameworks GUI, un peu sur le modèle de la STL.
Il permet d'écrire un IHM en très peu de ligne.
je cherche un gestionnaire de fenêtre/framework écrit en C++ pour win32 capable d'être compilé sous MSC, GNU ou Borland (genre MFC) : que me conseilleriez vous ?
http://www.torjo.com/win32gui/
C'est le plus "c++" des frameworks GUI, un peu sur le modèle de la STL. Il permet d'écrire un IHM en très peu de ligne.
-- John Deuf
Eric.Malenfant
On Jun 24, 5:03 am, John Deuf wrote:
Christian PANEL :
> je cherche un gestionnaire de fenêtre/framework écrit en C++ pour w in32 > capable d'être compilé sous MSC, GNU ou Borland (genre MFC) : que m e > conseilleriez vous ?
http://www.torjo.com/win32gui/
C'est le plus "c++" des frameworks GUI, un peu sur le modèle de la STL. Il permet d'écrire un IHM en très peu de ligne.
D'après son auteur, win32gui a un successeur: eGUI++: http://torjo.blogspot.com/2008/06/egui-easy-gui-for-c.html
On Jun 24, 5:03 am, John Deuf <nom...@dontuseit.com> wrote:
Christian PANEL :
> je cherche un gestionnaire de fenêtre/framework écrit en C++ pour w in32
> capable d'être compilé sous MSC, GNU ou Borland (genre MFC) : que m e
> conseilleriez vous ?
http://www.torjo.com/win32gui/
C'est le plus "c++" des frameworks GUI, un peu sur le modèle de la STL.
Il permet d'écrire un IHM en très peu de ligne.
D'après son auteur, win32gui a un successeur: eGUI++:
http://torjo.blogspot.com/2008/06/egui-easy-gui-for-c.html
> je cherche un gestionnaire de fenêtre/framework écrit en C++ pour w in32 > capable d'être compilé sous MSC, GNU ou Borland (genre MFC) : que m e > conseilleriez vous ?
http://www.torjo.com/win32gui/
C'est le plus "c++" des frameworks GUI, un peu sur le modèle de la STL. Il permet d'écrire un IHM en très peu de ligne.
D'après son auteur, win32gui a un successeur: eGUI++: http://torjo.blogspot.com/2008/06/egui-easy-gui-for-c.html
