Epsilonwiki

Epsilonwiki joue avec mumuwiki , le 25 décembre 2010 par alain marty

epsilonwiki se souvient de rowiki, son lointain ancêtre. Et parfois vient l’envie d’en revenir aux sources. D’où l’écriture de mumuwiki dont le moteur est contenu dans un seul fichier de 115 lignes de code PHP + CSS + HTML.

Juste pour le fun :)

Epsilonwiki a remplacé feu almawiki , le 22 mai 2011 par marty alain

Une autre étape ici : http://marty.alain.free.fr/_www !ki/

Votre avis m’intéresse.

-----> http://marty.alain.free.fr/_www!ki/

Almawiki , le 26 novembre 2009 par lebendre

Passez par le wiki pour mettre à jour la notice !

http://wiki.framasoft.info/PropositionNotice/Almawiki

Almawiki remplacé par epsilonwiki depuis 3 ans , le 12 juin 2010 par amarty

Bonjour, j’ai bien suivi il y a déjà quelques temps la procédure pour remplir la notice à cette adresse : http://wiki.framasoft.info/PropositionNotice/Almawiki, mais je voudrais bien savoir si elle a une chance d’être un jour validée, ou au moins corrigée. Je me doute qu’il faut du temps et que c’est ce qui nous manque à tous :)

Merci d’avance

-----> http://wiki.framasoft.info/Proposit...

Almawiki -> taille police par défaut , le 15 décembre 2007 par alain marty

Bonjour,

Almawiki est devenu epsilonwiki depuis longtemps Plusieurs solutions :
 utiliser le zoom du navigateur, dont l’effet est constant sur toutes les pages ; mais d’accord, il faut le faire !
 régler la taille de chaque page en utilisant la balise epsilonwiki : _div(font-size:1.5em|contenu de la page) - remplacer les () par des accolades - où 1.5em est par exemple la valeur CSS qui augmente de 50% la taille des textes de la page et ceci proportionnellement ; cette solution est valable si cette modification n’a pas à être systématique, sinon ...
 modifier la feuille de style choisie en écrivant par exemple dans la règle correspondant à la balise body : " font-size:1.5em ; ". C’est la seule solution acceptable si le choix est systématique et cette solution donne accès à tous les autres réglages sur les styles. Il faut connaitre un minimum la syntaxe CSS et travailler sur une copie de la feuilles de style.

Un exemple est visible à cette adresse : test

J’espère avoir répondu à la question, merci pour l’intérêt que vous portez à epsilonwiki et très curieux de voir ce que vous en aurez fait :)

Alain Marty

epsilonwiki , le 4 juillet 2007 par alain marty

Dernières fonctions ajoutées à epsilonwiki :
 verrouillage (optionnel) par mot de passe sauf pages forum et sandbox laissées en libre édition
 et téléchargement de certains types de fichiers

Toujours pas de gestion de thèmes. Pas envisagé pour l’instant. Plus tard peut-être ...

alain marty / 04/07/2007

-----> espsilon++

Almawiki , le 12 septembre 2006 par elrik

Bonjour !

va sur le site officiel, clique sur "admin" puis sur wikimodèle.zip".

Cordialement.

Almawiki [vérouillage/dévérouillage] , le 21 août 2006 par alain marty

Il m’arrive d’avoir ce problème sur Firefox Mac ou PC (je n’ai pas accès à Linux pour l’instant). En général il suffit de cliquer dans un autre champ pour forcer la validation des entrées et ça repart, ... sans avoir à fermer puis ouvrir le navigateur. J’espère que cette manip suffira à régler votre problème.

alain marty

Almawiki [vérouillage/dévérouillage] , le 22 août 2006 par fun sun

Bonjour alain,

J’ai testé sous win et sur un serveur local, ça marche bien. Comme très probablement le logiciel sera utilisé sous win donc ce ne sera pas gênant. Néanmoins merci pour l’info :-)

Almawiki HTML ??? , le 20 août 2006 par Fabien

Affaire de goût ! Personnellement, je cherche depuis longtemps un wiki utilisant HTML, et non une syntaxe particulière et tout aussi ch***te à aprendre. Un internaute moyen aujourd’hui utilise du BBcode sur tel forum, un codage su tel wiki, un autre codage sur tel autre wiki. Ad nauseum.

Il y a véritablement besoin d’une standardisation, et ma foi à ce jour il n’existe en ce sens qu’html.

Almawiki HTML ??? , le 20 août 2006 par alain marty

Merci pour vos commentaires. Quelques éléments de réponse :

Concernant le choix du HTML :

Je comprends tout à fait votre point de vue et ça a été mon premier réflexe, mais j’ai été amené à en changer et à privilégier le choix HTML. Je m’en explique dans l’aide (page raccourcis wiki, titre "en somme"). Encore un peu de patience et les éditeurs des navigateurs deviendront WYSIWYG (j’ai connu WordStar sur PC (voici par exemple la mise en gras : ^Bgras^B) et j’ai apprécié MacWrite, le premier WYSIWYG. L’évolution qu’on a connu en bureautique on va la connaître sur le web, et les fichiers en pur HTML (dérivé du XML) seront les seuls à être encore facilement lisibles demain.

Concernant le bouton "édition", a priori masqué :

Ce bouton n’est masqué que dans les thèmes "lessismore" et "moreisless", et il suffit de cliquer sur les quatre points rouges du titre pour afficher/masquer le menu de gestion ainsi que le ligne d’informations. C’est un choix qui me semble apporter plus de force au contenu. Ca me paraîssait assez élegant sans être génant, à la manière de Tiddlywiki, superbe travail à aller voir.

Concernant la mise en page normalisée :

Ca existe bien sûr, mais mon projet était de faire ma propre recherche en la matière et de ne pas m’enfermer dans tel ou tel choix. La structure du wiki d’un atelier d’architecture (ex. : http://amartyfree.free.fr/ensam.wiki/S8_archilegere/ ) la présentation du programme, du planning, des référents, du journal, des sites étudiants, ... n’est pas la même que celle d’un wiki présentant un article de recherche (ex. : http://amartyfree.free.fr/pformes/ ) ou de celui présentant une base de données sur les matériaux (ex. : http://amartyfree.free.fr/ensam.wiki/materiautheque/ ) ; le wiki d’un artiste ne ressemblera probablement pas à celui d’un matheux et il ne s’agit pas simplement de graphisme.

La totale liberté offerte par "la page blanche et sans cadre pré-établi" d’un wiki permet de tester des tas de présentations, le prix à payer étant de manipuler quelques règles élémentaires de CSS.

N’avez-vous jamais eu à entrer une relation entre des cellules dans un tableur ? Pas évident d’écrire : =somme(K2:K56), mais tellement puissant. Pour moi un wiki c’est un peu le tableur du web...

concernant le SVG :

vous prêchez un convaincu, j’en rêve ... cf par exemple la page recherche / svg dans http://amartyfree.free.fr/alain.marty/ ; mais savez-vous que le SVG c’est un petit cousin de (X)HTML, enfants de XML et que la plupart des éditeurs de tous types d’informations (texte, calcul, dessins,...) offrent de plus en plus un export XML ?

concernant le GPL :

le seul petit reproche que je faisais à rowiki était sur l’illisibilité du code, ce qui enlève beaucoup au caractère GPL/échange de savoir du travail ; j’ai écrit le code d’almawiki de la façon la plus lisible possible (à mes yeux), j’y ai ajouté quelques fonctions sans trop l’alourdir j’espère, et je serai ravi que vous puissiez l’analyser et y apporter des améliorations. Merci encore pour votre intérêt.

alain marty

Almawiki HTML ??? , le 20 août 2006 par Bern JAURE

Moi, j’adore Almawiki !

C’est simple et sobre. Esthétique en diable.

J’ai fait à peu près le même itinéraire qu’AlMa (sans être créateur).

 Simplifier les choses est prépondérant.
— Il faut être polyglotte (et parfois connaître, de plus, des dialectes sous-dérivés ...) pour communiquer simplement sur ses propres thèmes, en définitive, quelque soit l’outil à écrire employé.

Bien sûr ! On aime "mettre les mains dans le cambouis", faire de l’enluminure, gérer la technique qui rendra la page plus attrayante ou le script qui irait bien...

Et les développeurs existent heureusement.

Mais parfois, on se dit que si l’auto était aussi compliquée que certains domaines de l’informatique, nous serions (ceux qui resteraient) des "customizer".

Alors, le mieux ne serait il pas l’ennemi du simple ?

Merci Marc Rohlfing, Merci Alain Marty

Almawiki HTML ??? , le 20 août 2006 par elrik

Moi, j’adore Almawiki !

C’est simple et sobre. Esthétique en diable.

Content que quelqu’un ait le même avis que moi sur almawiki : merci !

Cordialement.

Almawiki avec option wiki , le 21 août 2006 par Patrick Bougé

Je suis certain que almawiki est très bien (et c’est le cas), et c’est vrai que c’est joli et surtout léger. L’histoire de l’édition je n’avais pas compris autant pour moi.

En revanche, pendant qu’il est encore en développement, simplement j’aimerais plus de "liberté" sur la syntaxe et le paramétrage...sans tomber nécessairement dans l’usine à gaz, avec quelques éléments simples au niveau administrateur.

Juste une petite partie permettant à l’utilisateur de définir sa propre syntaxe liée aux mots clés standards de mise en forme serait bienvenue, sous la forme d’un fichier config séparé, par exemple, une table de correspondance...

Sans vouloir troller sur un sujet à propos duquel la messe est déjà dite depuis 15 ans, il est évident que HTML est la syntaxe universelle web, c’est ainsi. Mais ca n’empêche pas de toujours aller vers une recherche et une évolution de ces normes qui sont faites pour êtres remplacées un jour : on les acceptes et on les trouve bien parce qu’elles remplissent aujourd’hui un vide, mais quand même, elles ne sont pas ce qu’il y a de mieux sur le plan syntaxe en informatique. Le moins que l’on puisse dire, c’est que l’on ne facilite pas la vie aux parsers.

L’assembleur pêche parce que sa syntaxe est trop légère, elle manque de sens intelligible pour le commun des mortels. Les langages à balises tombent exactement dans le même défaut en tombant paradoxalement dans l’exces inverse : ils rajoutent trop de sens, trop de structuration et trop de redondance, ce qui pollu le contenu et rend tout aussi inintelligible que pas assez (un peu comme ma propre façon d’écrire ;-) ).

SVG, je suis adepte parce qu’avant, il n’y avait rien du tout (sauf flash...mais bon...) : ca remplit le vide du vectoriel. Mais je reste convaincu qu’il aurait exactement la même qualité sans ce tas de balises de partout : Pour faire un cercle rouge sur fond blanc, il y a plus de balises que d’informations pour dire 4 choses : "rouge" "cercle" "fond" et "blanc". Un comble. C’est pour moi tout le problème de la syntaxe avec balise : le rapport entre l’information transmise et le nombre de signes employés est très mauvais.

XML n’est là que pour représenter une norme rendant compatible entre eux tous les outils qui l’utilisent : un metalangage universel. Sa seule qualité n’est donc que d’être partagé et admis par tout le monde (faute de mieux), et non pas d’être basé sur le choix de syntaxe le plus judicieux, le plus clair et le plus ergonomique du monde. Donc si un jour on décidait d’en garder les avantages, sans en avoir les inconvénient (la redondance et le manque de discretion), on pourrait.

Une limite évidente : aujourd’hui on tente de définir un WEB réellement sémantique avec l’ajout de tags ontologique sur les contenus : l’utilisation de ces balises rend a priori, la déclaration et l’affectation des types ontologiques inexploitable tellement le travail est laborieux...on peut donc prévoir par avance un flop d’une initiative qui serait capitale avec une meilleur forme. On ne voit même plus les tags on ne voit que des <> > partout, les doigts sont plus sollicités sur le clavier que sur une partition de Chopin en ré mineur.

L’anglais, on ne peut pas le remplacer comme langage universel, c’est trop tard. Pour les systèmes d’exploitation et la bureautique, on est pas loin d’être au même point (même si on soutient Linux et Openoffice). Mais sur le WEB, on en est au début, on a encore le choix de l’évolution, du langage et de sa construction...et de son ergonomie. Alors, on peut encore critiquer, demander et faire autre chose et c’est une chance.

On parle souvent de séparer le contenu de la présentation, la forme et le fond. Alors, regardez un code développé avec un langage à balise, quoi que l’on fasse, les balises sont massives, partout, aussi présentes et aussi visibles que le contenu lui-même, haché en tout petits morceaux incompréhensibles et non repérables. Un paragraphe correctement mis en page ne tiens même pas sur un écran normal (Le pire : un tableau en HTML...une sainte horreur).

Les CSS n’ont rien arrangé du tout à ce propos, au contraire, on a des "div" en plus.

Même avec une couche graphique par dessus, ça ne servira à rien et ca ne changera rien à la qualité du langage dessous : si derrière le wisiwig, il y a une syntaxe plutôt bien faite, c’est mieux.

Latex le montre suffisament par rapport à des outils comme word. Malheureusement la syntaxe de Latex n’est pas une norme du WEB, il en aurait pourtant fallu de peu pour qu’il soit une bien meilleure référence que le HTML. Et enfin, je trouve le principe de la syntaxe WIKI, pour peu qu’elle soit généralisable bien meilleure encore sur tout point de vue.

Au contraire une bonne syntaxe et une bonne norme permettent souvent de passer outre l’aspect graphique, plus facilement...en terme de programmation, la surcouche graphique est souvent là pour récupérer ce qui est mal construit au départ. On ne cherche jamais à dessiner ce qui se dit en quelques mots parce que c’est inutile, plus long et moins précis.

Pour moi, dans l’ensemble des langages à balise qui sont développés jusqu’à aujourd’hui, certains mots clés vont rester parce qu’il n’y a pas de raison ergonomique, pas de meilleur remplacant et il faut réutiliser au maximum l’existant.

En revanche, ces principes de redondance systématique avec balises ouvrante et fermante, les div id de CSS, les guillemets, deux points et autres points virgule qui trainent...ça disparaitra naturellement dans le temps.

On reviendra à des signes de ponctuation plus communs, moins "gros", moins présents, moins fréquents, laissant réellement place au vrai contenu, celui que l’on veut présenter, comprendre et recorriger par la suite.

Almawiki HTML ??? , le 21 août 2006 par alain marty

Merci pour ces précisions.

Options wiki ? D’accord. Dans le code j’ai mis en évidence deux fonctions ( wiki_security() et wiki_syntax() ) qui peuvent être modifiées à la demande, et qui pourraient être effectivement placées dans un fichier config externe.

 La première filtre les entrées dans un compromis discutable entre la liberté et la sécurité. Les idées sont les bienvenues.

 La seconde traite les raccourcis wiki, au début limités à la simple gestion des liens internes, progressivement étendus aux liens externes, mails, images, ... La aussi chacun peut en ajouter, en veillant à assurer au mieux la retro-compatibilité avec les pages existantes qui commencent à être nombreuses.

La syntaxe wiki proposée par Ward Cunningham en 1995 était élégante avec le principe de la casse chameau, l’interprétation immédiate des URL et des adresses mail. La suite est moins élégante et chaque wiki a sa solution, incompatible avec les autres. Et donc pourquoi pas le HTML, et au delà la famille XML dont SVG entre’autre fait partie.

Concernant la lourdeur des langages à balises, on pourra en discuter longtemps, et personnellement je ne me sens pas assez compétent pour remettre en cause un système qui a au moins réussi à apporter la standardisation dans la gestion de tous les types d’information, quelle que soit la plateforme et le logiciel permettant de créer, éditer, visualiser et échanger les informations. Entre la base de registres de WINDOWS et la gestion XML-like des préférences et autres paramétrages système de MACOSX, mon choix est fait.

Je me souviens des critiques portées sur la programmation objet, avec son cortège de complications et de lourdeurs qui allaient engorger inutilement les processeurs. Les compilateurs peut-être, pas les processeurs et aujourd’hui tout ce que nous touchons sur nos écrans est fondé sur une programmation objet.

WYSIWYG (sans excès de boutons et dialogues) en surface, XML propre (texte balisé éditable directement) sous le capot, navigateurs équipés d’interpréteurs rapides et/ou compilateurs de code à la JAVA, il y a du blé à moudre pour quelques temps avec en tête l’objectif de produire le plus facilement possible des informations partageables et pérennes.

Je suis d’accord, il y a du travail sur la planche et les choix sont difficiles.

Alain Marty

Almawiki , le 18 août 2006 par kbp.meo

Bon, tes besoins persos -moi je- ne se satisfont pas de ce produit, dommage pour toi. Quel intérêt en ce cas de venir en parler ? Ton post, finalement, aurait plutôt sa place dans la rubrique :

« les logiciels libres que J’utilise »

Mais finalement, ce genre de post a une utilité : ça donne envie d’aller voir le soft dénigré ! Comme ça, je connais almawiki, même si je n’ai pas besoin de wiki : merci l’ami, et sans rancune !

La critique même négative, c’est bien... , le 19 août 2006 par FabriceV

Almawiki , le 19 août 2006 par elrik

Que manque-t-il, selon vous, à la notice, pour être plus juste dans la présentation de ce logiciel ? J’ai cru avoir exprimé clairement les limites du soft par sa comparaison avec roWiki, mais il semble que ça soit insuffisant. Je rejoins fabriceV sur le fond, mais j’aimerais une aide pour améliorer mon écrit.

Au premier posteur, hélas anonyme :

Je conteste juste l’emploi du terme "simpliste", car il me semble péjoratif.

j’ai écroulé DokuWiki niveau temps de réponses avec ses fichiers textes, alors que Wikka me sert sans broncher

On ne peut comparer que ce qui est comparable, j’ai écrit :

Almawiki suffira amplement à la gestion de projets simples

Ton projet ne me semble pas simple, il ne rentre donc pas, clairement, dans l’usage d’Amalwiki.

Sur le fond de ton post, il me semble inélégant de venir faire la promo d’un wiki, fut-il meilleur, sous la notice d’un autre : Wika wiki manque-t-il donc si cruellement d’afficionados pour avoir besoin d’une telle mise en lumière ?

Cordialement.

Almawiki , le 20 août 2006

Quand à savoir si le bouton de la barre des machins en bas à droite était lissé et celui du haut ombré pendant que je tapais, c’est le cadet de mes soucis. Je veux du simple et de l’efficace, du reposant justement, du pas compliqué...

J’ai lu çà ailleur, mais je trouve que c’est bien de le mettre ici. Pourquoi faire compliqué quand il ya plus simple ? Pourquoi l’élite viens toujours nous faire ch... avecson avis chébran "moi je sais tout c’est pour vote bien".

Tu devrais faire de la politique !