Recherche avancée

Sur d’autres sites (4659)

• Evolution #3528 (Nouveau) : Apporter un Compagnon-Avertissement optionnel pour le premier article ...

  13 août 2015, par YannX DYX

  Très souvent, sur les sites de la communauté, on découvre un vieil article resté en attente de rédaction depuis...
  A la lecture, il est facile de comprendre que ce n’est pas une proposition de nouvel article, mais plutot le premier endroit où un nouvel inscrit a cru pouvoir poster sa demande de renseignements...

  Plutot que de devoir, dans dans tous les sites de la galaxie (et tous les autres sites collaboratifs sur inscription en privé), préparer dans les squelettes du privé et/ou du public, l’apparition d’avertissements diversement compris (et pas reçus au bon moment), j’imagine d’utiliser le mécanisme de Compagnon pour avertir UNE fois l’apprenti-rédacteur (au premier essai de création d’un premier article) que ce n’est pas l’endroit adapté pour une demande de rensiegnements ( et le brancher vers le Forum internes, d’autres liens, etc...)

  Cerise sur le gateau /sous la langue/ du Webmestre, proposer l’affichage d’un article ’_technique_’ (restant seulement au statut "*en redac*") qui bénéficierait des liens de traduction, géré par le seul webmestre.

  Faut-il garder cette option débrayable pas défaut, ou sous forme d’un mini-plugin optionnel ?
  Après tout le Compagnon fait bien partie intégrante de SPIP..
  et comme le texte affiché serait modifiable par tout webmestre,
  il pourrait meme remplacer "*Manuel du Site*"

  YannX

• Evolution #4766 : Passer le menu d’ajouts rapides dans un sous-menu

  4 mai 2021, par RastaPopoulos ♥

  N’importe quoi… on ne les utilise que rarement en tant que dev, si on réfléchit ergo là c’est bien pour les utilisateurices finales, et sur comment les former. Cf les arguments sur la facilité d’apprentissage + la mémorisation de la fonctionnalité + l’accessibilité de la lecture pour savoir ce que ça fait du premier coup d’œil (sans title infobulle que fort peu trouvent et lisent).

  Il est d’ailleurs bien plus plus simple, une fois le gros menu ouvert de viser une ligne entière avec label, qu’un mini bouton riquiqui.

  Quant à la comparaison avec d’autres logiciels : prenons plutôt ceux de la même branche. Et… o gosh, les deux plus utilisés au monde utilisent ce genre de menu !

  Wordpress : un menu "New" avec un picto "+", qui ouvre la liste des choses qu’on peut créer : exactement comme ce qu’on propose
  

  Drupal : un menu "Shortcuts" qui ouvre dessous ce sous-menu (en horizontal et pas vertical pour eux) : là chez eux on peut personnaliser pour chaque utilisateur, ce que j’avais d’ailleurs proposé un jour, ya un remplissage par défaut mais ensuite on peut retirer/ajouter des éléments
  

  Dans un premier temps le truc comme Wordpress suffit, et tout le monde connait et comprend ça (et je pense que ça doit avoir un label du coup, pas juste un "+" !).

• FFMPEG Encoding MP4 for iOS

  3 août 2015, par Ryan K

  I am using the gem streamio-ffmpeg to convert an .mp4 file to another .mp4 file that conforms to iOS standards. I want to put that file in an HTML5 video tag. The video plays well on desktop and Android devices. However, no matter what I do, the iPad Mini 2 that I’m using will not play the video.

  My options hash looks like this :

  options = {video_codec: "libx264", resolution: "480x320", frame_rate: 30, video_bitrate: 500,
  
               x264_vprofile: "baseline", x264_preset: "slow", audio_codec: "aac", audio_bitrate: 56, aspect: 1.333333,
  
               audio_sample_rate: 44100, audio_channels: 1, custom: "-strict -2"}

  When I load the new .mp4 file back into streamio-ffmpeg, this is the object (and metadata) returned :

  #

  I’ve tried just about everything I could find, with different bit rates, codecs, resolutions, etc. What are the correct options to play an .mp4 on an iOS device ?

  BTW, streamio-ffmpeg allows pure ffmpeg options, so I’m ok with that.