Recherche avancée

Sur d’autres sites (6408)

• Nomenclature #3470 : Renommer #LESAUTEURS en #AUTEUR

  12 février 2017

  Je pense qu’il faut éviter de mêler "Paquets" au débat. C’est pas vraiment un champ éditorial et ça reflète juste le fait que dans paquet.xml, la balise s’appelle <auteur></auteur> (et elle peut apparaître plusieurs fois).

  Reste donc #AUTEUR dans FORUMS qui est un champ de la table, et est un texte.
  Et #LESAUTEURS ailleurs pour lister les auteurs de l’objet en cours, avec des liens… et elle appelle le modèle modeles/lesauteurs.html.

  Bien que cela retourne quelque chose en relation avec un auteur ou des autrices, elles n’ont pas le même comportement ni le même code technique.
  Si on met le même nommage #AUTEUR partout, c’est cacher que dans un cas ça appelle un modèle qui peut être surchargé, alors que dans l’autre cas c’est simplement le champ en BDD.
  Ça pourrait amener tout autant de confusion également (ie : « mais pourquoi mon modèle "lesauteurs" n’est pas utilisé lorsque j’utilise #AUTEUR sur les FORUMS ? »)

  Ceci étant dit je n’ai jamais été grand fan du nom de la balise #LESAUTEURS, surtout le fait qu’il n’y a pas de souligné ! (#LES_AUTEURS) mais aussi parce que ça doit être la seule balise qui a un article défini devant, du moins il me semble. On n’écrit pas #LA_PAGINATION par exemple.

  Pour aller au delà, peut être que la balise #MODELE pourrait automatiquement renseigner les champs objet et id_objet depuis la boucle dans laquelle elle se trouve employée. Ainsi, pour le cas d’une boucle article on pourrait directement écrire dedans #MODELE{lesauteurs} ou tout autre nom de modèle, à la place de #LESAUTEURS. Ce qui serait bien plus clair sur l’effet réel de la balise : elle appelle le modèle, simplement.

• Anomalie #3281 (En cours) : remarques sur le nouveau thème graphique de la 3.1

  13 août 2016, par b b

  Ha mais non pardon, je pensais qu’on avait intégré les propositions alors que non... J’ouvre de nouveau, mais il serait bien de s’occuper de ce ticket un jour... (parce que là ça commence à dater ^^).

  Pour tenter d’avancer, quelques remarques à propos des propositions de tcharlss :

  formulaires latéraux (fiche d’un objet) : couleurs neutres (bordures et fond), boutons plus lisibles.

  Perso je n’avais même pas remarqué le problème car j’utilise toujours le gris dans le privé. Ça a failli être la couleur par défaut pour la 3.1, mais Arnaud nous a "gentiment" fait remarquer que le gris n’est une couleur... Du coup, je ne suis pas certain que ta proposition lui fera plaisir, par contre ça le fera certainement réagir :p

  Pour les boutons plus lisibles, je crois bien qu’on a augmenter le contraste de ce côté, ça semble bon de mon côté à ce jour.

  - fiche d’un objet : pas d’ombre portée, remplacée par une simple bordure.

  Perso avec ou sans je m’en cogne un peu, mais je trouve plus en accord avec le reste du thème de ne pas utiliser d’ombre portée. Je crois bien que c’est la seule présente dans tout le privé, elle fait un peu tâche du coup. +1 donc :)

  - marge entre le contenu éditorial d’un objet et les formulaires de date etc.

  Ce point semble aussi réglé maintenant.

  - bandeaux identité et outils : couleur de fond identique.

  J’ai un gros doute sur ce point, en effet, si on utilise la "non couleur" gris (^^) et qu’on applique le gris clair du premier bandeau au second (#f4f4f4), la séparation visuelle entre la zone haute et la zone de contenu est beaucoup moins perceptible.

  D’autres avis ?

• The proper way to limit framerate when recording screen on macOS

  5 juillet 2024, par jsx

  macOS 14.5, FFmpeg 7.0.1. To record the screen, if I use the code from Wiki, that is,

  


  ffmpeg -f avfoundation -i 1 output.mp4


  


  the frame rate seems to be so high that when I press q to stop recording, the following message persists until my MacBook Pro starts to noise by its cooler : "[q] command received. Exiting."

  


  My current solution is to add -r after -i :

  


  ffmpeg -f avfoundation -i 1 -r 24 output.mp4


  


  But I heard that a more correct solution is to replace -r with -framerate and to put it before instead of after -i :

  


  


  ffmpeg -f avfoundation -framerate 24 -i 1 output.mp4


  


  Note that I used -framerate as an input option instead of -r 24 as an output option, so I'm telling avfoundation to record at 24fps instead of recording at the default fps and then forcing FFmpeg to drop or duplicate frames to give you the desired 24.

  


  


  This doesn't work for me currently, and appears to be the same as I don't use -r at all.

  


  And so, what is the proper way to fix the "too high framerate" issue when recording the screen on macOS ? Do we need -r or instead -framerate, and where to put it, before or after -i ?

  


  Just in case, here is the log of ffmpeg -f avfoundation -i 1 output.mp4 -v verbose :

  


  https://github.com/jsx97/test/blob/main/ffmpeg.log