Path: csiph.com!aioe.org!news.gegeweb.eu!gegeweb.org!news.trigofacile.com!.POSTED.reverse-90.fdn.fr!not-for-mail From: Yliur Newsgroups: fr.comp.lang.java Subject: Re: Aide pour une =?UTF-8?B?c3RyYXTDqWdpZQ==?= de programmation. Date: Tue, 14 Nov 2017 12:27:59 +0100 Organization: Groupes francophones par TrigoFACILE Message-ID: <20171114122759.223fae94@free.fr> References: <59fc966a$0$20429$426a34cc@news.free.fr> <20171107150354.5dc0969f@free.fr> <5a03af3a$0$7158$426a74cc@news.free.fr> <20171109091546.54256f71@free.fr> <5a06ff9f$0$3443$426a34cc@news.free.fr> <20171111183357.7277d116@free.fr> <5a0a6560$0$3841$426a74cc@news.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Info: news.trigofacile.com; posting-account="yliur@free.fr"; posting-host="reverse-90.fdn.fr:80.67.176.90"; logging-data="4739"; mail-complaints-to="abuse@trigofacile.com" X-Newsreader: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) Xref: csiph.com fr.comp.lang.java:1599 >>> (JTestPane) ((Chapter) (vector.getChapter())).getMainText() = >>> jtextPane; >> >> Là je ne vois pas bien ce que tu fais : la ligne ci-dessus ne semble >> pas être du code qui fonctionne (tu ne peux pas affecter jtextpane au >> résultat de getMainText()). > > Si. Normalement ça doit marcher. La méthode getMainText() c'est moi > qui l'ai inventée. C'est celle qui renverra un JTextPane de l'objet > Chapter. La question que je me posais était de savoir si le fait de > mettre le symbole = permettait de faire le lien entre la > représentation graphique et le JTextPane dans le Chapter du Vector. > Je pense qque oui mais je n'en suis pas sûr. Sinon comment fait-on > pour dupliquer un objet déjà? On emploi la méthode clone()? Non, ça ne peut pas marcher. Une forme valable c'est ça (on associe une valeur à un nom) : nomVariable = valeur ; Une autre forme possible (on passe la valeur à une fonction ; laquelle pourra faire elle-même une association pour stocker la valeur quelque part) : fonction (valeur) ; par exemple : chapter.setMainText (texte) ; avec un corps de setMainText de cette forme : this.mainText = texte ; Par contre tu ne peux pas utiliser cette forme : getMainText() = texte ; parce que getMainText() renvoie une valeur et donc c'est de la forme valeur = valeur ; ce qui n'est pas possible. >> Déjà il faut choisir s'il existe un composant graphique par >> chapitre. À mon avis ça ne sert à rien et ça complique les choses. > > Je pense que c'est quand-même la solution que je vais retenir car > c'est celle du logiciel d'origine et elle est très ergonomique. Ce > programme est très bien pensé. Dommage qu'il soit complètement > buggé... (note qu'il semble y avoir un peu d'activité sur le site de ce logiciel ; après ça n'a pas l'air d'avancer rapidement...) Là je pense qu'on ne s'est pas bien compris : je n'ai rien contre l'ergonomie du logiciel que tu cites et je parle bien de reproduire la même interface. Mais pour ça il n'est pas obligatoire de créer un composant graphique (ou plusieurs) par chapitre. En clair il y a deux solutions... La première consiste à effectivement tout représenter dans les composants graphiques. Par exemple stocker le texte de chaque chapitre dans un JTextPane. Ça a l'air simple à réaliser, la correspondance entre les données et leur représentation graphique est simple à comprendre, par contre ça risque de compliquer le développement futur du logiciel. La seconde consiste à représenter d'un côté les données (chapitres, textes, notes, personnages, ...) dans des classes qui n'ont aucun lien avec l'interface graphique, et de l'autre à représenter l'interface graphique. Cette solution nécessite un peu plus de réflexion, il y a un peu plus de classes et il faut synchroniser les données et l'interface, mais elle est souvent plus simple à comprendre quand le logiciel grossit. Ces deux solutions concernent uniquement l'organisation du code et la conception du logiciel, elles n'ont pas d'impact sur son ergonomie et sur la manière dont l'utilisateur manipulera les données. De manière générale, je pense qu'il est plus facile de penser un programme en raisonnant sur ses données et fonctionnalités, l'interface n'étant que la traduction d'une partie de ces fonctionnalités (d'autres pourraient être l'indexation/recherche, la création de pages regroupant les données sous une autre forme, ...). Donc je penche pour la seconde solution. C'est un peu plus de travail et d'explications mais je pense que ça en vaut vraiment la peine Et dès que tu vas vouloir sortir des fonctionnalités de base (l'édition des informations par chapitre) ça va être plus simple. Là il faut choisir l'une ou l'autre option (la plus simple ou celle qui nécessite plus d'effort mais qui est mieux rangés à plus long terme). Sinon on ne se comprend pas bien et les explications sont plus compliquées (dans le dernier échange on est à cheval entre les deux, on ne s'est pas bien compris). Et en fait en relisant mon message et en jetant un œil sur les captures d'écran de Plume Creator je suis bien sûr que tu vas être ennuyé très rapidement quand tu vas vouloir faire des choses un tout petit peu plus avancées, comme l'affichage d'informations sous une autre forme, la vue qui semble servir à comparer les textes de deux chapitres, la mini-carte, ... À ce moment si tu n'as pas très clairement distingué les données manipulées des composants graphiques tu vas bien te prendre la tête. Donc à moins que tu aies une objection majeure, je vais un peu attendre que tu décides de me faire confiance sur cette partie puis poursuivre mon explication dans ce sens ;) . Et ne t'inquiète pas, ça n'empêche absolument pas de reproduire le comportement du logiciel d'origine ; le fait que tu en doutes (et d'autres remarques, comme la question sur List/JList) me semble être le signe que tu ne parviens pas encore bien à distinguer les données de l'appli de leur représentation dans les discussions, à mon avis ce sera beaucoup plus clair avec la deuxième solution. Pour l'instant je ne réponds pas à ta question sur la duplication de données parce que je pense qu'elle est issue de l'échange embrouillée et qu'elle ne paraît pas nécessaire. Pareil pour la question sur List/JList. > Oui car c'est la même chose que pour les menus. Mais je manque > d'expérience dans le traitement des évènements. A part les menus je ne > sais pas trop comment ça se déclare, même si je vois à peu près > comment faire en prenant l'exemple des menus. Ça devrait fonctionner comme tu l'as fait pour les menus, la gestion des événements n'est pas très complexe à la base : - Une classe doit servir d'écouteur (implémenter XXXListener). Elle contient une ou plusieurs méthodes traitant des événements (ce qu'il faut faire quand un événement survient). Tu peux avoir une classe pour ça ou bien opter pour une solution plus simple qui consiste à utiliser ta fenêtre pour réaliser cette classe (c'est donc elle qui contient les méthodes de traitement des événements). C'est une solution acceptable tant que la gestion des événements n'est pas très complexe. Il peut aussi s'agir d'un onglet, panneau ou autre si tu as créé une classe pour ça et que les événements le concernent. - Une ou plusieurs méthodes doivent être écrites pour traiter les événements qui t'intéressent. - La classe doit être enregistrée comme écouteur sur le composant, pour indiquer qu'elle veut recevoir les événements. Ça se fait avec une fonction du type addXXXListener sur le composant source des événements (bouton, ...). Pour déterminer les événements interceptables sur un composant, tu cherches donc dans la doc (tu as toujours la doc pas loin ?) les méthodes addXXXListener de ce composant et tu regardes l'interface à implémenter pour la liste des événements possibles (par exemple si on écoute les événements de souris (MouseListener) il y a plusieurs événements comme mouseClicked, mouseExited, ...). Tout ça doit ressembler pas mal à ce que tu as fait avec les menus. Voilà pour cette fois :) . Il faut vraiment choisir une des deux solutions de conception, sinon les explications vont rester confuses. Tu verras qu'avec l'une ou l'autre ce sera plus simple de discuter et de s'y retrouver dans les concepts ;) . Et donc à mon avis si tu ne choisi pas la deuxième tu vas être encore plus embrouillé.