On January 1st 2023 at 00:30, my Android smartphone died, and it made me realize how dependent on that device I was. I used it for many aspects of my life: to stay organized, to be informed, to be entertained, or to move around.
Luckily, at that time I was working for Purism and I had a Librem 5, that was the perfect opportunity to try it out in real conditions, as the device I depend on. I started by listing all I used my previous smartphone for, and tried to fulfill the same needs with the Librem 5. It didn’t go well. The device has some great upsides and interesting features, for sure, but the Linux smartphone ecosystem was very far from something I can depend on, especially given how much I was asking from my smartphone.
I ordered a new smartphone in mid-February 2023, and being back on Android after 1½ months not using it helped me discover things I wasn’t expecting.
Going back on Android after a forced withdrawal period helped me notice how much I was bombarded with notifications from YouTube, from Twitch, from Discord and more. Every time I need my phone to do something productive, they are there to tempt me, right from the lock screen so even looking at the clock isn’t safe.
These notifications are external unsolicited distractions that are at all time close at hand in my pocket or next to me, if not already in my hands given I need my phone for everything. Even without notifications, these distractions are right there, these apps are just a few centimeters away from the app I need to reach.
When I yield to the temptation, I end up on YouTube and its autoplay, on Twitch and its FOMO and raids, on infinitely scrolling social, or on an endless flow of short videos. The distraction is endless and it can be hard to go back to what I initially needed to do.
When I was using the Librem 5, granted I didn’t have access to these applications on my phone, but I was feeling more at peace, I was able to keep my focus on what I am doing more easily, getting things done was easier as I was less disturbed. Using an Android smartphone is like sailing on the Sea of Entertainment, having to be very careful not to fall for the haunting notifications of the sirens, at the risk of drowning in the depths of the Bay of Infinite Scrolling.
A smartphone is a full package, so as long as I use one for everything, I can’t bring my calendar and to-do list with me without also bringing YouTube and Twitch along. Because they are on the same device and as I need my productivity tools to always be at hand, distractions are always at hand too. I need to find some way to not bring nagging distractions with me when I want to work, or at the very least I need to keep them away from the tools I need to work.
I decided to reduce my dependency on my smartphone, which implies fulfilling some of its use-cases with tools that don’t subject me to unsolicited distractions. The more I have other ways to do what I use my smartphone for, the less I’m likely to fall into its attention traps. Another benefit would be that if one of my tools fails, there’s only one task I can’t perform anymore. If I depend on my smartphone for everything, it’s a single point of failure and I’ll be screwed when it will inevitably fail.
If I can do things without having to bring my smartphone with me, that’d be perfect. My goal isn’t to get rid of my smartphone, but to stop depending on it for everything, as I currently don’t have the choice to not use it. Having a single device that’s just a thin and light slab that fits in a pocket is extremely comfortable, so if I replace it with many other dedicated tools, I need these to be as small, light, simple, sober, comfortable and to the point as possible. They must do one thing and do it well.
Moreover, distractions and stimulations are important as they help you recharge your batteries and to remain focused longer. I don’t want to remove distracting applications from my smartphone as they are welcome on some occasions, I do need to find ways to rest and to have fun without my smartphone. Distractions should be solicited by me, not soliciting me, and they should be either finite or easy for me to drop out to go back to work.
While I disliked the idea of depending on a Google service, I was somewhat satisfied with how I kept track of events and tasks on Google Calendar. I thought about using a planner but I never was super satisfied by them, they mostly bring bad memories from high school, but a few months ago I heard of bullet journaling, and it piqued my curiosity.
I decided to replace Google Calendar with a bullet journal. I took some base ideas from the original bullet journal method and tweaked it to better match how I was planning on Google Calendar to make the transition smoother. In practice, I dedicate half a page to the tasks I need to perform during a given week whenever I find the time for it, then I dedicate half a page for each day of the week for tasks I want to perform on a specific day. I rinse and repeat until I reached a month’s worth (so 4 or 5 weeks) and dedicate two pages for tasks that should be performed after the already written weeks, and I only add a month or two at a time.
I’ve been using this method with an 250 pages A5 hardcover notebook since the end of July 2023, it’s a bit early to judge if it worked but so far this new system isn’t much worse than the previous one. The main downside is that having to carry such a large notebook with me at all time is quite inconvenient, and I end up letting it at home when I’m going out, and even at home I tend to forget about it. If I want such a journal to replace my previous planning method, I need to make it easy to carry around at all time, even when I’m at home. I’m considering switching to an 80 pages pocket-sized journal, because I don’t need to bring a year’s worth of planning around with me, I only need to plan a few weeks ahead, and there probably are better methods to plan further ahead.
Another downside I’ve noticed is that I used to plan with time slots in mind, but now my to-dos are tied to a day. I need finer granularity and flexibility, I need to find some way to easily sort when I will perform a task and for how long, and ideally I should lay the tasks down in a graphical way that will help me get a sense of how the day will go. Without that, my days are just a mishmash of to-dos that I end up not doing at all. The good thing about bullet journals is that at heart, they just are DIY planners. I can let my system evolve as I see fit, and if I end up switching to smaller journals I will be able to make them evolve more quickly as each one should last 2 months and not a year.
Then I did something that may sound pretty straightforward as I got myself a wristwatch, but it actually wasn’t that simple as I never really liked them. Every time I saw one, either they were large, bulky and heavy, or they had an uncomfortable wristband that just made them annoying to wear, or they were littered with useless features bloating the dial, or they had virtually no notation that could make the time readable. If not all of these at once.
All I wanted is a simple, sober, small and light watch that just showed the time and did it well, which is what I ended up finding with Casio’s MQ-24 series which is priced at around 20€–25€. You can find some really sober and well designed models from Swatch too, though while they seem slightly more polished they will cost you around 60€–75€, which is a non-negligible difference.
I bought a Casio MQ-24-7B2L mid-August 2023, I’ve been using it for a week now and it turns out I like it a lot! To my surprise, I actually like wearing wristwatches, I just needed to find the right model.
I use my phone to listen to music as I’m walking, biking, or working. While when listening to music on my phone when I’m walking or biking I can’t be distracted as easily by notificiations, that’s still a reason for me to bring it with me, so I’d rather have a dedicated way to listen to music.
As for the wristwatch, I want a simple, sober, small, light and long lasting device that just plays music and do it well. High end devices are large, bulky, expensive, and full of features I don’t care about, so they aren’t what I’m looking for. Low end devices tend to be pretty simple and straightforward, but they all have a display that takes space, add weight, reduces their battery life and are so low quality that you could just as well not have them. So, I started looking for small music players with no display, rapidly leading me to the iPod Shuffle series and devices inspired by it. Such devices have the added advantage of forcing me to not care about choosing what I’m listening to, letting me focus on what I’m doing.
I think my perfect device to listen to music would be similar in form and function to an iPod Shuffle G4, have a good build quality and UX, use mass storage and microSD cards, offer 20 hours of audio playback, feature VoiceOver, feature Bluetooth, use USB C (though using the 3.5mm jack is fine too), have some good color options, and have no internet connection whatsoever. No device matches all of these, and I could be satisfied with less. I found a few devices offering some of these features, but ultimately I settled for a second hand G4 as their build quality is top notch and you can find some for the price of new similar devices of lesser quality. I may have to replace its battery soonish, but they are fairly affordable and the operation doesn’t look too hard.
I’m not fond of having to use some special software to load music into the iPod, but at least there are several FLOSS options. Rhythmbox and Clementine from Flathub didn’t work, the former didn’t recognize the iPod at all and the latter couldn’t use because it wasn’t built with libgpod. Then I’ve tried this Python script which worked just fine and even supported VoiceOver, but didn’t handle the database very cleanly. Later I tried Rhythmbox from Fedora, and it let me easily handle the music on the device is a clean way, with the downside that it doesn’t support VoiceOver.
I filed the device with puzzle game music, contemplative game music, ambient music, jazz, trip-hop, electronic music… anything goes as long as it’s lyrics-free and calm to help me focus. The first two are great as they are designed specifically with focus in mind.
I ended up liking the iPod a lot. Having only purposefully chosen songs on it, coupled with its shuffle feature and it’s great design and build quality make it the perfect tool to help me focus. The music is always adapted to the situation and never distracts me, I don’t have to bother selecting a song, which means I don’t have to touch the device, a device so light and tiny I tend to forget it’s there at all! I like it so much and they are so cheap nowadays (well, if you know where to search) that I actually ordered a second one I’ll fill with energetic music that helps me focus.
Distractions, as long as they are chosen, are not only welcome but necessary to relieve stress and produce dopamine, which help remaining focused.
I used my smartphone a lot to fidget. It may sound ridiculous, but very regularly I spun my smartphone in my hands, and I juggled with it. It turns out playing with something with my hands helps me stay focused, it’s a need I was fulfilling with my smartphone only because it always was at hand. Now that I understand that, I can accept it’s a need and get myself some fidgets before I break a nearly 400€ device. Ideally, I need something small, silent, that can easily be carried around in a pocket, and that can be used with one hand only. I don’t know much about what exists, but it’s pretty easy to find affordable ones on the second hand market.
I used my smartphone to get the news and to study various topics. I could easily fulfill these use cases with newspapers and books when I’m out, and still get news from my usual online sources when I’m home or when bringing my phone with me is fine.
Looking for highly portable ways to be distracted made me remind of my old Game Boy Micro, and I decided to pick it up ad play with it. I forgot how incredibly tiny that device is, and yet it’s still very comfortable to use! Another advantage of Game Boy Advance games is that they are honnest. They don’t show ads, they don’t use psychological strategies to make you pay… they are are self-contained gaming experiences. And because they are designed for a portable system, they allow short play sessions. On top of that, flash cartridges are fairly affordable and allow to bring a few games along in a single cartridge. I don’t play games on smartphones, I don’t play video games at all actually, but I think I will really enjoy taking a habit of taking my Game Boy Micro with me. 😄
Thanks to the iPod and the watch, I’ve been able to go out a few times without bringing my smartphone with me, yet without feeling like I was missing something important. I still need my smartphone for communication, for navigation, for its camera, for its torchlight, and much more, but while having it at all with me is a risk, it’s still a lower risk than having it in my pocket. I can still carry the smartphone around in my backpack when I know I’ll need it for something or when I don’t mind risking to be distracted. So don’t think I need to replace it further, and if in the end this isn’t enough and I still get disturbed by my phone, I can just add other tools to replace some of its use cases.
Is this new organization method in search for fewer external distractions a fad, or will it stick? Only time will tell, but so far it’s pretty promising. On a more lighthearted note, now every time I need to leave, instead of having to look for a single tool that’s not too far away because I definitely used it recently, I need to look for several tools scattered all around my apartment, including the smartphone itself. 🙃 Replace “standards” with “tools” and this classic xkcd comic will perfectly describe the situation I’m in.
]]>The following is a translation of an interview published in the February 2023 issue of Alternative Libertaire. I conducted this interview with the goal of offering to its readers a glimpse of what the free culture movement is. The magazine doesn’t target free software or free culture enthusiasts, and its printed edition constrains the size of its content. Please excuse the resulting briefness and simplifications.
Thanks to Nina for proofreading the translation.
Making comics, deciding to give up copyright and hoping to make a living from them in capitalist lands, what an idea! Yet that’s what the comic artist and librist activist David Revoy decided to do. Here’s a look at his unusual journey into the commons.
Alternative Libertaire: Hi David, your main work follows the adventures of the young witch Pepper and her cat Carrot, and you distribute your works under free licenses. What led you to make your work part of the commons?
David Revoy: At first, I was afraid of free licenses, I was afraid that one of my characters would be copied, that my style would be imitated, that I would have no control over it.
In the years 2009–2010, I worked for the Blender Foundation, the Creative Commons was mandatory and under their wing, it reassured me. I made concept-arts and it went well, I saw beautiful derivations, fan-arts and I didn’t see any unpleasant derivation, it reassured me a lot. I even saw the beneficial effects on propagation, audience and interest. There was an added value, it became a common good, a sandbox that other creators could use.
When I did my own comic book project, Pepper & Carrot, the commons imposed itslef to me as evident.
A community collaborates in the creation of you universes, how is it integrated into the creative process?
It’s not completely integrated, I’m using a software forge to create my collaborative space which is abused as a forum, and we have an instant messenging tool on the side. I made a special scenario forge, where people can publish their Pepper & Carrot scenarios under a free license, to check if it can inspire me to make an episode. But you can’t improvise yourself a scenarist, and I have a lot of scripts that start out with very good ideas but fail to come up with a ending or a plot-twist. So there’s a lot of fragments of ideas that I sometimes pick up, some published episodes are inspired by things that have been suggested to me.
What really happens in terms of collaboration is feedback. I share my story-board and the community will show me things that could be avoided, like a proofreading before publication. For example, two panels didn’t flow well and we couldn’t understand why the character comes from the right and then from the left, or why there was a bubble that said that at this particular moment. It allows me to anticipate these questions and to know if they are desired or if it is uncontrolled, if something is not understandable.
After that, the collaborative space is mostly around translation, there are now sixty languages and about a hundred people gravitating around the project, around twenty of which are active.
How do you manage to make a living from your art while giving up on the usual models?
Since all my work is under a free license and accessible without any pay wall, to make an economic model around it, there are not 3 000 solutions, there is only donation, voluntary patronage of the readers. Only a small percentage of the readership will contribute to the author’s livelihood by making a donation for the next episode that I publish every two months.
When I made Pepper & Carrot in 2014, asking money like that was really frowned upon, for web-comics it was donations on Paypal and e-shops, one-time donations, but not recurring donations. Now it’s much more commonplace and almost every starting artist has a system for recurring donations, this system has spread a lot.
Since 2016, Pepper & Carrot is published by Glénat in print edition. Did you approach them or did they come to you after the online success of Pepper & Carrot?
Glénat clearly came to me after the online success of the comic, the publishing house was looking for web-comics authors and they contacted me to edit Pepper & Carrot. I was offered the classic contract following their process, with the standard contract from their legal department. They are the ones who have leverage on the author; unless you already make a lot of sales, when you are a very small author, you don’t tend to negotiate too much.
Except I told them that this would not be the concept at all, that there was the free tool, the free culture, and that I had no interest in the exclusivity system. They were convinced by the unusual concept that now serves as an experiment. We just signed the Creative Commons together. It bothered the legal department a bit because it’s not their usual process and they know that a competing publisher like Delcourt could publish Pepper & Carrot, it would be completely legal.
Glénat pays me when I release a new comic, as patronage, and I have no copyright on the books. When I do signings, whether I sell a million copies or zero, I don’t make any money, but I help Glénat to help me in return. Besides, I love signing books and I can’t sign web-comics, there’s a kind of synergy, we have a relationship based on trust.
Last October, you shared your irritation when you discovered the Bulgarian edition removed a lesbian relationship from the story. If the license gives them this right, how do you reconcile the desire to create commons and to preserve your story?
We had a full range of legal resources at our disposal, the Creative Commons doesn’t remove moral right, so if this edition put a red cross on the lesbian kiss panel, it would have been an opinion expressed to say “this is bad” and there I could have expressed my moral right and sued over it, because it is not what I want to express as an author. The fact that it removes the panel from the story doesn’t mean that the author is against it, because it doesn’t take anything away from the story. There’s an omission because the editor didn’t want to be persona non grata in the media for defending an opinion too progressive for his country.
I couldn’t use my moral rights on it, it’s annoying but there was a movement of readers who organized themselves to print the panel and glue it back into their album, it became a sign of militancy to patch the printed book.
You also promote the freely licensed tools you use, like the Krita drawing software. What do you gain by using these instead of proprietary tools like Photoshop?
Mostly freedom. Not the freedom to not pay because I have a support subscription on Krita equal to what Photoshop costs, but I can install it on as many machines as I want, use it in a computer room, and tell everyone “we’re doing a Krita workshop, install it”.
I’ve been helping the Krita project since 2010 by giving feedback, and I had a lot of adjustments made for my needs. Krita has become tailored to my drawing technique, I have all my reflexes catered for, it is the ultimate comfort. Secondly, I’m sure there is no telemetry. I can’t read Krita’s code, but I know that there’s a whole community who does and can assure me that at no moment in time there can be a line of code able to find out which documents I’m using, what tablet, how much time I’m spending on my drawing. It guarantees my privacy and ensures that I don’t have any ad.
If tomorrow Adobe is bought by a billionaire, people who use Photoshop have no recourse. On Krita, there’s the Krita Foundation that develops it, but if they stop, its free license requires that the code has to be published somewhere and accessible. There will certainly be another group, or even myself, who will continue to build Krita and use it. This ensures that I can still benefit from my level and practice of drawing in the years to come, a guarantee that a Photoshp user would never get.
You also participate in the promotion of free software and free culture by illustrating many Framasoft campaigns. What political significance do you see in librism?
I see it as an online sandbox where you can try your hand at collaboration. You can try out a pyramidal structure with a leader, or a horizontal structure with each person being here on their own initiative, wanting to develop the project and to know how it works. I think this sandbox will allow us to develop reflexes of appreciation for certain models that will make us adopt certain policies instead retrospectively.
]]>I don’t really believe in someone who will come up with a ready-made policy. School is not made like that, hobbies in France are not made like that, we always have a master on a podium, and now, all of a sudden, we’re going to be able to really have a space for experimentation of what collaboration is. I’ve already seen in librist festivals, when you have to pack up, how people organize themselves. That’s where free software has a great political force: to train people to collaborate.
Faire des bandes dessinées, décider d’en abandonner le droit d’auteur et espérer en vivre en terres capitalistes, mais quelle idée ! C’est pourtant ce qu’a décidé de faire le bédéiste et militant libriste David Revoy. Retour sur un parcours hors du commun dans les communs.
Alternative libertaire : Salut David, ton œuvre principale narre les aventures de la jeune sorcière Pepper et de son chat Carrot, et tu diffuses tes œuvres sous licences libres. Qu’est-ce qui t’as mené à faire de tes œuvres des communs ?
David Revoy : Au début, les licences libres me faisaient peur, j’avais peur qu’un de mes personnages soit repris, que mon style soit imité, que je n’ai pas de contrôle dessus.
Dans les années 2009–2010, j’ai travaillé pour la Blender Foundation, la Creative Commons était obligatoire et sous son égide, ça me faisait moins peur. J’ai fait des concept-arts et ça s’est bien passé, j’ai vu de belles dérivations, des fan-arts et aucune dérivation déplaisante, ça m’a beaucoup rassuré. J’ai même vu des effets bénéfiques de propagation, d’audience et d’engouement. Il y avait une plus-value, ça devenait un bien commun, un bac à sable que d’autres créateurs et créatrices pouvaient réutiliser.
Quand j’ai fait mon propre projet de bande dessinée, Pepper & Carrot, c’est devenu une évidence du commun.
Une communauté collabore à tes univers, est-elle intégrée au processus créatif ?
Elle n’est pas totalement intégrée, j’utilise une forge logicielle pour faire mon espace collaboratif dont on abuse comme d’un forum, et on a une messagerie instantanée à côté. J’ai fait une forge spéciale scénarios, où les gens peuvent publier leurs scénarios Pepper & Carrot sous une licence libre, pour voir si ça peut m’inspirer pour faire un épisode. Mais on ne s’improvise pas scénariste et j’ai beaucoup de scénarios qui partent sur de très bonnes idées mais qui n’arrivent pas à faire de chutes ou de plot-twists. Ça fait pas mal de bribes d’idées que je vais des fois reprendre, certains épisodes sont signés en s’inspirant de choses qui m’ont été proposées.
Ce qu’il se passe réellement comme collaboration c’est un retour. Je vais montrer mon story-board et la communauté va plutôt me dire les choses qu’on pourrait éviter d’avoir, comme une relecture avant publication. Par exemple deux cases qui s’enchaînaient mal et on ne comprenait pas pourquoi le personnage vient de droite et là vient de gauche, et pourquoi y’a une bulle qui dit ça à ce moment là. Ça me permet d’anticiper ces questions et savoir si elles sont désirées ou si c’est non-contrôlé, si quelque chose ne se comprend pas.
Après l’espace collaboratif va surtout être pour la traduction, y’a maintenant soixante langues et à peu près cent personnes qui gravitent autour du projet, dont une vingtaine d’actifs.
Comment arrives-tu à vivre de ton art en renonçant aux modèles habituels ?
Vu que tout mon travail est sous licence libre et accessible sans barrière de paiement, pour faire un modèle économique autour, y’a pas 3 000 solutions, il ne reste que la donation, le mécénat volontaire des lecteurs et lectrices. Seul un faible pourcentage du lectorat va participer à ce que l’auteur puisse avoir un moyen de survie en faisant une donation pour le prochain épisode que je publie tous les deux mois.
Au moment où j’ai fait Pepper & Carrot en 2014, c’était très mal vu de demander comme ça, pour les web-comics c’était les dons sur Paypal et les e-shops, la donation ponctuelle, mais pas la donation récurrente. Maintenant ça s’est vachement démocratisé et presque tout·e artiste qui se lance a un système de donations récurrentes, ce système s’est beaucoup diffusé.
Depuis 2016, Pepper & Carrot est édité chez Glénat en albums papier. Les as-tu approché·es ou sont-ils venus à toi après le succès en ligne ?
Glénat est clairement venu à moi après le succès en ligne, la maison d’édition était à la recherche d’auteurs et d’autrices web-comics et elle m’a contacté pour éditer Pepper & Carrot. On m’a proposé le contrat classique suivant leur processus, avec leur contrat-type venant de leur département légal. C’est elles et eux qui ont une force à imposer à l’auteur ; à moins qu’on ait déjà beaucoup de ventes, quand on est un tout petit auteur, on n’a pas trop tendance à discuter.
Sauf que moi, je leur ai dit que c’est pas ça du tout le concept, qu’il y avait l’outil libre, la culture libre, l’exclusivité dont je ne voulais pas. Ils ont été convaincus par le concept qui sort de l’ordinaire et sert d’expérimentation. On n’a fait que signer la Creative Commons ensemble. Ça embêtait un peu le département légal parce que c’est pas leur process habituel et ils et elles sont au courant qu’une édition concurrente comme Delcourt peut éditer Pepper & Carrot, c’est complètement légal.
Glénat me reverse quand je sors une nouvelle bande dessinée, en mécénat, et je n’ai pas de droit d’auteur sur les livres. Quand je fais des dédicaces, que j’en vende un million ou zéro, je ne gagne pas d’argent, mais j’aide Glénat à m’aider en retour. En plus j’adore signer les livres et je peux pas signer les web-comics, y’a une espèce de synergie, on a un rapport qui est basé sur la confiance.
En octobre dernier, tu as partagé ton agacement en découvrant que l’édition bulgare supprime une relation lesbienne du récit. Si la licence leur accorde ce droit, comment concilies-tu les volontés de créer des communs et de préserver ton propos ?
On a eu une batterie légale à notre disposition, la Creative Commons ne supprime pas le droit moral, donc si cette édition avait fait une croix rouge sur la case du baiser lesbien, ça aurait été une opinion exprimée de dire « ça, c’est pas bien » et là j’aurais pu exprimer mon droit moral et faire un procès contre ça, parce que ce n’est pas ce que je veux exprimer en tant qu’auteur. Le fait qu’elle supprime la case du récit ne veut pas dire que l’auteur est contre, parce que ça ne retire rien au récit, il y a une omission parce que l’éditeur ne voulait pas ne plus être invité dans les médias parce qu’il défend une opinion trop progressiste pour son pays.
Je n’ai pas pu faire jouer mon droit moral dessus, c’est agaçant mais il y a eu un mouvement de lecteurs et lectrices qui se sont organisé·es pour imprimer la case et la recoller dans leur album, c’est devenu un signe de militance de patcher l’album papier.
Tu promeus également les outils libres que tu utilises, comme le logiciel de dessin Krita. Que gagnes-tu à utiliser ceux-ci plutôt que des outils propriétaires comme Photoshop ?
Principalement la liberté. Pas celle de ne pas payer parce que j’ai une souscription de soutien sur Krita égale à ce que coûte Photoshop, mais je peux l’installer sur autant de machines que je veux, l’utiliser dans une salle informatique et dire à tout le monde « on fait un atelier Krita, installez-le ».
J’ai aidé au projet Krita depuis 2010 à faire du retour et j’ai eu beaucoup d’aménagements pour mes besoins. Krita est devenu sur mesure à ma technique de dessin, j’ai tous mes réflexes, c’est un confort ultime. Ensuite, je suis sûr qu’il y a pas de télémétrie. Je sais pas lire le code de Krita mais je sais qu’il y a tout une communauté qui le lit et qui peut m’assurer qu’à aucun moment, il va y avoir une ligne de code qui va dire quels documents j’utilise, quelle tablette, combien de temps je passe sur mon dessin, ça va me garantir une protection de ma vie privée, pas de publicités.
Si demain Adobe est racheté par un milliardaire, les gens qui utilisent Photoshop n’ont aucun recours. Sur Krita, y’a la Krita Foundation qui le développe, mais si elle arrête, sa licence libre assure que le code doit être publié quelque part et accessible. Il va y avoir certainement un autre groupe, voire moi personnellement, qui va continuer à construire Krita et à l’utiliser. Ça m’assure que je puisse encore bénéficier dans les années à venir de mon niveau et ma pratique de dessin, ce qu’un utilisateur de Photoshop ne peut pas se garantir.
Tu participes également à la promotion des logiciels et de la culture libres en illustrant de nombreuses campagnes de Framasoft. Quelle portée politique vois-tu au librisme ?
J’y vois un bac à sable en ligne où on peut s’essayer à la collaboration. On peut s’essayer à une structure pyramidale avec un chef ou une cheffe, ou à une structure horizontale avec chacun·e qui est là sur l’initiative personnelle, qui va vouloir développer le projet, savoir comment ça marche. Je pense que ce bac à sable va nous permettre de développer des réflexes d’appréciation de certains modèles qui vont nous faire a posteriori adopter plutôt certaines politiques.
]]>Je ne crois pas vraiment à quelqu’un qui va arriver avec une politique déjà toute faite. L’école n’est pas faite comme ça, les hobbies en France ne sont pas faits comme ça, on a toujours un maître sur une estrade, et là tout d’un coup, on va pouvoir avoir vraiment un espace d’expérimentation de ce que c’est qu’une collaboration. J’ai déjà vu dans des festivals de libristes, quand il faut remballer, comment les gens s’organisent. C’est là que le libre a une grande force politique : entraîner les personnes à la collaboration.
I’m on my way back form Berlin Mini GUADEC 2022, and it was delightful! I’ve been able to meet pals, colleagues and comrades, old and new! The location was great, it’s a really cool hackerspace called c-base, decorated like a sci-fi spaceship with a gigantic 40×16px screen made out of old bottles of Club Mate.
While I’ve not been able to watch all the talks I wanted to and while I didn’t always watch attentively, many talks caught my interest.
🌐 — I have particularly been interested by the talks about internet autonomy by Robert McQueen as this is something I’m realy looking forward to since a really long time. After all, why should I give Google — or any cloud provider — my calendar and the many many sensitive information it contains, when what I really want is to have the same calendar on my laptop and phone, all while keeping this private info for myself‽
⚡ — I also enjoyed the power measurement talk by Aditya Manglik. I’d really like to give Usage a new life as it’s a really neat little app, and having some power measurement info there totally makes sense.
✏️ — Allan Day’s talk about best practices for app design gave a great insight of what design languages are and how GNOME grew itself one.
🥵 — I didn’t learn much from Tobias Bernard’s talk about post-collapse computing, but it was nonetheless interesting and moving.
🤝 — I was particularly interested by the AGM this year too… am I… finally becoming an adult? 😳
I can’t wait to be back home to watch the talks I missed, especially the ones about community, accessibility and inclusivisty!
I didn’t do much regular work this week — conferences are quite demanding and you really want to focus on the rare occasions to socialize — yet I still did a few things, like:
Julian and I also looked a bit at making Metronome vendor its crates in a way that doesn’t require internet at build time, so we can finally update it on Flathub to the GNOME 42 runtime… without success sadly.
I also spent time trying recent versions of GNOME apps on the Librem 5 — especially the upcoming version of Nautilus — and compared the upcoming version of Phosh with the exciting mobile prototype of Shell on Jonas’ tablet and Pinephone Pro.
But more importantly, this conference has been a great opportunity to bond again with members of GNOME, including coworkers and friends! It’s easy to undermine how important in-person social interactions are for the health of the whole project.
The Berlin Mini GUADEC is a sattelite experiment of the main event in Guadalajara. I really enjoyed the mixed local and remote experience, and I think distributed conferences are something that should become the norm for GNOME.
I don’t have number, but this distributed experience felt like it was more inclusive as it allowed more persons to attend, and I assume it was cheaper too as the GNOME Foundation doesn’t have to subsidies as many transatlantic flights. But more importantly it allowed me to attend without contributing much to the destruction of life on Earth — including ours. I’m really considering to never ever attend any conference by plane anymore, and I would simply not have attended GUADEC this year because of the transatlantic flight, even though I would have loved to visit Guadalajara.
On a (somewhat) lighter note, I recently got into street stickers — you know, the kind that cover lamp posts in your city — and I have to say: Berlin didn’t disappoint me! Its streets are riddled with really cool looking ones.
BTW. Thibault. My name isn’t Adrieng Plazza.
]]>When we announced the Librem 5, we knew we would have to invest in and build a mobile operating system and applications to run on it — by “mobile” understand “for smartphones”. To avoid reinventing the wheel, we decided to base that system on an existing environment. Librem laptops ship with our operating system PureOS, which provides GNOME as its graphical user environment as it is a modern environment and a very active project with which we share many goals, design principles and values.
Touchscreens bring a new set of possibilities and constraints to user interface designs. For many years, GNOME’s main target is laptops, and it acknowledges in its design that they can have touchscreens. All of these factors made GNOME a serious candidate for Purism to turn into a mobile platform, and using it on both the Librem laptops and the Librem 5 brings some very valuable consistency to our broader software ecosystem and user experience.
To feed that system we need mobile applications, but rather than creating mobile duplicates of existing GNOME applications, we decided to take an approach the web has been doing for years: making existing GNOME applications adaptive. Making an application adaptive not only makes it work on smartphones just as well as on laptops, but it allows it to work well on anything in between, e.g. when its window is small or tiled. Adaptive applications also means same app code for multiple device sizes.
Making applications work on smartphones just as well as they do on laptops at the scale of a whole application ecosystem can seem like a daunting task, but Purism’s multi-year effort was helped and simplified a lot with good design and appropriate tools.
We experimented creating mobile-specific and adaptive widgets — the elements composing a graphical interface, like text, images, and buttons. We needed a way to provide these experimental widgets to GTK developers without modifying GTK directly. This led to the creation of a library to include into a GTK application: Libhandy — Handy being the German name for a mobile phone.
Here are a few examples of widgets available in Libhandy.
When the window is narrow, the leaflet turns side-by-side panels into a stack of panels with gesture navigation.
The view switcher relocated itself depending on the available width.
The carousel helps navigating between pages with gestures.
The flap can be used to implement sidebars which will smartly use the available space.
As time went on, we needed to develop new and experimental widgets that aren’t specific to mobile phones and adaptiveness. Actually, designers and application developers from both Purism and GNOME wanted widgets to modernize the platform as a whole — e.g. a preferences window and an avatar widget. As Libhandy already was the widgets library we developed for a very similar purpose, it naturally became a host for said widgets.
As it allowed to easily and quickly develop modern, adaptive and snappy applications, Libhandy quickly gained popularity among the GNOME application developers, both for third party GNOME applications and core GNOME applications such as Settings, Files, Web, and more.
Libhandy got closer to GNOME to the point of becoming its unofficial high-level widgets library, sitting atop GTK. Our work on Libhandy benefited not only Librem device users but GNOME and all its users as a whole.
After many years of development, GTK 4 got released in December 2020. Libhandy was relying on GTK 3, and needed to be ported so applications depending on it could, in turn, be ported to GTK 4 and benefit from all its novelties.
Concurrently, a will grew in the GNOME community to have an official widgets library that would implement its human interface guidelines and that would be developed in close relationship with the GNOME design team, which is exactly the role Libhandy ended up filling over the years.
For these reasons, it was decided to change the role of the GTK 4 version of our library, making it not a library focused on mobile and adaptive platforms that accommodate GNOME, but a canonical implementation of GNOME’s human interface guidelines and visual language. In turn, GNOME would take adaptiveness from smartphones to desktops into account in its guidelines. To reflect this new role, it was decided to rebrand that library after Adwaita, GNOME’s design language brand already used for its stylesheet and icons set.
We are currently investing in and working on Libadwaita and have recently released its first alpha version. Its first stable version is planned to be released in September 2021 alongside GNOME 41, as it follows GNOME’s development schedule like all other core GNOME projects.
GTK 4 will allow us to make Libadwaita go way further than we ever could in Libhandy. Here are some demos of what we plan to bring to the library, with no estimated date for completion.
We want a modern and adaptive tabs overview for AdwTabView, it could be used for web browsers, terminal emulators… any application using modern tabs.
We would like to offer some degree of style customization to applications, beyond letting them load custom CSS files. With Libadwaita now hosting the Adwaita stylesheet and thanks to Alice simplifying it, we could bring some API to customize the stylesheet.
We could also offer some neat stylesheet transition animation.
To build the ethical and secure mobile platform we need, we invested heavily transforming and expanding over GNOME in many ways that benefit all its users. While what we have done has been immense, we still have many plans to continue to improve the whole ecosystem for smartphone and laptop users alike: it’s all just the start!
]]>For the past 20 years, GNOME has had human interface guidelines — HIG for short — that are followed by applications targeting the platform.
Implementing the HIG is a lot of manual work for application developers. This led to lots of verbose copypasted UI code, full of slight interpretation variations and errors, making applications hard to maintain and full of visual and behaviorial inconsistencies. The fact these guidelines are not set in stone and evolve every so often made these inconsistencies explode.
Following these guidelines can be streamlined via a library offering tailored widgets and styles. This role has been filled by GTK because of its strong bonds with the GNOME project: Adwaita is both GNOME’s visual language and GTK’s default theme. This is somewhat problematic though, as GTK serves multiple audiences and platforms, and this favores GNOME over them.
This also leads to life cycle mismatches, as GTK machinery must be extremely stable and can’t evolve at a rapid pace, while the GNOME guidelines and Adwaita evolve in comparison much faster, and can benefit from a library that can keep up with the latest designs
The need to give GNOME a faster moving library quickly grew in the community, and many widget libraries filled the gap: libdazzle, libegg, libgd, or libhandy to name a few. This improved the situation, but it only worked around the issues instead of solving them. GNOME needs a blessed library implementing its HIG rapidly, developed in collaboration with its design team. Such a library would define the visual language of GNOME by offering the stylesheet and the patterns in a single package.
This would allow GTK to grow independently from GNOME, at a pace fitting its needs. It could narrow its focus on more generic widgetry and on its core machinery, simplifying its theming support in the process to make it more flexible. This would in turn give other users of GTK an even playing field: from GTK’s POV, GNOME, elementary and Inkscape would be no different, and that hypothetical GNOME library would fill the same role as elementary’s Granite.
The introduction of that library should not make GTK less useful on other platforms, or make GTK applications harder to build (or uglier). It should simply be another library you can choose to link against if you want to make your application fit well into GNOME.
To solve both GTK’s need of independence and GNOME’s need to move faster, we are creating the libadwaita project.
Adwaita is the name of GNOME’s visual language and identity, and it is already used by two projects implementing it: the Adwaita GTK stylesheet and the Adwaita icon set. This new libadwaita library intends to extend that concept by being the missing code part of Adwaita. The library will be implemented as a direct GTK 4 continuation and replacement of libhandy, and it will be developed by libhandy’s current developers.
The Adwaita stylesheet will be moved to libadwaita, including its variants such as HighContrast and HighContrastInverse. GTK will keep a copy of that stylesheet renamed Default, that will focus on the needs of vanilla GTK applications. See gtk!3079 and gtk#3582 for more information. We want that to happen early in the development of libadwaita.
As it will implement the GNOME HIG, the library’s developers will work in close collaboration with the GNOME design team. The design team will also review the initial set of widgets and styles inherited from libhandy, ensuring they are aligned with the guidelines they developed and that they will refresh for GNOME 41.
This transition is being developed in close collaboration between the GTK developers, the libhandy developers, and the GNOME design team. It has also been discussed with various other GNOME and elementary developers.
If you are a GNOME application developer, you likely want to port your application from GTK 3 (and libhandy) to GTK 4 and libadwaita in time for GNOME 41. You can find libadwaita on GNOME’s GitLab, and you can reach the developers on the Matrix room at #libadwaita:gnome.org. You can also join the room via IRC at #libadwaita on GIMPnet.
The libadwaita project will follow revisions of the HIG, and releases will follow GNOME’s schedule. Each version of the library will target a specific version of GNOME, the first stable version being released alongside GNOME 41.
The first stable version of the library will be 1.0. We won’t use the GNOME version number as major versions of the Adwaita library will span multiple GNOME releases, the contrary would be unmanageable for application developers. Major versions will be parallel-installable.
The library isn’t quite ready to be used yet, we have to fix some remaining issues, write a migration guide, and release a first alpha version you can safely target. We will then release several alpha versions and matching migration guides, so you can safely update your application as we stabilize libadawaita 1.0 without ever breaking your build.
Starting from now, libhandy’s pace of development will slow down tremendously as we will focus on developing libadwaita. Any improvement made to libhandy must now first be implemented in libadwaita.
We hope the GTK 4 users will enjoy the newly gained independence, and that GNOME application developers will feel empowered!
Thanks to the GTK developers, GNOME design team, and Alice Mikhaylenko for helping me write this article.
]]>This article presents the most newsworthy changes, you can check the full list of fixes and improvements in the changelog.
While HdyLeaflet
is a good candidate to implement panels which are different layers in the hierarchy of the model — e.g. a list of articles in the first panel, and the selected article in the second panel — it is not well suited for sidebars providing extra information on the current view, or for sidebars providing an overview of the current document. In these cases, the sidebar can be seen as an attachment to the view, not an upper or lower layer in the hierarchy.
To help implementing such sidebars, we created HdyFlap
which can have 3 children: a content, a flap, and a separator. Depending on the available size and the properties, the flap child can either be next to the content child or overlay it, and the separator can be put between the two or not. In the context of a sidebar, your view would be the content child, and your sidebar would be the flap child.
HdyFlap
can also be used to implement fullscreen headerbars: putting the headerbar on top of the window’s content when it is floating, and overlaying it when it is fullscreened. To do so, use HdyWindow
to have a unified window area, give it a vertical HdyFlap
, make your headerbar the flap child, and fold the flap when it’s fullscreened.
While GtkNotebook
is serviceable for a small and fixed number of tabs, it was showing its age for applications heavily relying on tabs such as web browsers, file managers and terminal emulators.
We introduce HdyTabBar
and HdyTabView
as a modern tab bar for such applications letting you pin tabs and scroll.
Pages presenting a big icon, a big title, a description, and optionally some more widgets are often used to implement welcome pages, empty state pages, or error pages. Sadly each application was implementing them in their own way, leading to style inconsistencies not only between applications but also within a single application.
To help unifying their look across the whole ecosystem and to reduce the code needed to implement them a bit, we created HdyStatusPage
.
The swiping velocity is now calculated with a scroll history to make swipes more accurate and comfortable.
HdyCarousel
gained the ability to swipe through multiple children at a time, this can be activated via the allow-long-swipes
property.
The area used to detect edge swipes for HdyDeck
and HdyLeaflet
got increased to make these swipes easier to trigger.
The loadable-icon
property has been added to allow setting a GLoadableIcon
as the avatar picture, simplifying setting the icon and deprecating the set_image_load_func()
method in its favor.
The draw_to_pixbuf()
and draw_to_pixbuf_async()
methods were added to allow exporting the avatar as a GdkPixbuf
, which is helpful to create notification bubbles e.g..
The title-lines
and subtitle-lines
properties were added to set the maximum number of lines the title and subtitle can take. Setting them to 0 means the number of lines won’t be limited, contrary to the previous single-line limit.
HdyDeck
and HdyLeaflet
received the prepend()
, insert_child_after()
, and reorder_child_after()
methods to help inserting children anywhere relevant.
HdyKeypad
now allows pasting and erasing text in the entry, and beeps when an invalid character is typed.
We have plans to support GTK 4 for GNOME 41, and that is what we will focus on for the next GNOME development cycle. I’ll write more about these plans in a following article.
]]>As a user you want to know which applications are relevant to install, so PureOS Store will by default only present mobile-ready applications, while still letting you opt-into showing all applications to take full advantage of the Librem 5’s convergeant docked mode. As a user you also want to know which applications are relevant to run at a given time, so Phosh will let you run desktop-only applications only when the phone is docked.
This requires the applications to provide some information on which form-factors they can handle, if you are an application developer and you want your applications to work as expected on the Librem 5, please provide the relevant information as shown below.
To make your application appear in PureOS Store, add the following lines to your AppStream metainfo:
<?xml version="1.0" encoding="UTF-8"?>
<component type="desktop">
…
<custom>
<value key="Purism::form_factor">workstation</value>
<value key="Purism::form_factor">mobile</value>
</custom>
…
</component>
To make your application appear in Phosh, add the following lines to your desktop entry:
[Desktop Entry]
…
# Translators: Do NOT translate or transliterate this text (these are enum types)!
X-Purism-FormFactor=Workstation;Mobile;
…
If you don’t add these, your application will be assumed to only be compatible with the desktop mode.
You may be intrigued by the Purism namespace in these solutions, we came up with these ad-hoc solutions to provide the form-factor compatibility information we need until better fleshed out solutions are ready. You can read more about this issue here:
]]>A few days ago we released the first alpha of Handy 1, known as Handy 0.80.0. It comes with tons of new features, such as:
HdyWindow
and its companion widgets, a free-form unified window that Alice presented in a blog post;HdyDeck
, that you can picture as a swipeable and spatialization-aware stack;HdyViewSwitcherTitle
, a simpler way to implement a view switcher in a titlebar;HdyActionRow
and HdyExpanderRow
;Keep in mind this is an alpha release of a new major version, it breaks compatibility with previous versions, and more API and ABI breaking alphas will be released.
We plan to release betas starting from 0.90.0, following the GNOME 3.38 development schedule, and 1.0.0 alongside GNOME 3.38. This means that if you application follows the GNOME schedule and still targets GTK 3, you can safely start migrating to Handy 1 via that first alpha version.
Handy just moved to GNOME’s GitLab, you will now find it at gitlab.gnome.org/GNOME/libhandy, and find its documentation at gnome.pages.gitlab.gnome.org/libhandy. Remember to update the URLs in your projects!
The latest stable version is 0.0.13, and it can now be found here. You can follow the evolution of the 0.0.* versions on the libhandy-0-0 branch here, but we are clearly focusing on the upcoming 1.0 version.
I am sure you will love these changes! 😀
]]>This week we had the Design Tools Hackfest 2020, virtualized because of COVID-19, where we discussed that recoloring API. We came up with something I think is interesting enough to discuss more widely.
First let’s define the need:
Common patterns in vendor themes are to change the accent color from the default blue to something better matching their brand like orange or green, another is to have a light theme but a dark titlebar as do Ubuntu and Pop!_OS.
Application developers want to convey information via color, e.g. Web uses a light blue titlebar to convey you are browsing in private mode, and King’s Cross uses a red titlebar to convey you are in super user mode and a purple one to convey you are not on the host’s shell (e.g. in a container or in SSH).
Application developers want to inject their branding via color, e.g. Ciano has a cyan titlebar and Tootle has a desaturated blue one. I could easily see GNOME Twitch use a purple titlebar too.
Application developers color the UI for the material meaning they convey, e.g. Notes gives a color to the notes; when viewing a specific one, almost all the window takes the note’s color, I could imagine the whole window take the note’s color.
Users want to set the system’s accent color, to make the device they use feel more like their own; to do so Windows lets its user set an accent color that will be used in the applications as the titlebar color and accent color.
We need to define a set of color variables and what they should be used for, like selected foreground color or unfocused border color, and these color variables should be made public and defined as the coloring API. Adwaita already has a list of color variables which could serve as a base to forge that API.
To add some variety, each of these color variables would come in a specific variant; during the hackfest we defined three variants so far: regular, titlebar and alternate which would correspond to CSS classes you can use to automatically color elements. regular would be the default color used in the whole UI, titlebar would correspond to the titlebar style class that GTK already gives by default to window titlebars, and the alternate style class would let the application developer apply a third style wherever they want in the UI.
Applications would be able to redefine the colors for all their windows via CSS, like this:
@define-color titlebar_bg_color #f00;
For that to work, themes would only be allowed to use these public color variables in CSS. Given SASS hardcodes its variables’ values, its functions’ results, and the selected conditional branches in the compiled CSS, you can’t affect the style by overriding the public color variables in your application.
In order to change the style by redefining public color variables, you have to make the color computation logic appear directly in the generated CSS, which is fortunately doable using some tricks (see the code example below). Same limitations of not being able to use the full power of SASS can pretty easily be mitigated by offering similar color functions in GTK, but color-dependant conditional branching would have to be abandonned.
// Here is how you can call the alpha() GTK CSS color function from SASS.
@function gtkalpha($color, $alpha) {
@return unquote("alpha(#{$color}, #{$alpha})");
}
// Because CSS doesn't have conditional branching, this bit from Adwaita
// would have to be abandonned, unless we create a very specific color
// function in GTK for each and every case.
@if lightness($c)>95% { @return white; }
@else if lightness($c)>90% { @return transparentize(white, 0.2); }
@else if lightness($c)>80% { @return transparentize(white, 0.5); }
@else if lightness($c)>50% { @return transparentize(white, 0.8); }
@else if lightness($c)>40% { @return transparentize(white, 0.9); }
@else { @return transparentize(white, 0.98); }
Application developers too shouldn’t deviate from this API as their source of colors; unless of course there is a very valid reason to opt-out.
This color API would be a contract between the GTK developers, theme developers, and application developers that they all should follow for colors to be tweakable.
The bulk of Adwaita is implemented in a file named _common.scss
, which is then imported by the files implementing its different variants (light and dark).
In it, the label color would be set that way:
label { color: $fg_color; }
$fg_color
is a color hardcoded in Adwaita and then exported as @theme_fg_color
, if we assume it’s pure white, the following CSS would be generated:
label { color: #fff; }
To implement the color API we have two problems: Adwaita should use the overrideable color variabless from the color API in its CSS instead of hardcoded colors, and it should offer the different color variants.
Adwaita implements one of its theme variants that way:
$variant: 'light';
@import 'colors';
@import 'drawing';
@import 'common';
@import 'colors-public';
As you can see, _common.scss
in imported via @import 'common';
, and variables can be set before importing the file and used in it, like $variant: 'light';
.
We could import _common.scss
for each of the variants of the color API, tweaking a few variables for each import:
$variant: 'light';
@import 'colors';
@import 'drawing';
// The default color variant
$color_selector: '&';
$fg_color: unquote('@theme_fg_color');
@import 'common';
// The titlebar color variant
$color_variant: 'titlebar';
$color_selector: '&.#{$color_variant}, .#{$color_variant} &';
$fg_color: unquote('@titlebar_fg_color');
@import 'common';
// The alternate color variant
$color_variant: 'alternate';
$color_selector: '&.#{$color_variant}, .#{$color_variant} &';
$fg_color: unquote('@alternate_fg_color');
@import 'common';
@import 'colors-public';
Then in _common.scss
, every time we use a public color we would do this:
label { #{$api_selector} { color: $fg_color; } }
The following CSS would then be generated:
label { color: @theme_fg_color; }
label.titlebar, .titlebar label { color: @titlebar_fg_color; }
label.alternate, .alternate label { color: @alternate_fg_color; }
By default, Adwaita would use the same color values for all color variants.
Tada~ 🎉️, all labels in a titlebar would have the overrideable titlebar color and all labels marked to use the alternate color would do so.
So far I detailed how such a coloring API could be implemented by themes and taken advantage of by apps, but I didn’t explain how we could support vendor theming or user customization. While I don’t think this should be supported and implemented, and I think this API should only be between the GTK team and application developers, I’ll explain how I think we can extend it to let the vendors and the users set the colors.
GSettings seems like a good candidate to offer that API to vendors and users: GTK could offer to set the color variables from the API via GSetting, that means vendors could override them by a simple GSettings override, and users could override them to set their prefered colors over the default and vendor ones.
GTK allows different sources to provide styling, and each style provider is given a priority: GTK offers the fallback, theme, settings, application, and user priorities, from the lowest to the highest. If we follow these priorities and GTK loads the colors from the settings with the settings priority, it means we offer what I consider the perfect priority order, from the lowest to the highest: