Recherche avancée

Sur d’autres sites (7072)

• Evolution #4148 (Nouveau) : Augmenter la largeur de l’espace privé

  9 juin 2018, par tcharlss (*´_ゝ｀)

  Il est temps d’augmenter la largeur de l’espace privé :)

  En développant des plugins, je butte souvent face au manque de place et me retrouve à diminuer artificiellement des contenus pour essayer de tout faire rentrer : enlever ou fusionner des colonnes dans les tableaux, réduire des labels dans les colonnes, etc.
  Mais ça ne règle pas tous les problèmes, et c’est vite frustrant de se contorsionner pour essayer de tout faire rentrer.

  Pour ma part je serais d’avis de prendre simplement toute la largeur disponible, width: 100% quoi.
  Les colonnes en pourcentage avec un min-width, le contenu central qui prend la place restante, et voilà.
  Et surtout rien de configurable de ce côté là : pleine largeur, point barre.

  Ça m’amène à la préférence utilisateur « petit écran » / « grand écran ».
  Ces termes sont un peu trompeurs, car ils impactent avant tout le layout.
  Le mode grand écran est certe un peu plus large, mais il ajoute une colonne à droite : au final les colonnes et le contenu central conservent exactement la même largeur que le petit écran, et on a toujours le même problème de place.
  Donc l’idée serait d’avoir la pleine largeur quelque soit le mode, et de trouver des termes plus appropriés : « 2 / 3 colonnes » ou quelque chose du genre.

  Mais à terme ces 2 options devraient disparaître à terme à mon avis, ça ne devrait pas être une préférence utilisateur.
  Certaines pages ont besoin de 2 colonnes, d’autres de 3, mais c’est à décider page par page, pas de façon globale.
  C’est d’ailleurs le cas actuellement sur certaines pages qui ont besoin d’une seule colonne avec la balise #LARGEUR_ECRAN{pleine_largeur}

  Enfin, une précision, je laisse complètement de côté la question du responsive.
  Pour l’instant le privé n’est pas responsive, donc il n’est pas question d’y toucher.
  Là il s’agirait juste de modifier quelques règles CSS qui régissent la largeur générale, avec éventuellement quelques adaptations pour d’autres éléments.

  J’essaierai de joindre un patch à l’occasion.

• Evolution #3990 : Pouvoir utiliser dans SPIP

  20 avril 2021

  Mais du coup ça trimme même si plusieurs \n (genre à la fin). C’est une bonne idée ?
  Faudrait pas trimmer qu’un seul \n maxi ?

  Sinon pas d’avis pour l’autre suggestion de conserver les attributs sur pre.

  Ma remarque est que l’on est censé être dans une syntaxe légére (de SPIP en l’occurrence). Pas écrire du html complet (pre + code). Déjà @

  @ je trouve ça limite limite !
  En ce qui concerne l’écriture de code, quitte à changer l’écriture par défaut, personnellement je préfèrerais basculer sur un équivalement markdown à base de backtick  ```le cadre``` et `le code`.
  
  Ceci dit à part pouvoir passer les attributs de type de code ```php du code ``` on ne peut a priori rien indiquer d’autre au cas par cas. Donc c’est peut être un peu plus limitant.
  

• MPG to MP4 Video Conversion after Azure Media Services Retirement [closed]

  30 juillet 2024, par Yousef

  I'm hosting a C# Blazor Application in Azure App Service and was leveraging Azure Media Services to transcode mpg videos to mp4 in Jobs. However, Azure Media Services was retired last month and the services are going to stop next week so I have to find an alternative.
I have looked at multiple alternatives but couldn't find a simple conversion tool.
In Azure Media Services I was using the following configuration


  


  I can't seem to find the same configuration in the tools I have looked at. I tried Bitmovin but the encoding takes 5 - 10 Minutes (unlike Azure Media Services which takes 2 minutes) and the result of the encoding is a folder with 4 mp4 segments that are not part of the original mpg video.

  


  I tried ffmpeg locally but I can't get it to work in an Azure App Service.

  


  Does anyone have any suggestion of an alternative to Azure Media Service when it comes to Transcoding mpg videos to mp4 in a background task ?