TImaniac a écrit 6420 commentaires

Commence par dessiner dans un JPanel plutôt que directement dans le JFrame.
Ensuite redéfini la méthode paint(graphics g) de ton JPanel, pas paintComponent. Pour finir je pense qu'il faut mieux ne pas mettre de gestionnaire de placement, cad mettre setLayout(null) dans ton JPanel. Par contre faudra peut être le resizer du coup.
N'hésite pas à faire des setBackground(Color.GREEN) pour voir si tes JPanel apparaîssent déjà bien dans le JFrame.
n'oublies pas d'ajouter ton JPanel au JFrame et de faire un pack() après.

En même temps MS a fait une grande partie de son monopole sur le fait qu 'on pouvait pirater ses produits, ce n'est donc pas contradictoire de voir que celà se pratique au sein de la firme.

Et combien même celà ne prouve strictement rien : si ca se trouve le cracker deepz0ne travaille chez MS et c'est la licence originale qu'il a acquise :) (sans parler du fait que dans bien des programme on met le nom qu'on veut dans la rubrique utilisateur)

Je me dois de pertinenter ton post :)

Juste un ou 2 détails :
trop compliqué (à développer / déployer / utiliser / maintenir) pour son but premier.
Je ne demande pas de faire un composant ou un API avec tout pleins de fonctionnalités, mais au moins proposer les même commandes que le programme console en version API. Pour ce qui est de la maintenabilité, je pense qu'il est toujours plus facile de séparer les préocupations, et faire une lib est peut-être plus compliquer à développer (celà demande plus de rigueur), mais conduit généralement à un ensemble de meilleure qualité, plus facile à maintenir, voir à déployer (on fait une lib on commence à faire gaffe aux problèmes de dépendances).
Même si dans tous les cas le développeur ne prend pas la peine de faire une doc, il sera de toute façon toujours plus facile d'interfacer une lib qu'une programme console : il suffit de matter le .h pour avoir déjà une bonne idée de ce que la lib risque de nous retourner comme message lors de tel ou tel appel.

pourquoi ne remplace-t-on pas ces programmes ?
Parcqu'ils sont performants, vieux et donc souvent éprouvés, comportant moins de bugs, et aussi pour assurer la compatibilité avec l'existant qui s'interface avec. C'est ça le boulet :)

Faire une version personnalisée (en l'occurence avec des maj) :
Hier je décide de faire un dvd official (enfin 2) à jour pour un collègue. Je supprime mes fichier locaux (le miroir de mandrake) avec les fichiers de conf, à même pas peur ;).

Effectivement tu as le choix entre :
- Windows, tu n'auras quasiment aucun problème matériel, mais quand tu en aura un, ben tu peux pleurer et tout réinstaller (mais si tu es vraiment paresseux tu peux toujours utiliser le sytème de restore).
- Sous Linux, tu as quasiment toujours un problème matériel, mais tu as toujours moyen de trouver une solution : mais là encore tu peux toujours pleurer car tu vas passer tes soirées à essayer de l'appliquer, et tu vas devenir croyant, en te mettant à prier Saint CVS que le prochain noyau ou le prochain driver compile enfin avec le support de ton matos. Mais l'avantage c'est que parfois on n'y prend goût, et heuresement ils ont pensés à tout : quand tu installe un nouveau noyau ou truc dans le genre, hop tu perds le support d'un autre matos ! et hop tu recommences :)
Mais c'est bien mieux que sous Windows, car là au moins tu aura appris :
- à utiliser cvs, make
- à éditer truc.conf
- à comprendre pourquoi être en root c'est mal (TM)
- à occuper tes soirées
- à mouler sur linuxfr pendant que ca compile

le commentaire ci-dessous (http://linuxfr.org/~BlueBird/(...)) me fait dire que c'est encore plus drôle qui n'y paraît : mettre l'accent sur le respect des interfaces et proposer une plateformes dont les interfaces vont évoluer en version final me fait dire que en plus d'être drôle c'est paradoxal, j'ai presque envie de dire stupide ?

oui je comprend bien, mais même si le noyau est stable, les interfaces ne le sont pas du tout, alors déclarer celà en version "finale" (qui en général signifie on y touche plus sauf pour corriger des bugs jusqu'à la prochaine version majeur) est un peu fort :)
En gros c'est une version pas finie (puisque les interfaces évoluent) finie. Mais j'ai un peu peur pour le support de ce genre de version "finale" : ils vont proposer des maj pour toutes les version expérimentales finales ? J'espère que y'en a pas trop :)

C'est rigolo quand même, c'est la première fois que je vois une version expérimentale sortir dans une version finale... une version expérimentale finale. Pourquoi pas.

Enfin le but était peut être de passer en première page de linuxfr, qui comme chacun le sait est limité aux versions à chiffre rond ;)

Moué toi tu pars du principe qu'un programme n'est censé répondre qu'à tes besoins. Effectivement on va pas aller bien loin si on ne peut même pas supposer qu'il sera utilisé par une tierce personne.

Moi ce que j'essai de t'expliquer, c'est qu'à l'heure actuelle, si tu veux faire un programme réutilisable, surtout dans le contexte du logiciel libre ou on prone la réutilisabilité et le partage, il me paraît impératif de tenir compte du fait que les utilisateurs ont évolués, que ce sont bien souvent des machines plutôt que directement des humains. A l'époque la ligne de commande était l'interface reine, les autres étant souvent délaissées voir ignorées, du coup on se retrouve maintenant avec un boulet à supporter.

Forcement que tu trouveras toujours un cas où la ligne de commande pour unique interface est simple, naturelle sans trop compromettre les perfs, mais celà donne souvent des hello world ou des programmes batch qui par essence n'ont pas besoin d'interactivité.

Pour en venir à ta remarques première :
Je ne vois pas ce qu'il y a d'absolument aberrant la dedans ...
Tu en conviendras que c'est abberant dans les cas où on a affaire à une application interactive, c'est-à-dire la plupart des front-end. Même si ce n'est pas toujours vrai, celà existe , c'est abberrant., et c'est un véritable boulet à traîner, ces programmes étant parfois iremplaçable.

PS : dans tous les cas, la communication inter-processus avec l'anglais comme protocole de communication entre 2 programmes est plus lourd et plus inefficace.

De rien, mais il a raison Dab, essai de parler français sans abréviations, c'est relativement pénible à lire :) Je sais ca fait djeuns-aware-hipe mais les linuxiens sont très attaché à ce qu'on ne massacre pas leur langue maternelle. De plus la plupart d'entre eux ne peuvent pas blairer les portables, alors ton orthographe est une sorte d'offense à leurs facultés sensoriels.

(Si ca peut te rassurer, les messages ne sont pas limités à 160 caractères :) )

Pour les mises à jour, n'utilise pas le truc rouge qui clignote en bas à droite, ouvre une console, passe en root (commande su) et utilise l'utilitaire de gestion de paquet yum comme ceci :
yum upgrade
il va aller tout seul sur internet chercher la liste des paquets à mettre à jour et te demanderas s'il peut les installer.
Plus d'infos par là : http://www.fedora-france.org/modules/wfsection/article.php?articlei(...)

Est ce que cette version est bien adaptée pr moi petit débutant ?
C'est un choix parmis d'autres. La fedora core 2 est censé être simple d'accès.

Comment installer des progs (genre lecteur mp3 ou divx) parceke bon G essayer av des aides sur différents site ms bon... sans succès koi !
il faut mettre à jour la liste des serveurs de yum, puis reporte toi à cette page :
http://www.fedora-france.org/modules/wfsection/article.php?articlei(...)

Et cmt faire pour voir mon 2e dur ki lui est en NTFS (ouindo XP) et pouvoir utiliser les fichiers ki sont dessus (genre mes muziks)
Tout est expliqué par là :
http://www.fedora-france.org/modules/wfsection/article.php?articlei(...)

Plus généralement, des tutoriaux pour la fedora core 2 :
http://www.fedora-france.org/modules/wfsection/(...)
Tout le site est dédié à ta distribution.

Arrête tu me donnes le tourni :)
Pour résumé :
- je t'ai posé une question
- tu connaissais pas la réponse et tu as répondus comme à ton habitude
- les lecteurs ont jugés que ton commentaire était loin d'être pertinent, sans doute vis-à-vis de ma question
Si tu prennais moins la mouche, si tu changeai un peu de ton (cet espèce de mépris pour les autres solutions que tu connais pas), tu te serais tout de suite aperçu que tu n'avais rien à répondre.
Conclusion tu aurais mieux fait de t'abstenir.
Bon allez bonne nuit, faut mieux arrêter là parcque ca devient légèrement "lourd".

(PS : fait comme moi : quand tu te fais moinsser unanimement, c'est qu'il y a une bonne raison : tu as sorti une connerie (c'est de ta faute), tu as fait du HS (c'est de ta faute), tu as répondu à côté de la plaque (c'est de ta faute), tu lâche des trolls sans le vouloir (c'est encore de ta faute), il y a un quiproquo : c'est de ta faute, fallait mieux t'exprimer)

Bah oué t'avais l'air de t'y connaître :)
Je m'attendais à un commentaire pertinent, apparement d'autres ont jugés comme moi, non pas que ton commentaire soit foncièrement faux ou dénué d'intérêt (quoique), mais non, question pertinence voilà quoi.

non :)
la meilleur réponse était de se taire et de laisser parler ceux qui peuvent répondre. T'imagines si dans une classe le prof demande si quelqu'un connait la réponse et que tout le monde gueule en coeur : "non mais ca me saoule blablabla".

Ben sors la même news sur SuSE 64 bits quand elle sortira on verra bien.

T'en a pas marre de râler ?
Sérieux si tu arrives à rédiger une news qui a un certain attrait, même si ce n'est qu'une pré-commande SuSE, elle passera peut-être, à défaut d'être une actualité passionnante, tu peux toi même la rendre passionnante par la rédaction. Ce n'est pas que de la discrimination de news, c'est aussi un jugement sur la qualité.
(Celà dis elle était peut être très bien rédigée ta news)

mais tu lis pas tes mails ou quoi toi ?

Réfléchi à la pertinence de ton commentaire qui répond à ma question :)

C'est rigolo parcque j'ai l'impression qu 'on est d'accord sur la pluparts des points du débat :)

C'est pas trop la mort à parser, et les perfs ne sont pas importantes.
Oué enfin dans le cas de ton lecteur mp3, comment tu indiques à l'utilisateur la position courante ? comment dans ton programme de gravure tu précises voir traite le message retourné par cdrecord ? C'est rarement une communication On/Off, même pour ds programmes aussi triviaux. Comment tu sépares ce qui est une erreur et ce qui n'en ai une simple information, voir un résultat ? Sachant que la doc ne te renseigne pas du tout sur la nature des messages retournés à parser, c'est à toi de te démerder, la doc t'indiques juste quoi appeler.
Rien que dans k3b tu vois ca m'énerve sérieusement que quand il foire une gravure il me dise juste "cdrecord a retourné une erreur". Ouh merci pour l'info.

C'est sur, mais bon, pour lancer un mp3 ou une gravure, on va peut-etre pas non plus faire une norme ISO hein ? :)
Bah non mais tout bêtement on expose les APIs qu'on a du faire pour les utiliser. C'est juste une question de bonne pratique : on sépare ce qui fait le boulot de l'interface (même console), auquel cas ce n'est absolument pas plus dure de proposer celà aux programmeurs en plus.

(Au fait ce que je dis s'applique également aux fichiers de conf sous Unix/Linux en général : personne n'a la même syntaxe, c'est imbittable à parser par une application tierce-partie.)
Quelle différence il y a entre une API maison ou une ligne de commande maison ?
Dans un cas c'est documenté, pas dans l'autre. Dans un cas les moyens de comunications sont multiples et dans l'autre réduit au parsing. C'est d'une abberation total, regarde :
- le front-end transforme un appel de méthode interne en chaîne de caractères compréhensible par le programme console
- le programme console parse la chaîne de caractère et transforme celà en passage de paramètre d'une méthode appelée derrière.
C'est pas un peu très idiot ?

- gérer tous les projets avec des methodes lourdes (sauce RUP)
- gérer tous les projets avec des methodes légeres (sauce XP)
Juste pour la précision, RUP tire pas mal de pratique de XP et les 2 sont complémentaire et à choisir selon l'effectif. Enfin emrci pour l'historique, même si je ne vois pas en quoi celà va dans ton sens :)

S'interdire des approches c'est se compliquer la vie dans les cas où l'approche n'est pas appropriée.
Bah voilà exactement, et avec certains programmes qui croyait proposer une interface "universelle" par console, on se retrouve avec des aberrations parcqu'ils n'ont pas voulu proposer d'API, petit plus pas bien compliqué qui faciliterait la vie de bien des applications.

il prend mon programme et en fait une lib s'il a besoin d'une lib.
Oui effectivement, seulement si il a les sources.
Celà peut être légitime de se dire qu'on a pas envie de se casser le cul pour d'éventuels utilisateurs, mais le minimum, à l'heure actuelle, et quand même de se dire que notre programme a de grande chances d'être utilisé par un utilisateur qui n'a rien d'un être humain, et pour qui la langue de shakespeare distribuée au compte goute dans un format à la con (chaîne de caractère) n'est pas du tout un moyen de communication privilégié.

J'ai cité 2 exemple qui sont tout à fait convenables en termes de GUI et qui marchent très bien comme ça.
Comme je te l'ai indiqué plus haut, même pour ces 2 cas précis c'est insuffisant. Si le volume change ou si bêtement le lecteur n'arrive plus à lire un morceau, etc, il y a pleins de messages à parser si on vuet qu'il y est un tant soit peu d'interactivité. Pareil pour la gravure, faut bien indiquer en permanence l'état des buffers, signaler des messages sur la vitesse courante de gravure, bref, il y a une interactivité permanente et donc des communications permanentes avec le programme console.

Si tu fais une lib ET une commande, tu devras probablement te taper deux fois le controle
Euh, dans le cas de la lib, il n'y a pas de vérification de débordement à faire, tu passe des vrais valeurs dans des vrais types en arguments, pas besoin de parler en anglais dans une string. Et puis bon, les contrôles de débordement de chaîne de caractère, c'est bon pour les programmeurs C qui veulent tout faire à la main, et encore ils peuvent utiliser la glib pour faire le boulot.

e pense que tu n'aimes pas les mêmes gens que moi : les gens qui fustigent une techno et qui sont des boulets à cause de leur inaptitude a s'adapter au but parce qu'il sont limités à une seule approche.
Comme je l'ai dit plus haut, ce n'est pas l'utilisateur que je considère comme un boulet, mais plutôt des habitudes du passé, qui se sont transformées en boulet avec le temps, parcque les technos étant dépassées.

Mais tu vois, j'attend toujours des arguments en faveur de la ligne de commande uniquement, et décidemment, même pour cdrecord je vois que des inconvénients.

Et puis, la perte de perf n'est vraie que pour la génération des parametres et le passage de ces paramètres.
Et également pour la récupération du résultat aussi : bref, partout où tu utilises le programme il y a perte de perfs. Sans parler de l'absence de tous les protocoles spécifiques à la communication entre programmes : types de données, exceptions, synchronisation, etc.
Sans parler qu'il a création inutile de processus quand un simple thread suffirait voir rien du tout.

Pour reprendre ton expression, on a pas inventé la redirection des I/O standard pour les chiens non plus.
Non effectivement on a inventé celà y'a 20 ans, en croyant qu'on allait pouvoir tout faire avec ça, et maintenant c'est ce que je désigne un boulet, parcque de nombreux programmes ont été conçus sans du tout penser à proposer une interface de programmation plus avancée EN PLUS (pas à la place).

L'autre limitation de l'utilisation d'une commande c'est que ce n'est pas le pied pour un processus interactif, dans ce cas, c'est sur qu'il vaut mieux éviter.
interactif, bref c'est valable pour la plupart des GUIs. C'est également un gros reproche de ces programmes en ligne de commande : le manque d'interactivité, de retour utilisateur. Et le parsing de la sortie standard voilà quoi. Soit c'est simple à utilisé et il n'y a aucune interactivité, soit il y a une sortie verbeuse, longue, lourde et contre-performante.

je ne vois pas ce qu'amènerai de plus l'utilisation d'une lib.
Tout ce que j'ai expliqué plus haut : une programmation beaucoup plus aisée des front-end, une lourdeur bien moins importante (pas 36000 processus et pourquoi pas une gestion multi-requête comme un serveur)

Bof, je continue à penser que c'est une IPC comme les autres qui a ses avantages et inconvéniants
Tu m'as cité des inconvénients, je t'approuve forcement, mais je cherche toujours les avantages de n'avoir QUE une interface console (et pas d'API en plus).

Enfin si toi tu préfères te taper de la communiactions inter-processus (et la gestion des erreurs qui va avec) avec redirections d'entrées-sorties avec parsing de la sortie et formattage de paramètre plutôt que de faire :
resultat = monAPI.truc(param)
c'est toi qui voit. En tout cas tu confirmes ce que je disais : pour linux aussi les habitudes des utilisateurs sont un vrai boulet à traîner.

D'un point de vue utilisateur, du moment que ça répond au besoin, on se contrefout de comment c'est fait...
Euh, désolé mais on a inventé les bibliothèques et les composants c'est pas pour rien. Alors moi je dis non, on ne se contrefout absolument pas de comment c'est fait : lire et écrire sur les I/O d'une application console est vraiment idiot et contre-performant. La ligne de commande est une interface homme machine comme une autre. Chercher à utiliser cette interface pour faire du dialogue machine-machine, voilà quoi.
Bref, on file une lib, on propose donc un ensemble d'API pour les autres programmes, et on propose aussi une interface console pour ceux qui veulent. Mais par pitié on n'essai pas de piloter une interface console avec une application graphique.

Sauf que MS a voulu concurrencer Java bien APRES sa sortie alors que pour le cas du HTML ils ont implémenter un format AVANT qu'il soit standardisé.

Dans la logique de l'article, les PC de particuliers ne sont pas particulièrement concernés et les pirates préfèrent les serveurs (ce que je comprend), et la posiiton des serveurs Linux dans ce domaine est quand même pas du tout la même que chez les particuliers...

Ca fait plusieurs fois que je vois ces chiffres, mais je me pose une question : si on prend au peid de la lettre ce qui est dit, les pourcentages ne tiennent pas du tout compte de la proportion des OS étudiés. Si MacOSX ou autre BSD représentaient moins de 5% des OS étudiés, les chiffres sont tout à fait logiques, la position de Linux pouvant alors être expliqué par une plus forte présente que ses concurrents côtés serveurs...
Si quelqu'un peut m'éclairer sur le sujet, histoire que je puisse faire mes propres conclusions :)

Tiens puisque tu as l'air plutôt convaincu par subversion, peux-tu me dire quels sont les avantages/inconvénients par rapport à Arch ?