saintamand a écrit 88 commentaires

Moi ce que je lis surtout, c'est que tu ne sais pas utiliser ton éditeur de texte.

J'éditais le commentaire dans la textarea pas avec un éditeur externe.

dire « je n'en n'ai pas besoin » ne fait rien avancer.

Ce n'est pas ce que j'ai dit. J'ai juste fait remarquer que les situations qui nécessitent l'utilisation d'un retour à la ligne forcée sont plutôt rares.

on peut pas faire de maths

Et ça c'est quoi ? :-)

\Gamma^{\rho}_{\mu\nu}= \sum_{i,j,k}\frac{\partial x^i}{\partial x^{\mu}}\frac{\partial x^j}{\partial x^{\nu}}\frac{\partial x^{\rho}}{\partial x^k}\Gamma^k_{ij}+\sum_r\frac{\partial^2 x^r}{\partial x^{\mu}\partial x^{\nu}}\frac{\partial x^{\rho}}{\partial x^r}

Juste quelques modestes éléments de reflexion.

L'utilisation d'un simple retour à la ligne pour forcer un retour à la ligne est, à mon avis, une très mauvaise idée. Je ne connais d'ailleurs aucune syntaxe wiki qui l'utilise. Le retour à la ligne devrait être réservé à la mise en forme du source, de la même manière que beaucoup les développeurs l'utilisent pour mettre en forme leur code. En outre, j'imagine que certains contributeurs doivent utiliser un vrai éditeur, ce qui est beaucoup plus confortable qu'un textarea, surtout pour les longues contributions, d'où des problèmes certains pour ceux qui utilisent les retours à la ligne statique. Je suis entrain d'éditer ce commentaire dans Chromium dans une textarea «qui déborde» de la fenêtre (impossible de la redimensionner la textarea convenablement, y compris avec Firefox), si bien que je suis bien content de pouvoir utiliser les retours à la ligne afin de ne pas taper mes fins de lignes mon à l'aveugle. Et non je ne veux pas maximiser ma fenêtre, car les lignes de la textarea ont au moins 96 caractères ce que je trouve est inconfortable (je préfère 60-70 caractères), et ensuite cela m'empêcherai de mater une des conf. du FOSDEM en même temps.

L'utilisation du double espace a le défaut d'utiliser des caractères invisibles. En regardant le source, on ne sait pas si les retours à la lignes sont forcés ou pas. J'aime bien l'utilisation du double slash \\ que l'on trouve dans la syntaxe Créole. Néanmoins je pense que le double espace pose moins de problème que le retout à la ligne.

Mais finalement est-ce si important ? Le seul exemple qui me vient en tête où l'utilisation du retour à la ligne forcé est utile, c'est pour le formatage d'adresses postales comme sur une enveloppe.

J'édite la plupart de mes textarea avec vim.

Pourquoi ne pas utiliser un véritable logiciel de PAO ? Scribus est excellent.

Pour les boîtes de dialogues, est ce que cela touche toutes les fenêtres du logiciel?

Presque toutes. Informations, Astuces, Préférences et Sauvegarde de la base s'affichent au milieu de l'écran, les autres (ou presque je n'ai pas tout testé) s'affichent en haut à gauche.

Peut-on en savoir un peu plus sur votre distribution, version de java, etc?

• Debian Lenny,
• KDE 3.5.10,
• java version "1.6.0_22", Java (TM) SE Runtime Environment (build 1.6.0_22-b04), Java HotSpot(TM) Client VM (buold 17.1-b03, mixed mode, sharing)

Le logiciel doit également mémoriser la position des fenêtres, est ce que cela fonctionne?

A l'exception de la fenêtre principale qui persiste à vouloir s'afficher en haut à gauche, elles conservent leurs positions absolues.

Que proposez vous pour remplacer le fond jaune clignotant des champs pas ou incorrectement remplis?

Je trouve le clignotement pénible. Un simple fond de couleur ne suffit-il pas ?

J'ai testé la version monoposte. Je suppose qu'elle est isofonctionnelle avec la version multiposte. En tout cas, aussi intéressante puisse-t-elle être, ce n'est pas un ERP. Les possibilité de configuration sont faibles, pas de gestion fine des droits (un utilisateur est administrateur ou simple utilisateur), peu de modules et impossibilité de supprimer par exemple le module de compta, pas de moteur de workflow, ... En outre existe t-il un framework qui facilite la création de nouveaux modules, comme le propose OpenERP avec OpenObject ?

Il y a deux trucs que je trouve pénibles: les boites de dialogues s'ouvrent toutes dans le coin supérieur gauche de mon écran alors que pour toutes mes applications chaque fenêtre s'ouvrent au milieu de la fenêtre parente conformément à la config. de mon KDE 3.5 et enfin il y a les champs obligatoires dont le fond clignote lentement .... Grrrr! :-)

Je l'ajoute quand même dans la liste des projets à suivre.

Qu'on aime ou non Perl, le CPAN a influencé énormément de projets, dont, par exemple le CTAN le LaTeX.

C'est le CTAN, né en 1992, qui a donné l'idée à Rhine de faire la même chose pour Perl en 1993. Le CPAN est né en 1995 (1996 ?).


find . -execdir rename 's/ /_/g' {} +


Eventuellement ajouter l'option -n à rename pour éviter une bêtise.

Ce serait bien si le HTML était figé environ une semaine avant la date limite afin que les auteurs puissent corriger leurs CSS si nécessaire.

Pourtant je viens de vérifier, la licence est la LGPL 2.1.

Bonjour,

Pour des sites légers, tourne toi vers des logiciels qui n'utilisent pas de base de données:
- wiki: dokuwiki [http://www.dokuwiki.org/]
- CMS: PluXML [http://pluxml.org/]
- Blog: NanoBlogger [http://nanoblogger.sourceforge.net/]

Il y a le joli logo de l'ESIEA.

La première chose que je remarque est que le menu de gauche est inaccessible si le javascript est désactivé. Pourtant ce n'est pas faute de connaitre les principes de dégradation élégante ou d'amélioration progressive [http://en.wikipedia.org/wiki/Progressive_enhancement].

Pour un site statique de quelques pages en HTML, tu n'as pas trop à t'en faire.

Toutefois l'idéal serait de réduire aux minimum les droits d'accès à tes fichiers sachant qu'il suffit que le serveur web puisse accéder en lecture à tes fichiers. Si tu choisis un hébergement partagé tu seras très limité à ce niveau là. En revanche si tu t'auto-héberges, alors il te faudra surtout sécuriser le serveur ce qui est un peu plus difficile tout en restant très accessible [http://wiki.auto-hebergement.fr/].

Est-ce techniquement possible?

Surement. Décentralisé, données chiffrées, ... ça ressemble à un Facebook façon Freenet, non ?

Bonsoir,

Qu'est-ce que tu entends par «IP locale chez le FAI» ?

Sinon pour en revenir à ta question, c'est tout a fait faisable. En jouant un peu avec xmpp4r [1], une lib XMPP en Ruby, je suis tombé sur JabberDisk [2] un logiciel de partage de fichiers via XMPP. Le problème est que c'est un composant serveur alors que tu voudrais un bot.

[1] http://home.gna.org/xmpp4r
[2] http://dev.jabbim.cz/jdisk

WebDAV est une extension de http. Tu géres les utilisateurs et leurs droits de la même façon: depuis un simple fichier texte jusqu'à un annuaire LDAP en passant par une base MySQL. Regardes les modules Apache mod_auth_* . Pour le versioning, en natif il n'y a rien (à part quelques logiciels proprios je crois), mais c'est possible de l'implémenter avec SVN et le module Apache correspondant.
Pour naviguer dans les dossiers WebDAV, il existe peut-être des interfaces Web mais je n'en connais pas (à l'exception de Websvn mais seulement en lecture). Mais c'est bien plus lourd que de monter le partage et d'y naviguer comme sur un partage CIFS, NFS, ... avec les outils habituels (Konqueror, Nautilus, Finder, ...). Avec ces outils, le versioning est automatique, mais pour naviguer dans le dépôt SVN il faut passer par un client SVN, c'est donc moins accessible à des utilisateurs non techniques.

WebDAV est une extension de http. Tu géres les utilisateurs et leurs droits de la même façon: depuis un simple fichier texte jusqu'à un annuaire LDAP en passant par une base MySQL. Regardes les modules Apache mod_auth_* . Pour le versioning, en natif il n'y a rien (à part quelques logiciels proprios je crois), mais c'est possible de l'implémenter avec SVN et le module Apache correspondant.
Pour naviguer dans les dossiers WebDAV, il existe peut-être des interfaces Web mais je n'en connais pas (à l'exception de Websvn mais seulement en lecture). Mais c'est bien plus lourd que de monter le partage et d'y naviguer comme sur un partage CIFS, NFS, ... avec les outils habituels (Konqueror, Nautilus, Finder, ...). Avec ces outils, le versioning est automatique, mais pour naviguer dans le dépôt SVN il faut passer par un client SVN, c'est donc moins accessible à des utilisateurs non techniques.

Pour partager des fichiers, WebDAV est très bien et il est bien implémenté sur tous les OS courants. Il est facile à sécuriser (https). Pour le versioning (le V de WebDAV), il n'existe pas d'implémentation libre à ma connaissance. En revanche, cette fonction peut-être mise en place avec subversion_(logiciel) et le module Apache mod_dav_svn (aptitude install libapache2-svn sur une Debian/Ubuntu).

Une documentation: [http://svnbook.red-bean.com/en/1.5/svn.serverconfig.httpd.ht(...)]

LaTeX sait faire ce type de mise en page sans aucun problème.

Tu peux personnaliser les en-têtes et pieds de page avec le package fancyhdr et notamment y ajouter un logo avec un simple {\includegraphics{mon_logo}} dans la définition des en-têtes.

Pour personnaliser une classe, par exemple la classe article.cls, tu la recopies dans ton dossier de travail en la renommant en maclasse.cls. Au debut de la classe tu ajoutes

RequirePackage{color}


et plus loin tu modifies la définition de la commande \section selon:

\newcommand\section{\@startsection {section}{1}{\z@}%
{-3.5ex \@plus -1ex \@minus -.2ex}%
{2.3ex \@plus.2ex}%
{\centering\normalfont\Large\bfseries\color{red}}}


Tous tes titres de section des documents utilisant la classe maclasse.cls sont maintenant centrés et en rouge.

Sur http://zoonek.free.fr/LaTeX/ tu trouveras pas mal d'exemples pour personaliser tes documents.

Il y a de forte chance pour que DocBook soit ce que tu cherches. A partir d'un seul source, tu peux générer du HTML, du PDF, du LaTeX, ... L'inconvénient majeur est que c'est du XML, donc un peu pénible à saisir.

ou un fichier PDF qui a l'inconvénient de de ne pas permettre des commentaires sonores.

Au contraire, dans un PDF on peut inclure des fichiers audios, vidéos et même des d'objets en 3D. Les heureux utilisateurs de LaTeX peuvent utiliser la package movie15.

Je t'invite à jeter un oeil aux frameworks web (Django, Rails, ...). Faire une application de type CRUD avec de tels outils, c'est du gâteau.

Sinon à SIP, tu peux ajouter Drupal, Ez-Publish, et sans doute beaucoup d'autres.

1. Le nombre d'utilisateurs

Je parlerais plutôt de sa communauté. Sa taille est un critère important, mais plus encore, surtout pour l'utilisateur débutant, sa convivialité. M. X a 40 ans, un boulot, une femme et des enfants. Il n'est pas technophile, il fait des choses simples avec son ordinateurs (bureautique, web, courriels, photos basiques, ...). Il veut envoyer quelques photos de ses enfants à ses grands-parents par courriels depuis f-spot. Ca marche pas. Sur #debian-fr, il a toutes chances d'être mal reçu et de se faire jeter. On osera même lui rappeler que le code est libre et qu'il n'a qu'à le corriger. Sauf que M. X préfère s'occuper de sa femme et de ses enfants que de passer son week-end à chercher comment ca marche parce-que le logiciel est mal foutu. Sur #ubuntu-fr, on fera preuve de plus d'empathie, et on lui expliquera gentiment comment créer la clé dans la base de registres de gnome afin de disposer de plus de 30 secondes pour rédiger son courriel. Voilà pourquoi j'ai préféré installer une Ubuntu à M. X, qu'il trouve fantastique, plutôt qu'une Debian pourtant plus stable.