
Recherche avancée
Autres articles (67)
-
Use, discuss, criticize
13 avril 2011, parTalk to people directly involved in MediaSPIP’s development, or to people around you who could use MediaSPIP to share, enhance or develop their creative projects.
The bigger the community, the more MediaSPIP’s potential will be explored and the faster the software will evolve.
A discussion list is available for all exchanges between users. -
MediaSPIP Player : les contrôles
26 mai 2010, parLes contrôles à la souris du lecteur
En plus des actions au click sur les boutons visibles de l’interface du lecteur, il est également possible d’effectuer d’autres actions grâce à la souris : Click : en cliquant sur la vidéo ou sur le logo du son, celui ci se mettra en lecture ou en pause en fonction de son état actuel ; Molette (roulement) : en plaçant la souris sur l’espace utilisé par le média (hover), la molette de la souris n’exerce plus l’effet habituel de scroll de la page, mais diminue ou (...) -
MediaSPIP version 0.1 Beta
16 avril 2011, parMediaSPIP 0.1 beta est la première version de MediaSPIP décrétée comme "utilisable".
Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
Pour avoir une installation fonctionnelle, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)
Sur d’autres sites (10117)
-
Anomalie #4194 : Rendre spip_loader compatible php 7.2
13 juillet 2019, par Vincent ROBERTJe confirme le bug que j’ai signalé en double ici #4360
-
Documentation #4098 : Compléter la documentation de #TRI pour générer un lien de tri avec un sens ...
28 septembre 2018, par cedric -Juste pour être sûr, ce que Jean-Luc précise c’est que tu peux générer deux liens de changement de sens de tri avec la syntaxe suivante :
[(#TRI’>’, #CHEMIN_IMAGEtri-asc-16.png|balise_img<:par_tri_croissant :>)] [(#TRI’<’, #CHEMIN_IMAGEtri-desc-16.png|balise_img<:par_tri_decroissant :>)]
comme dans https://zone.spip.org/trac/spip-zone/browser/spip-zone/_plugins_/albums/branches/v2/prive/objets/liste/albums.html#L47
Ce sont 2 liens uniques qu’on met en général en début de bare de tri.
Mais tu peux aussi les générer de manière contextuelle à côte de chaque lien en testant le champ de tri :[(#TRIid_album, <:medias:par_id :>)] [(#TRI|==id_album|oui) [(#TRI’>’, #CHEMIN_IMAGEtri-asc-16.png|balise_img<:par_tri_croissant :>)] [(#TRI’<’, #CHEMIN_IMAGEtri-desc-16.png|balise_img<:par_tri_decroissant :>)] ]
Bon je réponds un petit peu à côté de la question mais quand même donc : on peut générer des liens de sens de tri dynamique, et les mettre en contextuel à côté de chaque lien de tri si c’est ce que tu veux.
C’est vrai que le même lien qui change le sens du tri "comme dans phpMyAdmin" ce n’est pas prévu, mais a moitié aussi parce que je ne suis pas du tout certain que ce soit une bonne pratique accessibilité/usabilité
(ie le même lien dont l’action change selon le contexte, ce n’est pas hyper cognitif)Donc à voir/discuter sous cet aspect peut-être aussi avant de coder quoi que ce soit de plus
-
Evolution #4105 : Constante ou config ?
27 septembre 2018, par RastaPopoulos ♥Ça reste bancal dans le sens où si on a opté pour le côté "déploiement", donc avec un choix fait en PHP, alors le formulaire de config est obsolète, et les gens vont le remplir en croyant que ça va faire quelque chose, alors que non.
Quand au fait même de décider de faire cohabiter les deux (pas forcément constante mais "possibilité de le définir par le code") ce n’est pas tordu, mais bien indispensable si on veut permettre de déployer des choix sans que les admins puissent le changer MAIS que lorsqu’on est pas en mode déploiement, alors là les admins peuvent le changer dans une interface. Ce qui est contre-intuitif, c’est que le form est toujours visible si on a activé un define (ou autre méthode tel le pipeline décrit plus haut).
La solution proposée au début n’est pas la bonne ok, mais l’objet même du ticket pour moi est toujours valable et parfaitement légitime : permettre avec la même API, de manière cohérente et unifiée, que les configs puissent être modifiables par interface OU déployables prioritairement par du code. Et que cela fonctionne au niveau technique ET soit compréhensible dans l’ergonomie (càd champ grisé ou supprimé quand il y a un déploiement par le code).