Bonjour à tous,
J'ai une interface java pour mon appli en tête, mais j'angoisse à l'idée de
la développer avec eclipse...
Auriez vous un bon AGL à me conseiller pour la dessiner ?
J'ai besoin de JTree, de tirroirs, de canvas2D, 3D, de barres d'outils...
Enfin, il faut disposer d'une compréhension sans faille des "layouts" et une compréhension générale des méchanismes de rendu (surtout si tu compte mélanger 2D et 3D).
c'est pour ca (a mon avis) qu'en java rien ne vaut d'ecrire ses interfaces a la main. tous les elements vont bouger d'un OS a l'autre, donc il faut savoir exactement ce que l'on fait et comment ca va etre rendu. positionner ses elements a la pixel pres dans un editeur d'interfaces ne marche pas en java.
paul.
Jette un coup d'oeil à http://www.jgoodies.com/freeware/forms/
Ses layouts sont très efficace pour faire des interfaces soignées.
-- Gaetan Zoritchak Gestion de bug en mode ASP sous java http://eap.bug-sweeper.fr
barilla wrote:
Enfin, il faut disposer d'une compréhension sans faille des "layouts"
et une compréhension générale des méchanismes de rendu (surtout si tu
compte mélanger 2D et 3D).
c'est pour ca (a mon avis) qu'en java rien ne vaut d'ecrire ses
interfaces a la main.
tous les elements vont bouger d'un OS a l'autre, donc
il faut savoir exactement ce que l'on fait et comment ca va etre
rendu. positionner ses elements a la pixel pres dans un
editeur d'interfaces ne marche pas en java.
paul.
Jette un coup d'oeil à http://www.jgoodies.com/freeware/forms/
Ses layouts sont très efficace pour faire des interfaces soignées.
--
Gaetan Zoritchak
Gestion de bug en mode ASP sous java
http://eap.bug-sweeper.fr
Enfin, il faut disposer d'une compréhension sans faille des "layouts" et une compréhension générale des méchanismes de rendu (surtout si tu compte mélanger 2D et 3D).
c'est pour ca (a mon avis) qu'en java rien ne vaut d'ecrire ses interfaces a la main. tous les elements vont bouger d'un OS a l'autre, donc il faut savoir exactement ce que l'on fait et comment ca va etre rendu. positionner ses elements a la pixel pres dans un editeur d'interfaces ne marche pas en java.
paul.
Jette un coup d'oeil à http://www.jgoodies.com/freeware/forms/
Ses layouts sont très efficace pour faire des interfaces soignées.
-- Gaetan Zoritchak Gestion de bug en mode ASP sous java http://eap.bug-sweeper.fr
coco
positionner ses elements au pixel près est effectivement une erreur.
Ce n'est pas la première fois que je lis ce genre de commentaire et c'est une chose que j'aimerais comprendre; un pixel est un pixel, quelle que soit la plate-forme. Si je dessine un bouton ou LButton de 60 de large sur 20 de haut, je ne vois pas où est le problème.
-- Philippe
positionner ses elements au pixel près est effectivement une erreur.
Ce n'est pas la première fois que je lis ce genre de commentaire et
c'est une chose que j'aimerais comprendre; un pixel est un pixel, quelle
que soit la plate-forme. Si je dessine un bouton ou LButton de 60 de
large sur 20 de haut, je ne vois pas où est le problème.
positionner ses elements au pixel près est effectivement une erreur.
Ce n'est pas la première fois que je lis ce genre de commentaire et c'est une chose que j'aimerais comprendre; un pixel est un pixel, quelle que soit la plate-forme. Si je dessine un bouton ou LButton de 60 de large sur 20 de haut, je ne vois pas où est le problème.
-- Philippe
barilla
les textes et les elements graphiques n'ont pas une taille fixe d'un environnement graphique/plateforme a l'autre.
si tu as une JLabel de 160 pixels qui a l'air jolie sous windows parceque le texte fait par defaut 150 pixels, ca risque de depasser ou d'etre coupe lorsque tu change de plateforme et que tu as le texte qui fait alors 200 pixels ...
c'est comme les sites web qui sont illisibles des que tu changes la taille de la police ... tout ca parceque les tailles sont definies de maniere absolues et pas relatives. mal foutu quoi.
ca n'est reellement pareil que si tu utilises swing metal theme, que ton interface n'a aucun texte et ne fait appel a aucun element natif. et encore ...
paul.
les textes et les elements graphiques n'ont pas une taille
fixe d'un environnement graphique/plateforme a l'autre.
si tu as une JLabel de 160 pixels qui a l'air jolie
sous windows parceque le texte fait par defaut 150 pixels,
ca risque de depasser ou d'etre coupe lorsque tu change
de plateforme et que tu as le texte qui fait alors
200 pixels ...
c'est comme les sites web qui sont illisibles
des que tu changes la taille de la police ...
tout ca parceque les tailles sont definies de
maniere absolues et pas relatives. mal foutu quoi.
ca n'est reellement pareil que si tu utilises
swing metal theme, que ton interface n'a aucun texte
et ne fait appel a aucun element natif.
et encore ...
les textes et les elements graphiques n'ont pas une taille fixe d'un environnement graphique/plateforme a l'autre.
si tu as une JLabel de 160 pixels qui a l'air jolie sous windows parceque le texte fait par defaut 150 pixels, ca risque de depasser ou d'etre coupe lorsque tu change de plateforme et que tu as le texte qui fait alors 200 pixels ...
c'est comme les sites web qui sont illisibles des que tu changes la taille de la police ... tout ca parceque les tailles sont definies de maniere absolues et pas relatives. mal foutu quoi.
ca n'est reellement pareil que si tu utilises swing metal theme, que ton interface n'a aucun texte et ne fait appel a aucun element natif. et encore ...
paul.
Paul
"BJB" a écrit dans le message de news:
Au passage, je reste interloqué sur l'incapacité d'eclipse à fournir un tel concepteur ;-)
dézippez le tout (extraire le repertoire eclipse) dans un repertoire COMMUN eclipse qui contient (plugins, features, ...)
------------------------------------------------ copier le contenu du repertoire Eclipse (plugins, features, ...) dans le repertoire Eclipse principal le programme ECLIPSE arrété
pour creer classe visuelle exemple aller sur package new other java swing jframe visual class agrandir la palette et placer les composants
DOC= Build GUIs with the Eclipse Visual Editor project.htm http://www-106.ibm.com/developerworks/opensource/library/os-ecvisual/
"BJB" a écrit dans le message de news:
Au passage, je reste interloqué sur l'incapacité d'eclipse à fournir un
tel concepteur ;-)
dézippez le tout (extraire le repertoire eclipse) dans un repertoire COMMUN
eclipse
qui contient (plugins, features, ...)
------------------------------------------------
copier le contenu du repertoire Eclipse (plugins, features, ...)
dans le repertoire Eclipse principal
le programme ECLIPSE arrété
pour creer classe visuelle
exemple
aller sur package new other java swing jframe visual class
agrandir la palette et placer les composants
DOC= Build GUIs with the Eclipse Visual Editor project.htm
http://www-106.ibm.com/developerworks/opensource/library/os-ecvisual/
dézippez le tout (extraire le repertoire eclipse) dans un repertoire COMMUN eclipse qui contient (plugins, features, ...)
------------------------------------------------ copier le contenu du repertoire Eclipse (plugins, features, ...) dans le repertoire Eclipse principal le programme ECLIPSE arrété
pour creer classe visuelle exemple aller sur package new other java swing jframe visual class agrandir la palette et placer les composants
DOC= Build GUIs with the Eclipse Visual Editor project.htm http://www-106.ibm.com/developerworks/opensource/library/os-ecvisual/
Alain
les textes et les elements graphiques n'ont pas une taille fixe d'un environnement graphique/plateforme a l'autre.
si tu as une JLabel de 160 pixels qui a l'air jolie sous windows parceque le texte fait par defaut 150 pixels, ca risque de depasser ou d'etre coupe lorsque tu change de plateforme et que tu as le texte qui fait alors 200 pixels ... déjà sous windows ca dépend des fontes...
les développeurs de culture windows ont eu l'habitude de développer au pixel précis et de pas avoir d'interfaces élastiques...
moi j'ai bossé en CLOS, Smalltalk et Swing (en même Gpic,latex, et les interfaces y sont elastiques... c'est plus subtil à concevoir, mais ca fait des écrans qui survivent (et profitent) à un changement de fonte, de taille écran, de système d'exploitation, et a des alongement de champs...
sans parle des problèmes de traductions des labels... combien d'interfaces windows multi-lingues sont illisibles dans une langues autre que la langue de création...
les textes et les elements graphiques n'ont pas une taille
fixe d'un environnement graphique/plateforme a l'autre.
si tu as une JLabel de 160 pixels qui a l'air jolie
sous windows parceque le texte fait par defaut 150 pixels,
ca risque de depasser ou d'etre coupe lorsque tu change
de plateforme et que tu as le texte qui fait alors
200 pixels ...
déjà sous windows ca dépend des fontes...
les développeurs de culture windows ont eu l'habitude de développer au
pixel précis et de pas avoir d'interfaces élastiques...
moi j'ai bossé en CLOS, Smalltalk et Swing (en même Gpic,latex, et les
interfaces y sont elastiques... c'est plus subtil à concevoir, mais ca
fait des écrans qui survivent (et profitent) à un changement de fonte,
de taille écran, de système d'exploitation, et a des alongement de champs...
sans parle des problèmes de traductions des labels...
combien d'interfaces windows multi-lingues sont illisibles dans une
langues autre que la langue de création...
les textes et les elements graphiques n'ont pas une taille fixe d'un environnement graphique/plateforme a l'autre.
si tu as une JLabel de 160 pixels qui a l'air jolie sous windows parceque le texte fait par defaut 150 pixels, ca risque de depasser ou d'etre coupe lorsque tu change de plateforme et que tu as le texte qui fait alors 200 pixels ... déjà sous windows ca dépend des fontes...
les développeurs de culture windows ont eu l'habitude de développer au pixel précis et de pas avoir d'interfaces élastiques...
moi j'ai bossé en CLOS, Smalltalk et Swing (en même Gpic,latex, et les interfaces y sont elastiques... c'est plus subtil à concevoir, mais ca fait des écrans qui survivent (et profitent) à un changement de fonte, de taille écran, de système d'exploitation, et a des alongement de champs...
sans parle des problèmes de traductions des labels... combien d'interfaces windows multi-lingues sont illisibles dans une langues autre que la langue de création...
Zouplaz
Paul - :
"BJB" a écrit dans le message de news:
Au passage, je reste interloqué sur l'incapacité d'eclipse à fournir un tel concepteur ;-)
Chez moi Vep est d'une telle lenteur que j'ai abandonné l'idée de m'en servir (plus quelques autres choses qui ne me plaisaient pas et que j'ai oublié)...
Il y a jigloo qui fait un éditeur swing/swt plutôt sympa à un prix raisonnable (50 euros je crois). J'avais testé la version d'évaluation, ça fonctionnait bien...
Paul - nospam@hotmail.com :
"BJB" a écrit dans le message de news:
Au passage, je reste interloqué sur l'incapacité d'eclipse à fournir
un tel concepteur ;-)
Chez moi Vep est d'une telle lenteur que j'ai abandonné l'idée de m'en
servir (plus quelques autres choses qui ne me plaisaient pas et que j'ai
oublié)...
Il y a jigloo qui fait un éditeur swing/swt plutôt sympa à un prix
raisonnable (50 euros je crois). J'avais testé la version d'évaluation, ça
fonctionnait bien...
Chez moi Vep est d'une telle lenteur que j'ai abandonné l'idée de m'en servir (plus quelques autres choses qui ne me plaisaient pas et que j'ai oublié)...
Il y a jigloo qui fait un éditeur swing/swt plutôt sympa à un prix raisonnable (50 euros je crois). J'avais testé la version d'évaluation, ça fonctionnait bien...
Chez moi Vep est d'une telle lenteur que j'ai abandonné l'idée de m'en servir (plus quelques autres choses qui ne me plaisaient pas et que j'ai oublié)... je l'utilise sous eclipse 3 le plus récent et ca marche bien.
une note pour ceux qui râlent contre les layout qui font pas ce qu'on veut...
en fait les layous sont fait pour être imbriqués les un dans les autres...
par exemple pour un outils de parcours d'images... on met un border layout, avec au nord un flow layout avec des boutons et un champs dedans au milieu je met le contenu principal (in JImagePanel récupé sur le web qui pose une image) a l'ouest et a l'est juste chacun un icone pour avancer ou reculer... au sud je met un box layoux avec 3 cases horizontales avec des texte de status divers...
les layout c'est un coup de main a prendre... bon j'avoue je suis avantagé parce que j'ai bossé en Smalltalk puis avec VisualAge For Java
Chez moi Vep est d'une telle lenteur que j'ai abandonné l'idée de m'en
servir (plus quelques autres choses qui ne me plaisaient pas et que j'ai
oublié)...
je l'utilise sous eclipse 3 le plus récent et ca marche bien.
une note pour ceux qui râlent contre les layout qui font pas ce qu'on
veut...
en fait les layous sont fait pour être imbriqués les un dans les autres...
par exemple pour un outils de parcours d'images...
on met un border layout, avec
au nord un flow layout avec des boutons et un champs dedans
au milieu je met le contenu principal (in JImagePanel récupé sur le web
qui pose une image)
a l'ouest et a l'est juste chacun un icone pour avancer ou reculer...
au sud je met un box layoux avec 3 cases horizontales avec des texte de
status divers...
les layout c'est un coup de main a prendre... bon j'avoue je suis
avantagé parce que j'ai bossé en Smalltalk puis avec VisualAge For Java
Chez moi Vep est d'une telle lenteur que j'ai abandonné l'idée de m'en servir (plus quelques autres choses qui ne me plaisaient pas et que j'ai oublié)... je l'utilise sous eclipse 3 le plus récent et ca marche bien.
une note pour ceux qui râlent contre les layout qui font pas ce qu'on veut...
en fait les layous sont fait pour être imbriqués les un dans les autres...
par exemple pour un outils de parcours d'images... on met un border layout, avec au nord un flow layout avec des boutons et un champs dedans au milieu je met le contenu principal (in JImagePanel récupé sur le web qui pose une image) a l'ouest et a l'est juste chacun un icone pour avancer ou reculer... au sud je met un box layoux avec 3 cases horizontales avec des texte de status divers...
les layout c'est un coup de main a prendre... bon j'avoue je suis avantagé parce que j'ai bossé en Smalltalk puis avec VisualAge For Java
olivier.benichou
"" wrote in message news:<4239d1d9$0$844$...
il faut savoir exactement ce que l'on fait et comment ca va etre rendu. positionner ses elements a la pixel pres dans un editeur d'interfaces ne marche pas en java.
Bonjour,
positionner ses elements au pixel près est effectivement une erreur.
Par contre utiliser des containers, layout n'empêche pas d'utiliser un éditeur d'interface.
En C++ il y a par exemple Glade (pour GTKmm) et wxGlade pour wxWidgets. Et c'est assez intuitif tout en respectant les concepts de containers.
Cordialement
L'environnement de JBuilder permet de construire une interface qui s'adapte à la taille des ecrans et aux resolutions choisies par les utilisateurs. J'ai développé une vingtaine d'IHM complexes ( plus de 300 composants par ecran) . Il faut savoir utiliser la représentation sous forme d'arbres des composants ( dans le cadre situé à gauche de l'outil conceptuelle).
Les meilleurs IHM melangent les layout GridBagLayout et BorderLayout. Une fois compris, ces 2 layout permettent de créer avec precision des IHM redimensionnables réellement.
Le point de départ pour apprendre à se servir du GridbagLayout est l'aide inclu dans jbuilder à ce sujet (un tutorial inclu excellent).
Les IHM produites sont un peu lentes, mais ce n'est pas génant pour une application de gestion devant tourner sur un parc heterogene.
Une possibilité de développent d'IHM consiste à construire toute son IHM avec le layout de JBuilder en XYLayout , puis de convertir à la fin en GridBagLayout.
"noone@nowhere.com" <noone@nowhere.com> wrote in message news:<4239d1d9$0$844$8fcfb975@news.wanadoo.fr>...
il faut savoir exactement ce que l'on fait et comment ca va etre
rendu. positionner ses elements a la pixel pres dans un
editeur d'interfaces ne marche pas en java.
Bonjour,
positionner ses elements au pixel près est effectivement une erreur.
Par contre utiliser des containers, layout n'empêche pas d'utiliser un
éditeur d'interface.
En C++ il y a par exemple Glade (pour GTKmm) et wxGlade pour wxWidgets.
Et c'est assez intuitif tout en respectant les concepts de containers.
Cordialement
L'environnement de JBuilder permet de construire une interface qui
s'adapte à la taille des ecrans et aux resolutions choisies par les
utilisateurs.
J'ai développé une vingtaine d'IHM complexes ( plus de 300 composants
par ecran) . Il faut savoir utiliser la représentation sous forme
d'arbres des composants ( dans le cadre situé à gauche de l'outil
conceptuelle).
Les meilleurs IHM melangent les layout GridBagLayout et BorderLayout.
Une fois compris, ces 2 layout permettent de créer avec precision des
IHM redimensionnables réellement.
Le point de départ pour apprendre à se servir du GridbagLayout est
l'aide inclu dans jbuilder à ce sujet (un tutorial inclu excellent).
Les IHM produites sont un peu lentes, mais ce n'est pas génant pour
une application de gestion devant tourner sur un parc heterogene.
Une possibilité de développent d'IHM consiste à construire toute son
IHM avec le layout de JBuilder en XYLayout , puis de convertir à la
fin en GridBagLayout.
il faut savoir exactement ce que l'on fait et comment ca va etre rendu. positionner ses elements a la pixel pres dans un editeur d'interfaces ne marche pas en java.
Bonjour,
positionner ses elements au pixel près est effectivement une erreur.
Par contre utiliser des containers, layout n'empêche pas d'utiliser un éditeur d'interface.
En C++ il y a par exemple Glade (pour GTKmm) et wxGlade pour wxWidgets. Et c'est assez intuitif tout en respectant les concepts de containers.
Cordialement
L'environnement de JBuilder permet de construire une interface qui s'adapte à la taille des ecrans et aux resolutions choisies par les utilisateurs. J'ai développé une vingtaine d'IHM complexes ( plus de 300 composants par ecran) . Il faut savoir utiliser la représentation sous forme d'arbres des composants ( dans le cadre situé à gauche de l'outil conceptuelle).
Les meilleurs IHM melangent les layout GridBagLayout et BorderLayout. Une fois compris, ces 2 layout permettent de créer avec precision des IHM redimensionnables réellement.
Le point de départ pour apprendre à se servir du GridbagLayout est l'aide inclu dans jbuilder à ce sujet (un tutorial inclu excellent).
Les IHM produites sont un peu lentes, mais ce n'est pas génant pour une application de gestion devant tourner sur un parc heterogene.
Une possibilité de développent d'IHM consiste à construire toute son IHM avec le layout de JBuilder en XYLayout , puis de convertir à la fin en GridBagLayout.
