RestrictionsAlEdition

A propos des restrictions à la consultation et à l'édition sur ce wiki (groupe machin et groupe chose qui peuvent faire ci et pas ça, et le groupe du sous-groupe... (public/member/team/staff/kern/califat/...).

Est-ce bien utile?

|<blockquote> Il est vrai que vu les modifications apportées ça ne devrais plus porter le nom de wiki, quelqu'un à un autre nom à proposer? -- Renaud |</blockquote> Oui, bon, pas d'intégrisme, comme le dit Renaud ci-après, il s'agit simplement de mettre en place un système souple, pour ne pas reconfigurer 46x. Il est clair que, par défaut, on doit toujours choisir l'ouverture maximale (et par exemple, une fois les modalités clairement convenues, les discussions Europrof passeront sans doute sur le wiki public..). L'origine de tout ceci n'est d'ailleurs pas la volonté de rendre certains membres "plus égaux que d'autres" mais au contraire de pouvoir ouvrir partiellement le wiki des membres à des personnes extérieures. Le wiki privé sert à la cuisine interne, et beaucoup de membres (moi y compris) ne veulent pas qu'elle soit déballée sur la place publique (ils acceptent qu'on utilise l'outil wiki, c'est déjà bien..) --snulkid

Que quelqu'un écrive des bêtises aux quelles je n'ai pas accès, cela ne me dérange pas, mais je suis profondément frustré de ne pas pouvoir réagir à ce que je peux lire...

|<blockquote> Cela est venu du désir d'un certain nombre de personnes de disposer d'un espace ou il serait possible de partager des choses, mais avec cependant une certaine sécurité du contenu. Cela n'est pas encore très utile car parmis les personnes enregistrées sur le site nous avons relativement bien confiance les uns envers les autres. Mais le système a été prévu à plus long terme.
Par exemple, on peut vouloir donner un login à des personnes désirant travailler sur le projet EuroProf (en attendant qu'il aie un autre nom) sans pour autant vouloir devenir membres. Ces personnes n'ont pas à pouvoir modifier des choses qui concernent les membres (comme la page MembresDispo et l'OrdreDuJour) et dans certains cas n'ont même pas à en prendre connaissance (il y a des choses que nous préférons garder privées, au moins pendant un certains temps).
Pour ce qui concerne EuroProf (je parle du projet de programme), si tu désire participer (même occasionnellement), il suffit de demander à faire partie du groupe europrof et t'inscrire sur la ML [email protected] (en attendant une ML dédiée lorsque cela s'avèrera nécessaire)
Note que le système ne t'empèche pas strictement de réagir, puisque, comme tu l'as fait, il est toujours possible de créer une nouvelle page (ça risque juste de foutre un peu le bordel). Le système permet de protéger du contenu en édition/visualisation, si désiré. -- Renaud |</blockquote>

C'est à propos de l'utilisation de plugins...

Réginald (et/ou d'autres?) trouvent que c'est trop lourd (machines puissantes pour faire tourner Mozilla et/ou nécessité de connexion Internet). Moi, je trouve que c'est facile, sans risque et que cela augmente l'audience potentielle.

Rien n'empêche de faire une version "internet" plus tard mais c'est exact qu'a priori, on veut pouvoir utiliser un programme léger, ne nécessitant même pas de connection réseau sans sacrifier des fonctionalités. Au niveau plugins, on s'est mal compris : je n'ai pas dit que c'était trop lourd, c'est l'emploi systématique d'un navigateur complexe qui est trop lourd.. On parlait de plugins qu'on créerait nous-mêmes (au besoin) pour notre programme, pas spécialement des plugins traditionnels pour navigateurs. Le but étant d'alléger au max le framework en en retirant les fonctions rarement utilisées.

Je suis en train de surfer (sous windows, comme un gros veau) à la recherche de programmes d'orthophonie (à l'école des devoirs, il y a, me semble-t-il, une petite fille qui a de grosses difficultés de lecture (dyslexie?))...

Et bien, cette simulation en ligne me pose beaucoup moins de problèmes que les '.exe' disponibles par ailleurs en packages '.zip'. Il faut bien-sûr que cela soit facilement exécutable en local également. De plus, tout le monde peut surfer. Moins nombreux sont ceux capables de faire un 'tar xvfz', moins encore les adeptes du 'rpm ??' (j'ignore quelles sont les options je n'ai jamais eu le courage de lire les 100 (?) pages de documentation tout ce qui m'intéresse, c'est de voir quel est le contenu et l'extraire...). Quant à 'apt-get install', c'est bien pratique, mais je n'ai pas de Debian. Et tous ceux qui sont sous Windows ou Mac, je n'en parle pas...

La mauvaise nouvelle, c'est que les plugins les plus populaires ne sont pas spécialement OpenSource ou agréables à programmer (par exemple, Flash ou Java). La bonne nouvelle, c'est que (si je ne me trompe), il existe des plugins Python (? à confirmer) ou Tcl/Tk (dont la lisibilité n'est pas extraordinaire, mais qui permet de faire facilement du graphique. Par exemple, je viens de me laisser piéger pendant près d'une heure par Tetris... . (Rem: celui-ci est terrible aussi...)

--xof

Rien n'est décidé mais on avait suggéré de pouvoir utiliser Python au moins pour écrire des plugins. On (je) suppose que c'est plus facile que de créer le framework, avec un langage optimal (C++?), et que ça permettra donc à plus de gens de participer. Mais je n'y connais rien : quand on voit le nombre énorme de plugins que Gimp charge au démarrage, est-ce sans problème ou bien cela pénalise-t-il sensiblement les performances globales du programme ?? --snulkid

Le contenu de cette page est librement éditable et n'engage donc que son/ses auteur(s). LiLiT asbl n'en assume en aucun cas la responsabilité et se réserve le droit de retirer tout contenu jugé inaproprié.