This post is in part a response to an aspect of Nate’s post “Does Wayland really break everything?“, but also my reflection on discussing Wayland protocol additions, a unique pleasure that I have been involved with for the past months¹.

Some facts

Before I start I want to make a few things clear: The Linux desktop will be moving to Wayland² – this is a fact at this point (and has been for a while), sticking to X11 makes no sense for future projects. From reading Wayland protocols and working with it at a much lower level than I ever wanted to, it is also very clear to me that Wayland is an exceptionally well-designed core protocol, and so are the additional extension protocols (xdg-shell & Co.). The modularity of Wayland is great, it gives it incredible flexibility and will for sure turn out to be good for the long-term viability of this project (and also provides a path to correct protocol issues in future, if one is found). In other words: Wayland is an amazing foundation to build on, and a lot of its design decisions make a lot of sense!

The shift towards people seeing “Linux” more as an application developer platform, and taking PipeWire and XDG Portals into account when designing for Wayland is also an amazing development and I love to see this – this holistic approach is something I always wanted!

Furthermore, I think Wayland removes a lot of functionality that shouldn’t exist in a modern compositor – and that’s a good thing too! Some of X11’s features and design decisions had clear drawbacks that we shouldn’t replicate. I highly recommend to read Nate’s blog post, it’s very good and goes into more detail. And due to all of this, I firmly believe that any advancement in the Wayland space must come from within the project.

But!

But! Of course there was a “but” coming – I think while developing Wayland-as-an-ecosystem we are now entrenched into narrow concepts of how a desktop should work. While discussing Wayland protocol additions, a lot of concepts clash, people from different desktops with different design philosophies debate the merits of those over and over again never reaching any conclusion (just as you will never get an answer out of humans whether sushi or pizza is the clearly superior food, or whether CSD or SSD is better). Some people want to use Wayland as a vehicle to force applications to submit to their desktop’s design philosophies, others prefer the smallest and leanest protocol possible, other developers want the most elegant behavior possible. To be clear, I think those are all very valid approaches.

But this also creates problems: By switching to Wayland compositors, we are already forcing a lot of porting work onto toolkit developers and application developers. This is annoying, but just work that has to be done. It becomes frustrating though if Wayland provides toolkits with absolutely no way to reach their goal in any reasonable way. For Nate’s Photoshop analogy: Of course Linux does not break Photoshop, it is Adobe’s responsibility to port it. But what if Linux was missing a crucial syscall that Photoshop needed for proper functionality and Adobe couldn’t port it without that? In that case it becomes much less clear on who is to blame for Photoshop not being available.

A lot of Wayland protocol work is focused on the environment and design, while applications and work to port them often is considered less. I think this happens because the overlap between application developers and developers of the desktop environments is not necessarily large, and the overlap with people willing to engage with Wayland upstream is even smaller. The combination of Windows developers porting apps to Linux and having involvement with toolkits or Wayland is pretty much nonexistent. So they have less of a voice.

A quick detour through the neuroscience research lab

I have been involved with Freedesktop, GNOME and KDE for an incredibly long time now (more than a decade), but my actual job (besides consulting for Purism) is that of a PhD candidate in a neuroscience research lab (working on the morphology of biological neurons and its relation to behavior). I am mostly involved with three research groups in our institute, which is about 35 people. Most of us do all our data analysis on powerful servers which we connect to using RDP (with KDE Plasma as desktop). Since I joined, I have been pushing the envelope a bit to extend Linux usage to data acquisition and regular clients, and to have our data acquisition hardware interface well with it. Linux brings some unique advantages for use in research, besides the obvious one of having every step of your data management platform introspectable with no black boxes left, a goal I value very highly in research (but this would be its own blogpost).

In terms of operating system usage though, most systems are still Windows-based. Windows is what companies develop for, and what people use by default and are familiar with. The choice of operating system is very strongly driven by application availability, and WSL being really good makes this somewhat worse, as it removes the need for people to switch to a real Linux system entirely if there is the occasional software requiring it. Yet, we have a lot more Linux users than before, and use it in many places where it makes sense. I also developed a novel data acquisition software that even runs on Linux-only and uses the abilities of the platform to its fullest extent. All of this resulted in me asking existing software and hardware vendors for Linux support a lot more often. Vendor-customer relationship in science is usually pretty good, and vendors do usually want to help out. Same for open source projects, especially if you offer to do Linux porting work for them… But overall, the ease of use and availability of required applications and their usability rules supreme. Most people are not technically knowledgeable and just want to get their research done in the best way possible, getting the best results with the least amount of friction.

Back to the point

The point of that story is this: GNOME, KDE, RHEL, Debian or Ubuntu: They all do not matter if the necessary applications are not available for them. And as soon as they are, the easiest-to-use solution wins. There are many facets of “easiest”: In many cases this is RHEL due to Red Hat support contracts being available, in many other cases it is Ubuntu due to its mindshare and ease of use. KDE Plasma is also frequently seen, as it is perceived a bit easier to onboard Windows users with it (among other benefits). Ultimately, it comes down to applications and 3rd-party support though.

Here’s a dirty secret: In many cases, porting an application to Linux is not that difficult. The thing that companies (and FLOSS projects too!) struggle with and will calculate the merits of carefully in advance is whether it is worth the support cost as well as continuous QA/testing. Their staff will have to do all of that work, and they could spend that time on other tasks after all.

So if they learn that “porting to Linux” not only means added testing and support, but also means to choose between the legacy X11 display server that allows for 1:1 porting from Windows or the “new” Wayland compositors that do not support the same features they need, they will quickly consider it not worth the effort at all. I have seen this happen.

Of course many apps use a cross-platform toolkit like Qt, which greatly simplifies porting. But this just moves the issue one layer down, as now the toolkit needs to abstract Windows, macOS and Wayland. And Wayland does not contain features to do certain things or does them very differently from e.g. Windows, so toolkits have no way to actually implement the existing functionality in a way that works on all platforms. So in Qt’s documentation you will often find texts like “works everywhere except for on Wayland compositors or mobile”⁴.

Many missing bits or altered behavior are just papercuts, but those add up. And if users will have a worse experience, this will translate to more support work, or people not wanting to use the software on the respective platform.

What’s missing?

Window positioning

SDI applications with multiple windows are very popular in the scientific world. For data acquisition (for example with microscopes) we often have one monitor with control elements and one larger one with the recorded image. There is also other configurations where multiple signal modalities are acquired, and the experimenter aligns windows exactly in the way they want and expects the layout to be stored and to be loaded upon reopening the application. Even in the image from Adlershof Technology Park above you can see this style of UI design, at mega-scale. Being able to pop-out elements as windows from a single-window application to move them around freely is another frequently used paradigm, and immensely useful with these complex apps.

It is important to note that this is not a legacy design, but in many cases an intentional choice – these kinds of apps work incredibly well on larger screens or many screens and are very flexible (you can have any window configuration you want, and switch between them using the (usually) great window management abilities of your desktop).

Of course, these apps will work terribly on tablets and small form factors, but that is not the purpose they were designed for and nobody would use them that way.

I assumed for sure these features would be implemented at some point, but when it became clear that that would not happen, I created the ext-placement protocol which had some good discussion but was ultimately rejected from the xdg namespace. I then tried another solution based on feedback, which turned out not to work for most apps, and now proposed xdg-placement (v2) in an attempt to maybe still get some protocol done that we can agree on, exploring more options before pushing the existing protocol for inclusion into the ext Wayland protocol namespace. Meanwhile though, we can not port any application that needs this feature, while at the same time we are switching desktops and distributions to Wayland by default.

Window position restoration

Similarly, a protocol to save & restore window positions was already proposed in 2018, 6 years ago now, but it has still not been agreed upon, and may not even help multiwindow apps in its current form. The absence of this protocol means that applications can not restore their former window positions, and the user has to move them to their previous place again and again.

Meanwhile, toolkits can not adopt these protocols and applications can not use them and can not be ported to Wayland without introducing papercuts.

Window icons

Similarly, individual windows can not set their own icons, and not-installed applications can not have an icon at all because there is no desktop-entry file to load the icon from and no icon in the theme for them. You would think this is a niche issue, but for applications that create many windows, providing icons for them so the user can find them is fairly important. Of course it’s not the end of the world if every window has the same icon, but it’s one of those papercuts that make the software slightly less user-friendly. Even applications with fewer windows like LibrePCB are affected, so much so that they rather run their app through Xwayland for now.

I decided to address this after I was working on data analysis of image data in a Python virtualenv, where my code and the Python libraries used created lots of windows all with the default yellow “W” icon, making it impossible to distinguish them at a glance. This is xdg-toplevel-icon now, but of course it is an uphill battle where the very premise of needing this is questioned. So applications can not use it yet.

Limited window abilities requiring specialized protocols

Firefox has a picture-in-picture feature, allowing it to pop out media from a mediaplayer as separate floating window so the user can watch the media while doing other things. On X11 this is easily realized, but on Wayland the restrictions posed on windows necessitate a different solution. The xdg-pip protocol was proposed for this specialized usecase, but it is also not merged yet. So this feature does not work as well on Wayland.

Automated GUI testing / accessibility / automation

Automation of GUI tasks is a powerful feature, so is the ability to auto-test GUIs. This is being worked on, with libei and wlheadless-run (and stuff like ydotool exists too), but we’re not fully there yet.

Wayland is frustrating for (some) application authors

As you see, there is valid applications and valid usecases that can not be ported yet to Wayland with the same feature range they enjoyed on X11, Windows or macOS. So, from an application author’s perspective, Wayland does break things quite significantly, because things that worked before can no longer work and Wayland (the whole stack) does not provide any avenue to achieve the same result.

Wayland does “break” screen sharing, global hotkeys, gaming latency (via “no tearing”) etc, however for all of these there are solutions available that application authors can port to. And most developers will gladly do that work, especially since the newer APIs are usually a lot better and more robust. But if you give application authors no path forward except “use Xwayland and be on emulation as second-class citizen forever”, it just results in very frustrated application developers.

For some application developers, switching to a Wayland compositor is like buying a canvas from the Linux shop that forces your brush to only draw triangles. But maybe for your avant-garde art, you need to draw a circle. You can approximate one with triangles, but it will never be as good as the artwork of your friends who got their canvases from the Windows or macOS art supply shop and have more freedom to create their art.

Triangles are proven to be the best shape! If you are drawing circles you are creating bad art!

Wayland, via its protocol limitations, forces a certain way to build application UX – often for the better, but also sometimes to the detriment of users and applications. The protocols are often fairly opinionated, a result of the lessons learned from X11. In any case though, it is the odd one out – Windows and macOS do not pose the same limitations (for better or worse!), and the effort to port to Wayland is orders of magnitude bigger, or sometimes in case of the multiwindow UI paradigm impossible to achieve to the same level of polish. Desktop environments of course have a design philosophy that they want to push, and want applications to integrate as much as possible (same as macOS and Windows!). However, there are many applications out there, and pushing a design via protocol limitations will likely just result in fewer apps.

The porting dilemma

I spent probably way too much time looking into how to get applications cross-platform and running on Linux, often talking to vendors (FLOSS and proprietary) as well. Wayland limitations aren’t the biggest issue by far, but they do start to come come up now, especially in the scientific space with Ubuntu having switched to Wayland by default. For application authors there is often no way to address these issues. Many scientists do not even understand why their Python script that creates some GUIs suddenly behaves weirdly because Qt is now using the Wayland backend on Ubuntu instead of X11. They do not know the difference and also do not want to deal with these details – even though they may be programmers as well, the real goal is not to fiddle with the display server, but to get to a scientific result somehow.

Another issue is portability layers like Wine which need to run Windows applications as-is on Wayland. Apparently Wine’s Wayland driver has some heuristics to make window positioning work (and I am amazed by the work done on this!), but that can only go so far.

A way out?

So, how would we actually solve this? Fundamentally, this excessively long blog post boils down to just one essential question:

Do we want to force applications to submit to a UX paradigm unconditionally, potentially loosing out on application ports or keeping apps on X11 eternally, or do we want to throw them some rope to get as many applications ported over to Wayland, even through we might sacrifice some protocol purity?

I think we really have to answer that to make the discussions on wayland-protocols a lot less grueling. This question can be answered at the wayland-protocols level, but even more so it must be answered by the individual desktops and compositors.

If the answer for your environment turns out to be “Yes, we want the Wayland protocol to be more opinionated and will not make any compromises for application portability”, then your desktop/compositor should just immediately NACK protocols that add something like this and you simply shouldn’t engage in the discussion, as you reject the very premise of the new protocol: That it has any merit to exist and is needed in the first place. In this case contributors to Wayland and application authors also know where you stand, and a lot of debate is skipped. Of course, if application authors want to support your environment, you are basically asking them now to rewrite their UI, which they may or may not do. But at least they know what to expect and how to target your environment.

If the answer turns out to be “We do want some portability”, the next question obviously becomes where the line should be drawn and which changes are acceptable and which aren’t. We can’t blindly copy all X11 behavior, some porting work to Wayland is simply inevitable. Some written rules for that might be nice, but probably more importantly, if you agree fundamentally that there is an issue to be fixed, please engage in the discussions for the respective MRs! We for sure do not want to repeat X11 mistakes, and I am certain that we can implement protocols which provide the required functionality in a way that is a nice compromise in allowing applications a path forward into the Wayland future, while also being as good as possible and improving upon X11. For example, the toplevel-icon proposal is already a lot better than anything X11 ever had. Relaxing ACK requirements for the ext namespace is also a good proposed administrative change, as it allows some compositors to add features they want to support to the shared repository easier, while also not mandating them for others. In my opinion, it would allow for a lot less friction between the two different ideas of how Wayland protocol development should work. Some compositors could move forward and support more protocol extensions, while more restrictive compositors could support less things. Applications can detect supported protocols at launch and change their behavior accordingly (ideally even abstracted by toolkits).

You may now say that a lot of apps are ported, so surely this issue can not be that bad. And yes, what Wayland provides today may be enough for 80-90% of all apps. But what I hope the detour into the research lab has done is convince you that this smaller percentage of apps matters. A lot. And that it may be worthwhile to support them.

To end on a positive note: When it came to porting concrete apps over to Wayland, the only real showstoppers so far⁵ were the missing window-positioning and window-position-restore features. I encountered them when porting my own software, and I got the issue as feedback from colleagues and fellow engineers. In second place was UI testing and automation support, the window-icon issue was mentioned twice, but being a cosmetic issue it likely simply hurts people less and they can ignore it easier.

What this means is that the majority of apps are already fine, and many others are very, very close! A Wayland future for everyone is within our grasp!

I will also bring my two protocol MRs to their conclusion for sure, because as application developers we need clarity on what the platform (either all desktops or even just a few) supports and will or will not support in future. And the only way to get something good done is by contribution and friendly discussion.

Footnotes

1. Apologies for the clickbait-y title – it comes with the subject ︎
2. When I talk about “Wayland” I mean the combined set of display server protocols and accepted protocol extensions, unless otherwise clarified. ︎
3. I would have picked a picture from our lab, but that would have needed permission first ︎
4. Qt has awesome “platform issues” pages, like for macOS and Linux/X11 which help with porting efforts, but Qt doesn’t even list Linux/Wayland as supported platform. There is some information though, like window geometry peculiarities, which aren’t particularly helpful when porting (but still essential to know). ︎
5. Besides issues with Nvidia hardware – CUDA for simulations and machine-learning is pretty much everywhere, so Nvidia cards are common, which causes trouble on Wayland still. It is improving though. ︎

Instagram est l’une des plateformes de médias sociaux les plus populaires, et l’utilisation de réactions comme le like et les emojis dans les messages directs (DM) fait partie intégrante de l’expérience utilisateur. Il est possible de personnaliser ces réactions en modifiant les emojis par défaut pour correspondre à votre style et votre personnalité. Ce guide vous donnera un aperçu complet de la personnalisation des réactions emoji dans les DM Instagram et de l’importance du langage non-verbal dans la communication sur cette plateforme.

TENDANCE

La personnalisation des réactions emoji est une tendance croissante sur Instagram. Les utilisateurs cherchent à exprimer leurs émotions de manière plus authentique et personnelle, et la modification des réactions emoji dans les DM est une façon de le faire. Cette personnalisation permet également de rendre les interactions plus amusantes et engageantes.

Mettre à jour la messagerie Instagram

Avant de pouvoir modifier les réactions emoji dans les DM Instagram, il est important de s’assurer que l’application est à jour. Assurez-vous d’avoir la dernière version de l’application Instagram installée sur votre appareil pour accéder à toutes les fonctionnalités de personnalisation des réactions emoji.

Modifier les réactions Emoji dans les DM Instagram

Pour modifier les réactions emoji dans les DM Instagram, suivez ces étapes simples :

1. Ouvrez l’application Instagram et accédez à vos messages directs.
2. Sélectionnez une conversation et appuyez sur l’icône de réaction en dessous du message.
3. Cliquez sur l’emoji de réaction que vous souhaitez modifier.
4. Une liste d’emojis apparaîtra, choisissez celui que vous préférez pour remplacer l’emoji par défaut.
5. La réaction emoji sera ainsi modifiée et s’affichera désormais avec le nouvel emoji choisi.

Personnalisez vos réactions DM avec des emojis

La personnalisation des réactions DM avec des emojis vous permet d’exprimer vos émotions de manière plus précise et personnelle. Vous pouvez choisir des emojis qui correspondent à votre humeur, à votre style ou à la nature de la conversation, ce qui rend les interactions plus significatives et engageantes.

Comment changer son like en DM sur Instagram ?

Changer votre like en DM sur Instagram est une façon de montrer votre appréciation de manière unique. Au lieu d’utiliser le like par défaut, vous pouvez choisir un emoji qui représente mieux votre réaction aux messages de vos amis et de votre famille. Cela ajoute une touche personnelle à vos interactions sur la plateforme.

Comment modifier les réactions par défaut en DM Insta ?

La modification des réactions par défaut en DM Instagram vous permet de personnaliser votre expérience utilisateur. En choisissant des emojis qui vous parlent vraiment, vous rendez vos interactions plus authentiques et significatives. Cela montre également que vous accordez de l’importance à la manière dont vous communiquez avec les autres sur la plateforme.

Les avantages des emojis dans les DM

Les emojis sont des éléments importants de la communication en ligne, car ils permettent d’exprimer des émotions et des réactions de manière visuelle. L’utilisation d’emojis dans les DM Instagram rend les conversations plus vivantes et permet de transmettre des nuances émotionnelles qui pourraient être difficiles à exprimer avec des mots seuls.

L’importance du langage non-verbal dans la communication Instagram

Sur Instagram, une plateforme axée sur le visuel, le langage non-verbal revêt une importance particulière. Les emojis et les réactions visuelles ajoutent une couche supplémentaire à la communication, en permettant aux utilisateurs de partager leurs sentiments et leurs réactions de manière plus colorée et expressive.

Astuces pour optimiser l’utilisation des emojis réaction en DM Instagram

Voici quelques astuces pour optimiser l’utilisation des emojis réaction en DM Instagram :

• Choisissez des emojis qui correspondent à votre personnalité et à vos émotions réelles.
• Utilisez des emojis pour ajouter de la légèreté et de la convivialité à vos conversations.
• Évitez d’abuser des emojis, utilisez-les de manière équilibrée pour ne pas surcharger vos messages.
• Explorez les différentes options d’emojis disponibles pour trouver ceux qui correspondent le mieux à vos réactions.

Vous aimerez également

Comment avoir les notes sur Instagram

Outre les emojis de réaction, Instagram offre également la possibilité d’ajouter des notes à vos publications. Cela vous permet d’ajouter une touche personnelle à vos photos et vidéos, et de transmettre des messages ou des légendes de manière créative et expressive.

Légende Instagram : conseils et +170 exemples inspirants

Les légendes Instagram complètent vos publications et contribuent à raconter une histoire. Elles peuvent être utilisées pour donner du contexte, partager des émotions, poser des questions ou susciter l’engagement de vos abonnés. Découvrez des conseils et des exemples inspirants pour composer des légendes captivantes.

Tirage au sort Twitter : 5 outils et conseils

Les tirages au sort sur les réseaux sociaux sont un excellent moyen de stimuler l’engagement de votre audience. Découvrez des outils et des conseils pour organiser des tirages au sort sur Twitter de manière efficace et conforme aux règles de la plateforme.

Comment savoir si quelqu’un regarde plusieurs fois ma story Instagram ?

La fonctionnalité des stories Instagram permet aux utilisateurs de partager des moments de leur vie de manière éphémère. Découvrez comment savoir si quelqu’un regarde plusieurs fois votre story, et comment interpréter ces interactions pour mieux comprendre l’engagement de votre audience.

Laisser un commentaire Annuler la réponse

[‘Résumé des points clés’]

FAQ

Comment activer les réactions sur Instagram ?

Pour activer les réactions sur Instagram, ouvrez Instagram, allez dans votre profil, appuyez sur les trois lignes en haut à droite, ensuite allez dans ‘Settings’ > ‘Privacy’ > ‘Story’ et activez l’option ‘Allow Replies and Reactions’.

Comment mettre des cœurs sur Instagram ?

Sur Instagram, vous pouvez ajouter des cœurs en tapant le symbole du cœur dans votre clavier lorsque vous écrivez un commentaire, une légende ou un message direct. Vous pouvez également utiliser les emojis de cœur disponibles dans le clavier de votre téléphone.

Comment faire pour voir le nombre de like sur Instagram ?

Pour voir le nombre de ‘like’ sur Instagram, il suffit d’ouvrir le post qui vous intéresse et de regarder directement sous l’image ou la vidéo à côté du symbole de cœur. Si vous êtes l’auteur du post, vous pouvez également voir le nombre de ‘like’ dans vos notifications.

Comment faire la mise à jour de la messagerie Instagram ?

Ouvrez le Google Play Store ou l’App Store, recherchez Instagram et cliquez sur ‘Mise à jour’. Si aucune option de mise à jour n’est visible, cela signifie que vous disposez déjà de la dernière version.

L’article Guide étape par étape pour modifier le bouton ‘Like’ sur Instagram est apparu en premier sur Astuces Tech.

I love music. My family, friends, colleagues love music. I am in quite a few music-related Facebook groups. A returning question everywhere in the past couple of weeks in various wordings was: what are the five albums you would bring to a desert island? This list is of course changing almost each and every year. And also depends on the number of albums, and if live concert recordings, “best of”, etc. albums can be included. So, this is the 2024 January edition with just studio albums :-)

You are what you listen to. I read several articles with this or similar titles. Well, almost all focused on the lyrics of music, and how that is related to the personality of the listener. This approach has multiple problems with me. The majority of music I listen to does not have any lyrics. I prefer instrumental music. And even if a music has a lyrics, I do not care. I can turn of interpreting English almost completely, and even my native Hungarian to a degree. To me the human voice is just yet another instrument. Probably the only exception is The War of the Worlds, but that’s another story.

The first album on my list comes from Vangelis. “Chariots of Fire” was the first CD I ever bought, and it is one of my favorite albums ever since. There were times when I listened to it almost daily. Nowadays I listen to it a few times in a year. I learned only years later that it is a film soundtrack. I also watched the movie. Not bad at all, but its soundtrack is much better :-) After 32 years I still have the CD, and it plays perfectly well.

TIDAL: https://listen.tidal.com/album/103208768

The second album comes from Pink Floyd. Many say that the album “Atom Heart Mother” is the odd one out in the Pink Floyd discography. Probably they are right, but that’s why I love this album. The first song, the “Atom Heart Mother Suite” almost sounds like classical music. Oh, and it’s definitely the odd one out on my list: the only album with lyrics. Not that I have any idea what is it about, I just enjoy the music. The last song begins with a couple of sound effects. Listening to those on a quality pair of headphones or speakers can be scary :-)

If you take a look at my CDs, you will see that the largest collection is from Mike Oldfield. The various Tubular Bells albums are among my favorites. Of course I like the original version the most. But not the original recording. “Tubular Bells 2003” is a rerecording of the original version, and sounds much better than the original recording. It was not always this way. For many years the original recording was so much in my ears that I could hear all the little changes. It took some time before I could really enjoy the added quality of the new recording.

TIDAL: https://listen.tidal.com/album/2115739

The most recent album on my list comes from Japan. “Spectrum” by Hiromi is a solo piano jazz album. Most songs are her originals, and show off her virtuosity on the keyboard. The only exception is the song “Rhapsody in various shades of blue”. I hope you can guess from the title where the main motives of this song are coming from :-)

TIDAL: https://listen.tidal.com/album/119047902

Last but not least, an album from Hungary. To quote myself from a month ago: “One of my favorite albums is Vedres Csaba és a Kairosz kvartett – Áldott Idő / Blessed Time. It was made by Hungarian pianist Csaba Vedres, who worked together with a string quartet. Their music taught me that string quartets playing alone, with a piano, or with any other instrument can do some fantastic music.”

TIDAL: https://listen.tidal.com/album/27780222

You can also find the CD at the publisher http://perifericrecords.com/hun/catalogue.php?cont=artist&artist_id=1002, together with other albums from Csaba Vedres.

Obviously, this selection is just the tip of the iceberg. With more than five possible albums I would add many others: Philip Glass, King Crimson, ELP, Jean Michel Jarre, Kitaro, Kraftwerk and Rick Wakeman from abroad, or Solaris and After Crying from Hungary. These are just my most listened music, and we did not even mention classical music.

Finally, a question to all the amateur psychologists out there. If the statement “You are what you listen to” is true, what does this selection of music show about me? Am I a scary person or I’m a lovely person? Or both? :-) You can share your opinion with me on LinkedIn, Twitter or Mastodon. My accounts are listed in the top right corner of my blog.

Los desarrolladores de la Comunidad KDE están inmersos en un salto tecnológico que lleva eleverá a cotas superiores la excelencia de los productos KDE. Fruto de este movimiento se ha preparado un lanzamiento colectivo de Plasma 6, KDE Frameworks 6 y KDE Gear 24.02 para el 28 de febrero. A falta de un nombre mejor me he permitido bautizarlo como KDE 6, ya que utilizará tecnología de las librerías Qt 6. Es por ello que hay que preprarar bien las cosas y de esta forma ayer miércoles fue lanzada la primera RC de KDE 6, el megalanzamiento de la Comunidad KDE que empieza a generar mucha expectativa. Así que, para los que disfruten de probar cosas nuevas es el momento de testear esta versión y reportar los errores que se encuentren. ¡No pierdas la oportunidad de contribuir al desarrollo de Plasma!

Lanzada la primera RC de KDE 6, el megalanzamiento de la Comunidad KDE

Hoy 10 de enero ha sido lanzada la primera RC de KDE 6 ( es decir, de Plasma 6, KDE Frameworks 6 y KDE Gear 24.02). Este conjunto de software está previsto que sea lanzado el 28 de febrero de 2024. Esta primera versión liberada no es apta todavía para el usuario que busquen estabilidad, así que abstenerse usuarios finales si no queréis que se os rompa el sistema.

En palabras de sus desarrolladores:

Cada pocos años adaptamos los componentes clave de nuestro software a una nueva versión de Qt, aprovechando la oportunidad para eliminar cosas innecesarias y sacar partido de las funciones actualizadas que nos ofrece la versión más reciente de Qt.

Faltan menos de 50 días para el megarelease de KDE. A finales de febrero de 2024 publicaremos Plasma 6, Frameworks 6 y todo un nuevo conjunto de aplicaciones en una edición especial de KDE Gear de una sola vez.

Si has estado siguiendo las actualizaciones aquí, aquí y aquí, sabrás que estamos superando la fase de pruebas y alcanzando poco a poco la estabilidad. KDE pone hoy a su disposición la primera versión Release Candidate de todo el software que incluiremos en la megalanzamiento.

Al igual que con las versiones Alfa y Beta, se trata de una versión preliminar destinada a desarrolladores y probadores. El software proporcionado se acerca a la estabilidad, pero aún no es seguro al 100% para su uso en un entorno de producción. Te recomendamos que sigas utilizando las versiones estables de Plasma, Frameworks y aplicaciones para tu trabajo diario. Pero si utilizas esto, ten cuidado con los errores e infórmanos de ellos rápidamente, para que podamos solucionarlos.

Más información: KDE

Pruébalo y reporta errores

Todas las tareas dentro del mundo del Software Libre son importantes: desarrollar, traducir, empaquetar, diseñar, promocionar, etc. Pero hay una que se suele pasar por alto y de la que solo nos acordamos cuando las cosas no nos funcionan como debería: buscar errores.

Desde el blog te animo a que tú seas una de las personas responsables del éxito del nuevo lanzamiento de la Comunidad KDE. Para ello debes participar en la tarea de buscar y reportar errores, algo básico para que los desarrolladores los solucionen para que el despegue del escritorio esté bien pulido. Debéis pensar que en muchas ocasiones los errores existen porque no le han aparecido al grupo de desarrolladores ya que no se han dado las circunstancias para que lo hagan.

Para ello debes instalarte esta RC y comunicar los errores que salgan en bugs.kde.org, tal y como expliqué en su día en esta entrada del blog.

La entrada Lanzada la primera RC de KDE 6, el megalanzamiento de la Comunidad KDE se publicó primero en KDE Blog.

Le mode sombre est devenu une fonctionnalité très populaire parmi les utilisateurs d’applications sur smartphone. Snapchat, l’une des applications les plus utilisées pour partager des photos et des vidéos, a récemment ajouté cette fonctionnalité à sa plateforme. Dans cet article, nous allons vous guider sur la manière d’activer le mode sombre de Snapchat sur votre smartphone, que vous utilisiez un iPhone ou un appareil Android.

Comment activer le mode sombre de Snapchat sur iPhone

Si vous êtes un utilisateur d’iPhone et que vous souhaitez activer le mode sombre de Snapchat, vous serez ravi d’apprendre qu’il est très simple de le faire. Tout d’abord, assurez-vous que votre iPhone exécute la version la plus récente d’iOS, car le mode sombre de Snapchat est compatible avec les versions récentes du système d’exploitation. Ensuite, suivez ces étapes simples : 1. Ouvrez l’application Snapchat sur votre iPhone. 2. Appuyez sur votre profil situé dans le coin supérieur gauche de l’écran. 3. Appuyez sur l’icône d’engrenage pour accéder aux paramètres. 4. Faites défiler vers le bas et appuyez sur l’option « Apparence ». 5. Sélectionnez « Sombre » dans le menu déroulant pour activer le mode sombre de Snapchat.

Comment mettre le mode sombre de Snapchat sur Android

Si vous utilisez un téléphone Android et que vous êtes désireux d’activer le mode sombre de Snapchat, vous serez heureux de savoir que c’est également un processus simple. Voici comment vous pouvez le faire sur un appareil Android : 1. Lancez l’application Snapchat sur votre téléphone. 2. Appuyez sur votre profil dans le coin supérieur gauche de l’écran. 3. Appuyez sur l’icône d’engrenage pour ouvrir les paramètres. 4. Faites défiler vers le bas et appuyez sur « Apparence ». 5. Sélectionnez l’option « Sombre » dans le menu pour activer le mode sombre de Snapchat.

Comment activer le mode sombre de Snapchat sur iOS ?

Lorsque vous utilisez un iPhone, il est important de noter que Snapchat adopte les paramètres de thème sombre paramétrés par l’utilisateur sur l’appareil. Par conséquent, si vous activez le thème sombre de votre appareil, Snapchat adoptera automatiquement ce paramètre. Si vous ne voyez pas l’option pour activer le mode sombre dans les paramètres de Snapchat, assurez-vous que votre iPhone est configuré en mode sombre. Le processus pour activer le mode sombre sur Snapchat doit être réalisé via les paramètres de l’appareil.

Comment activer le mode sombre de Snapchat sur Android ?

Sur les smartphones Android, activer le mode sombre de Snapchat est assez similaire à la procédure sur iPhone. Si votre appareil est déjà configuré en mode sombre, Snapchat adoptera cette configuration automatiquement. Cependant, si vous souhaitez activer spécifiquement le mode sombre de Snapchat sans changer les paramètres de tout votre téléphone, vous pouvez suivre les étapes mentionnées dans la section précédente pour configurer l’option d’apparence de Snapchat.

En conclusion, il est très simple d’activer le mode sombre de Snapchat sur votre appareil, que ce soit un iPhone ou un smartphone Android. En suivant les étapes ci-dessus, vous pourrez profiter de l’esthétique sombre de Snapchat tout en économisant de l’énergie sur votre appareil. Profitez de cette fonctionnalité et partagez l’expérience avec vos amis sur Snapchat!

FAQ

Comment faire pour mettre Snap en noir ?

Pour mettre Snap en noir (mode sombre), vous devez aller dans les paramètres de votre téléphone, puis chercher l’option ‘Affichage et luminosité’ et choisir ‘Sombre’. Snap prendra automatiquement le mode sombre. Notez que cette option n’est pas disponible sur tous les appareils ou versions de l’application.

Comment changer la couleur de SNAP ?

Désolé, il semble qu’il n’y ait actuellement aucune option pour changer la couleur de l’interface utilisateur de Snapchat.

Comment mettre Snap en noir sur Samsung a51 ?

Pour mettre Snap en mode sombre sur Samsung a51, il faut se rendre dans les paramètres de l’application Snapchat, puis choisir le mode ‘Apparence de l’application’ et enfin sélectionner ‘Mode sombre’. Notez que cette fonctionnalité dépend de la mise à jour de l’application.

Comment activer le mode sombre sur Android ?

Pour activer le mode sombre sur Android, allez dans les paramètres de votre téléphone, puis dans ‘Affichage’. Ensuite, faites défiler vers le bas jusqu’à ce que vous voyiez l’option ‘Thème sombre’ ou ‘Mode nuit’ et activez-le.

L’article Mode d’emploi : comment passer votre Snapchat en noir ? est apparu en premier sur Astuces Tech.

Vamos a configurar que el comando cal de Linux que muestra un calendario en la terminal lo haga mostrando colores

Ayer en el blog pudiste leer un artículo sobre el comando cal de Linux que lo que nos hace es mostrarnos un calendario en nuestra terminal.

• https://victorhckinthefreeworld.com/2024/01/09/como-mostrar-en-linux-un-calendario-en-la-terminal/

Hoy vamos a ver cómo hacer que ese calendario tenga un poco de color, mostrando la salida del comando en colores, que facilitan la lectura y ayudan a mostrar mejor la información.

El archivo que contiene la configuración de colores del comando cal se encuentra en /home/<tu_usuario>/.config/terminal-colors.d/cal.scheme Si no tenemos ese archivo en esa ruta, podemos crearlo nosotros mismos.

Y en él tenemos que configurar las distintas partes de cal que podemos colorear y añadir el color deseado. Las palabras clave para colorear son:

• today → para el día actual
• weeknumber → para el número de la semana
• header → para la cabecera del nombre del mes y los días
• workday → para los días que no son fin de semana
• weekend → para los sábados y domingos

En mi caso he configurado con estos colores mi comando cal:

header 33
today 41
workday 36
weekend 35

Intenté configurar el color del número de la semana, pero no me funcionaba, si alguien lo probó y le funcionó que comente por el blog el modo.

Y sobre los colores:

Espero que os sirva de complemento al artículo de ayer. A mí me queda de este modo:

Many Linux distributions provide build services under various names: openSUSE Build Service (OBS), Fedora Copr, and so on. These resources are indispensable for upstream developers, and also for their users. I will demonstrate this through some examples from the syslog-ng project.

Note: this blog is loosely based on a talk idea I had for the FOSDEM Distributions Devroom. There is no deep technical information about syslog-ng in this blog. This is more like a history of syslog-ng packaging, and how the fantastic tools by openSUSE and Fedora made it a lot easier and made me an active part of these communities.

Read more at https://www.syslog-ng.com/community/b/blog/posts/how-build-services-make-life-easier-for-upstream-developers

Debo confesar que estoy intentando huir de los plasmoides de Zayronxyo pero creo que es de recibo darle más promocion ya que su trabajo para dotar de más funcionalidades a nuestro escritorio o barra de tareas es asombroso. Así que hoy toca un plasmoide sencillo, un visor meteorológico minimalista llamado Chaac Weather. Con este ya serán 236 los elementos de esta serie presentados en el blog.

Visor meteorológico mini-minimalista, Minimal Chaac Weather for panel- Plasmoides de KDE (241)

Sigo con estas pequeñas aplicaciones que se conocen como applets, widgets o plasmoides y que dotan de funcionalidades de todo tipo a nuestro entorno de trabajo KDE y que parece que van a sufrir un lavado de cara considerable en Plasma 6.

Como he comentado en otras ocasiones, de plasmoides tenemos de todo tipo funcionales, de configuración, de comportamiento, de decoración o, como no podía ser de otra forma, de información sobre nuestro sistema como puede ser el uso de disco duro, o de memoria RAM, la temperatura o la carga de uso de nuestras CPUs.

En esta caso vuelvo con un plasmoide del prolífico Zayronxyo que está siendo protagonista de esta sección desde hace varias publicaciones. Se trata de Minimal Chaac Weather, un visor meteorológico minimalista del cual ya presentamos a su hermano maypr en el blog pero que en esta versión se adapta mejor a los paneles.

En palabras de su creador:

Applet para el panel que muestra la temperatura meteorológica actual.

Para su creación se ha utilizado el código de Chaac Weather. En caso de problemas, es probable que estén relacionados con el código de dicho proyecto, por lo que los problemas pueden ser reportados en el Github de dicho proyecto.

La información meteorológica proviene de open mateo, te sugiero que tú mismo establezcas las coordenadas del lugar donde vives, el widget intenta establecer tu ubicación utilizando tu dirección IP, sin embargo no hay forma de asegurar que esto funcione

Y como siempre digo, si os gusta el plasmoide podéis «pagarlo» de muchas formas en la nueva página de KDE Store, que estoy seguro que el desarrollador lo agradecer?: puntúale positivamente, hazle un comentario en la página o realiza una donación. Ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day de la Free Software Foundation donde se nos recordaba esta forma tan sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

Más información: KDE Store

¿Qué son los plasmoides?

Para los no iniciados en el blog, quizás la palabra plasmoide le suene un poco rara pero no es mas que el nombre que reciben los widgets para el escritorio Plasma de KDE.

En otras palabras, los plasmoides no son más que pequeñas aplicaciones que puestas sobre el escritorio o sobre una de las barras de tareas del mismo aumentan las funcionalidades del mismo o simplemente lo decoran.

La entrada Visor meteorológico mini-minimalista, Minimal Chaac Weather for panel- Plasmoides de KDE (241) se publicó primero en KDE Blog.

Vamos a echar un vistazo a la utilidad cal de Linux que nos muestra un calendario en nuestra terminal

Al empezar el año, es común hacerse con un nuevo calendario para colgar en nuestras casas. Pero quienes usamos GNU/Linux tenemos el comando cal para mostrar un calendario en nuestra terminal.

El comando cal apareció por primera vez en la versión 6 de AT&T Unix y ahora forma parte del paquete de utilidades de Linux. Vamos a ver algunas de sus opciones.

La opción más sencilla es ejecutar el comando sin ninguna opción, lo que nos mostrará el mes actual resaltando el día del mes en el que nos encontremos:

cal
     enero 2024     
lu ma mi ju vi sá do
 1  2  3  4  5  6  7
 8  9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31     

También podemos ejecutar el comando y pedir que nos muestre un mes en concreto del año actual. Podemos pasarle el mes que queremos bien con un número del 1 al 12 o mediante la abreviatura del nombre. Por ejemplo para noviembre podríamos hacerlo de cualquiera de esta manera:

cal 11
cal nov

Si queremos ver el contexto del mes actual, el anterior y el posterior, podemos ejecutar cal -3 que nos mostrará esos tres meses.

Para hacer que muestre el primer día de la semana en domingo, podemos utilizar la opción cal -s o --sunday en la versión larga de la opción. Si queremos que muestre el lunes como inicio (la opción predeterminada) lo haremos con cal -m o --monday

También podemos hacer que en vez de en horizontal se muestren los meses en vertical mediante cal -v

cal -v                                                           
    enero 2024         
lu  1  8 15 22 29   
ma  2  9 16 23 30   
mi  3 10 17 24 31   
ju  4 11 18 25      
vi  5 12 19 26      
sá  6 13 20 27      
do  7 14 21 28      

Algo que me parece muy útil es la opción de poder hacer que también muestre el número de la semana en el calendario, mediante cal -w

      enero 2024      
   lu ma mi ju vi sá do
 1  1  2  3  4  5  6  7
 2  8  9 10 11 12 13 14
 3 15 16 17 18 19 20 21
 4 22 23 24 25 26 27 28
 5 29 30 31          

También podemos mostrar el calendirio de todo el año añadiendo el año que queremos mostrar. O una fecha en concreto. Por ejemplo, saber qué día era el día de nuestro cumpleaños:

cal 1 12 1975
   diciembre 1975   
lu ma mi ju vi sá do
 1  2  3  4  5  6  7
 8  9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31          

Con la opción cal -j nos mostrará no el día del mes, si no el día del año ordinal del mes. Es decir, si es el día 30, 43, o 321 del año.

cal -j feb                                     
        febrero 2024       
lun mar mié jue vie sáb dom
             32  33  34  35
 36  37  38  39  40  41  42
 43  44  45  46  47  48  49
 50  51  52  53  54  55  56
 57  58  59  60            

Como curiosidad vemos que se utilizan dos sistemas de calendario diferentes, gregoriano y juliano. Estos son sistemas casi idénticos con el gregoriano haciendo un pequeño ajuste en la frecuencia de los años bisiestos; esto facilita una mejor sincronización con eventos solares como los equinoccios.

La reforma del calendario gregoriano se introdujo en 1582, pero su adopción continuó hasta 1923. Por defecto, cal utiliza la fecha de adopción del 3 de septiembre de 1752. A partir de esa fecha se muestra el calendario gregoriano;

Las fechas anteriores utilizan el sistema de calendario juliano. Se eliminaron 11 días en el momento de la adopción para sincronizar el calendario con los eventos solares. Entonces, septiembre de 1752 tiene una mezcla de fechas julianas y gregorianas en las que al 2 le sigue el 14 (del 3 al 13 están ausentes).

Para más información ejecuta el comando man cal y verás estas y algunas opciones más que ofrece el comando cal.

The openSUSE Project will have a workshop on Jan. 16 at 15:30 UTC on meet.opensuse.org/meeting that will focus on this year’s Google Summer of Code application and mentorship efforts.

The openSUSE Project has a long tradition of participating in GSoC and community members that want to participate as a mentor should attend or update their project they want listed on 101.opensuse.org by opening up an issue on openSUSE’s GitHub Mentoring project.

The workshop will follow the openSUSE community meeting to determine the amount of projects can be listed for this year’s application, which is open between Jan. 22 and Feb 6.

The workshop will give mentors and people who would like to get involved with mentoring enough time to describe several project ideas before the administrators submit the GSoC application.

Participants are encouraged to create an outline of some project ideas before the workshop on the event’s etherpad.

Mentors and administrators who participated in previous Google Summer of Code programs will attend the workshop.