Recherche avancée

Médias (91)

Autres articles (29)

  • Demande de création d’un canal

    12 mars 2010, par

    En fonction de la configuration de la plateforme, l’utilisateur peu avoir à sa disposition deux méthodes différentes de demande de création de canal. La première est au moment de son inscription, la seconde, après son inscription en remplissant un formulaire de demande.
    Les deux manières demandent les mêmes choses fonctionnent à peu près de la même manière, le futur utilisateur doit remplir une série de champ de formulaire permettant tout d’abord aux administrateurs d’avoir des informations quant à (...)

  • Gestion de la ferme

    2 mars 2010, par

    La ferme est gérée dans son ensemble par des "super admins".
    Certains réglages peuvent être fais afin de réguler les besoins des différents canaux.
    Dans un premier temps il utilise le plugin "Gestion de mutualisation"

  • MediaSPIP Core : La Configuration

    9 novembre 2010, par

    MediaSPIP Core fournit par défaut trois pages différentes de configuration (ces pages utilisent le plugin de configuration CFG pour fonctionner) : une page spécifique à la configuration générale du squelettes ; une page spécifique à la configuration de la page d’accueil du site ; une page spécifique à la configuration des secteurs ;
    Il fournit également une page supplémentaire qui n’apparait que lorsque certains plugins sont activés permettant de contrôler l’affichage et les fonctionnalités spécifiques (...)

Sur d’autres sites (4594)

  • 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).

  • Evolution #3306 : Permettre l’ajout d’instructions au rédacteur pour le guider dans sa saisie

    24 octobre 2014, par RastaPopoulos ♥

    Il faudrait pouvoir modifier chaque label humain ET ajouter (ou modifier lorsque déjà existant) un texte d’explication en-dessous, cela pour chacun des champs de tout formulaire (au moins ceux des objets éditoriaux).

    Quand je dis "il faudrait pouvoir", je ne pense pas spécialement que ce soit à SPIP de fournir une interface pour le faire, etc, mais par contre il faudrait le pouvoir au niveau API, au niveau technique.

    Actuellement tous les formulaires sont "en dur", écrit en HTML directement avec des variables insérés dedans en squelette. C’est peut-être facile à comprendre mais pas du tout modifiable programmatiquement. Par exemple dans Drupal, tout est fait par une API de formulaires, et donc tout formulaire est modifiable, en ayant son contexte, etc, ce qui permet de dire que pour tel objet, dans telle rubrique, on change l’intitulé des champs, par exemple.

    Au hasard, Saisies permet à peut près cela avec son API… Je suis d’accord qu’il peut avoir des défauts, mais je préfère penser qu’on peut réfléchir à l’améliorer, plutôt que de rester sur du HTML en dur, uniquement surchargeable une unique fois en dur aussi.

  • avcodec/h264_mp4toannexb_bsf : process new extradata

    19 mai 2023, par Zhao Zhili
    avcodec/h264_mp4toannexb_bsf : process new extradata

    For fate-h264_mp4toannexb_ticket5927 and
    
fate-h264_mp4toannexb_ticket5927_2, they work by accident
    
previously. The sample file has two 'avc1' entries, and video
    
samples use the second one. It means packets should be decoded with
    
new extradata in side data. Before this patch, only extradata was
    
kept in the output, new extradata has been dropped. The output can
    
be decoded because the two extradata are almost the same, except
    
level indication. This patch fixed the issue, and add another
    
fate test.
    

    Signed-off-by : Zhao Zhili <zhilizhao@tencent.com>
    • [DH] libavcodec/h264_mp4toannexb_bsf.c
    • [DH] tests/fate/h264.mak
    • [DH] tests/ref/fate/h264-bsf-mp4toannexb-new-extradata
    • [DH] tests/ref/fate/h264_mp4toannexb_ticket5927
    • [DH] tests/ref/fate/h264_mp4toannexb_ticket5927_2

Navigation