Recherche avancée

Sur d’autres sites (8489)

• hw_base_encode : make recon_frames_ref optional

  30 août 2024, par Lynne

  hw_base_encode : make recon_frames_ref optional
  Vulkan supports some stupidly odd hardware, that unfortunately,
  
  most modern GPUs happen to be.
  
  The DPB images for encoders may be required to be preallocated
  
  all at once, and rather than be individual frames, be layers of
  
  a single frame.
  As the hw_base_encode code is written with the thought that either
  
  the driver or the device itself supports sane image allocation,
  
  Vulkan does not leave us with this option.
  So, in the case that the hardware does not support individual
  
  frames to be used as DPBs, make the DBP frames context optional,
  
  and let the subsystem manage this.
  

  • [DH] libavcodec/hw_base_encode.c

• Nomenclature #4626 (Nouveau) : Renommer le menu "Squelettes"

  13 janvier 2021, par RastaPopoulos ♥

  Un petit pavé en début d’année, comme ça peut-être qu’en décembre on aura un début d’idée de quoi faire. :D

  Constat : dans mon expérience, 100% des gens à qui on apprend à utiliser éditorialement SPIP, admins et rédacs donc, n’ont strictement aucune fichue idée de ce que veut dire "Suqelettes", ni quel est le rapport avec le contenu qu’il y a à l’intérieur. Passer du temps à devoir expliquer un terme qui n’aura jamais aucun sens dans leurs activités quotidiennes est une perte de temps pour tout le monde, et 3 mois plus tard illes l’auront oublié vu que ça n’a de rapport avec rien dans leur vie d’admins/rédacs.

  Le fait de faire une référence à l’histoire technique de SPIP, ça ne parle qu’aux devs/intégrateurices : fort peu de gens par rapport à la masse des admins et rédacs qui vont l’utiliser au quotidien.

  Quand on se retire, en tant que devs/ingégrateurices, alors en gros 99% des utilisateurices de l’interface d’admin sont des gens qui ne savent rien du tout de comment c’est techniquement derrière, et même pour beaucoup qui n’ont jamais choisi spécialement ce CMS, et même allons plus loin : assez souvent qui ne savent même pas quel est le CMS utilisé !

  Et point important : ces gens ne devraient avoir aucune obligation de le savoir pour utiliser pourtant comme il faut l’interface.

  Si on leur apprend, parce que nous on aime SPIP et qu’on est enthousiaste à raconter son histoire et comment il marche, c’est super. Mais ça ne doit PAS être une obligation pour comprendre l’interface du premier coup.

  Mon idée (toute relative, c’est pour démarrer quoi) : revenir à des choses simples et couramment utilisées. Il n’y a aucun intérêt spécial à vouloir être original quand on parle quand même du menu principal d’admin.

  Le fait de changer l’intitulé, va forcément changer légèrement le sens, donc quelques plugins qui s’insèrent dedans devront possiblement être déplacés ailleurs. Mais il me semble que ça restera très à la marge, et que la majorité ça correspond toujours. Ça ne doit pas bloquer pour changer. Donc :
  - Mise en page
  - Présentation
  - …

  Dans WP il y a une entrée principale "Apparence", mais ce n’est justement pas notre cas : il faut un terme plus large, qui couvre à la fois les choix graphiques (changer ou configurer un thème, choisir la boite modale…) et les choix de structuration générale, de navigation (Compositions, Menus…).

  Dans ma tête "Mise en page" est pour le moment le terme le plus vaste qui me vient à l’esprit, et qui regroupe plusieurs notions à la fois, pas juste l’apparence graphique. S’il y a mieux tant mieux, du moment que ça regroupe bien ces différentes notions. L’autre jour sur spip-dev Laurent (c-real) disait surcharger avec ce terme aussi pour ses utilisateurices.

  On ne trouvera sûrement jamais le mot parfait à 100%, mais ça sera toujours 1000 fois mieux que "Squelettes" qui vraiment, après 10 ans à devoir l’expliquer en permanence, ne signifie rien pour personne à part nous.

• Evolution #3720 (Nouveau) : Refaire un éditeur à base de CodeMirror + ajouts

  27 février 2016, par RastaPopoulos ♥

  Cahier des charges :
  - Dans l’éditeur lui-même, avoir une vue plus sémantique de ce que l’on tape (WYSIWY Mean !)
  - Pouvoir mettre en plein écran
  - Pouvoir prévisualiser le vrai rendu HTML final (avec les images, modèles, etc)
  - Pouvoir éditer côte à côte avec la prévisu
  - Être pérenne et que le noyau puisse reconnaitre plusieurs syntaxes

  Des gens ont fait ça pour Markdown mais malheureusement QUE pour Markdown. Mais en fait quasiment tout ce qui est important est géré en sous-main par CodeMirror !
  https://simplemde.com/

  Leur éditeur est en fait relativement simple :
  => c’est CodeMirror à 80%
  + ils ajoutent une CSS qui ne change pas juste la couleur pour la syntaxe, mais aussi la taille, pour les titres, gras, italique, etc
  + ils ajoutent une barre de boutons
  + ils ajoutent un système de prévisu (seul ou côte à côte)

  CodeMirror est entre l’autre l’éditeur de code de Chrome et Firefox, et de milles autres choses. Il est à priori (très) pérenne, modulaire, et sait gérer plusieurs syntaxes en les déclarant dans un module JS (un "mode"). En plus de la reconnaissance de syntaxe, il gère déjà plein de plugins comme raccourcis claviers, continuer une liste quand on fait Entrée, etc.

  Pour SPIP je propose cela :
  - faire un mode CodeMirror qui gère uniquement les modèles SPIP, et peut-être les liens (ce qui permettrait de l’utiliser avec d’autres syntaxes que SPIP, notamment dans Markdown)
  - faire un mode CodeMirror pour tous les trucs SPIP autre que modèles
  - faire une CSS qui rend plus sémantique la saisie SPIP (agrandir les intertitres, etc)
  - récupérer la CSS pour la saisie Markdown de SimpleMDE
  - trouver une barre de boutons se basant déjà sur CodeMirror : les boutons ne feraient qu’appeler des comportements CodeMirror
  - re-implémenter notre système de prévisu + de fullscreen et côte à côte dans cette nouvelle barre (= comme SimpleMDE !), sachant que nous la prévisu ça appelle un truc serveur, alors que SimpleMDE il semble que c’est tout en JS client.

  Je pense que le plus gros est de faire les deux modes de syntaxes SPIP pour CodeMirror. Mais une personne a fait un projet très cool qui apparemment fonctionne déjà : une déclaration de grammaire en JSON, beaucoup mieux que la programmation JS des modes de CodeMirror :
  https://github.com/foo123/codemirror-grammar
  Et ça marche !

  Pour le reste, on doit pouvoir s’inspirer de SimpleMDE mais en généralisant :
  1) Ce serait bien d’avoir une barre de bouton pour SPIP et pour Markdown en même temps (en fait avoir deux déclarations, suivant le mode voulu)
  2) Avoir notre prévisu-serveur.

  Comme on le remarque, je propose deux choses qui permettent de garder Markdown sous la main :
  1) séparer la déclaration des modèles (et peut-être des liens)
  2) avoir deux déclarations de boutons

  Cela permettra d’office, avec le même éditeur, la même base commune, de savoir gérer à la fois SPIP et Markdown. Cela me semble important à prendre en compte dès le début.