This morning, I had some free hours to spend on my baby Calendar, and of course I’d spend on what matters the most: the Week view.
I’ve been working on and off in this feature for quite a while, and the last missing piece was proper drag n’ drop support. Fear no more!, and say hello to the new Week view in GNOME Calendar:
This work initially started as a Summer of Code driven by Vamsi, and I just went ahead and finished his work. I tried to be as careful as possible with the new Week view, in order to keep in on part with Month and Year views. That means:
Drag n’ drop
Visualizing and editing events
Properly handle multiday and all day events
Handling too many events
And so it goes. You can create all day and multiday events very quickly:
Of course you can also create timed events with the new week view! Check this out:
And, as always, the traditional sequence of pictures with an awsome rock-ish soundtrack!
Excited? Join #gnome-calendar IRC room at irc.gnome.org, or send me an email to get in touch! Don’t be shy. Calendar is entirely made by amazing contributors dedicating their free time to make the world a slightly better place to live 🙂
A few weeks ago, I was curious to test Gtk+ 4. I know it has some awsome features like OpenGL rendering, major cleanups and other hot stuff, but didn’t have the chance to check it out until then.
I was mostly excited about Vulkan.
I know both of my laptop’s graphic cards support Vulkan. It’s a hybrid Intel Broadwell G2 + NVidia GeForce 920M, although I don’t use the latter because Linux sucks hard with Dual GPU.
Downloaded the latest Gtk+ source, compiled and… nothing. Immediate segmentation fault. Yay! What a great chance to get involved with the next major Gtk+ version development!
So, this happened:
May not be as exciting, since there are no new visible features but… damn, it’s Gtk+ being rendered with Vulkan on Wayland. It’s basically the state-of-the-art of toolkit support right now. Even better, the absolute majority of applications will gain this for free once they port to Gtk+ 4 series.
Getting this into an usable state wasn’t easy, but fortunately, Vulkan has an ~amazing~ thing called “Validation Layers” that simplified the tedious debugging process a whole lot (of course, only after making the validation layerswork with Gtk+). This work even uncovered a driver bug in the Intel driver, which was quickly fixed by Lionel Landwerlin and Jason Ekstrand (thanks folks!)
Of course, there are many improvements that still must be done. A bright future is lying ahead!
GNOME Music is an app that I particularly fell in love. Not because it worked perfectly (it didn’t, at all), nor because it’s fast to the last bit (it isn’t, at all), neither because it’s written in a programming language that I love (i.e. C. And no, it isn’t).
So why the hell did I invest my free time, energy and resources on it? If we look on how it is right now, it makes no sense. So for my dog’s sake, why?
Simply because I want to push GNOME forward.
I saw a very rough, embryonic prototype of what could be a good app. I saw bottlenecks all around, things to fix, tasks to complete. I saw pretty good mockups available. All the ingredients were there, we just needed a little bit of love. Working on challenging apps almost always ends up pushing the entire plataform forward.
To add value to this discussion, and for you guys to understand the future of GNOME Music, we must see the history of this app first.
The Python version was made the official one.
And yet, the pythonic Music was also a quick prototype.
I’m not particularly against quick prototypes. It’s just that the methods to maintain prototypes are radically different from the methods to maintain apps on the long run. Prototypes are meant to be rapidly developed and showcase a certain functionality, right? GNOME Music, however, is part of the extended GNOME plataform – this implies maintaining it for thousands of users during many years.
Features were being added to Music in such a way that the code was getting messier and messier. That sucks.
Back to the Future
All this trip to the past has serious implications on how GNOME Music codebase looks like now. At the GNOME Core Apps Hackfest, we had the chance to sit down, analyse the code and sketch out what we need to do.
Sad news: most of this work consists of fixing and reorganizing what we have now, so in the future we can still read Music’s code and work on it (instead of sitting down and crying every time we have to deal with it, which is basically what used to happen a few months ago).
If I’m to draw how Music’s codebase is organized right now, it’d look like this:
Basically, everything is spread all around the entire codebase. Based on that, here is our current, actionable list of tasks on how to fix that (the names are not final):
All the data will be encapsulated by a new backend class
A new concept of “data sources” will beintroduced
Data source is an interface for code that provides data
Data sources provide:
The current sources will implement this interface
Grilo will be a data source
Tracker will be another data source
Only one singleton class will exist, the Backend class
The Backend manages:
The Playlists object
Album art cache
The UI only communicates with the backend
tl; dr: we’re splitting UI from backend work and adding a layer to abstract data sources. This is how it should look like, after the plan is implemented:
We probably may be overloading the Backend class (suggestions?) but this new architecture will give us some more flexibility to implement new data providers, sync online accounts data, and whatever else we need.
I already started working on this move with the Playlists code. You can check it out here. It needs review and, of course, testing, but the prototype is there to show how we can move on.
During last weekend, I was very happy to attend the Core Apps Hackfest in Berlin. This is effectively the first hackfest I’ve ever been! Thanks Carlos for organizing that, thanks Kinvolk folks for hosting the event, and Collabora for sponsoring the dinner.
This event was a great chance to meet the maintainers in person and talk directly to the designers about doubts we have. Since Carlos already wrote down the list of tasks we worked on, I’m not going to repeat it. So here, I’ll report what I was able to work on.
Together with Marinus and Felipe, we were able to give GNOME Music some thought and decide what to do next. Music, unfortunately, was not written to scale, and this is basically the worst blocker we have to deal with. Pieces of code are not contained, and working on something means breaking something else completely unrelated.
So we sit down and analyzed the code, and came up with a solution for that. Music needs to isolate the backend and the UI, so we can write extensions to music providers in such a way that the UI doesn’t have to be patched too much for that. We decided to work on it before trying to add any new features, because otherwise GNOME Music will be unmaintainable.
For the next release, do expect to see lots of action in Music’s codebase, but few features. Most of the efforts will be focused on refactoring and cleaning the code (even if that means more lines of code in the end).
I’ve been able to work on top of Vamsi’s previous prototype of the week view a little bit, and it’s starting to take shape. Basically, getting a working week view is hard. I’m sure we’ll be able to have something working by the end of December, but I expect some pain and headaches before getting into that state.
Andreas also did a quick live testing of GNOME Calendar, and I could see a few bugs to be fixed.
What a great chance to talk about our beloved shellfish! With Carlos and Alex in there, some issues were figured out and hammered off.
We also dicussed the plans for porting Nautilus to GtkListBox and GtkFlowBox. The biggest problem with those widgets is scalability: they’re not performant on big ammounts of data. Put 10k rows inside a listbox and it slows down to death. Same for flowbox.
Following up on the discussion, the flowbox-based view prototype that Carlos did some time ago was rebased against master. I also worked on rebasing the actionbar prototypes against master. From now on, I’ll focus on trying to get the actionbars into the main codebase.
As Allan detailed in his report, one of the big app-agnostic concepts discussed in this event was the content apps opening and managing files.
This won’t affect GNOME Calendar nor GNOME To Do at the moment, so this discussion wasn’t my focus.
There’s a bunch of things that happened during the hackfest that I’d like to highlight:
The always-awsome Carlos Garnacho fixed some locking issues in Tracker that gave another performance boost to GNOME Music. Now I can really use Music as my everyday player. It takes only 2 or 3 seconds to load my 10.000-songs library.
The new Online Accounts panel patches were reviewed, and started to land on the main codebase. Thanks Rishi!
The GNOME hackers are absolutely awsome. They’re great people, really. I’m proud and honored to be part of this team with such incredible people. I feel like a small kid both in technical and human terms when with them.
I’m very grateful for the GNOME Foundation for sponsoring me. I wouldn’t be able to attend without the sponsorship. And I also thank Endless for allowing me to attend the event. This event was very productive and I have a strong feeling that this really pays back to the community.
I’m super excited to see old friends again. Do you guys remember Carlos was my GSoC mentor? Kudos for him for he organized this event, I want to see you again dude!
Looks like Berlin is a great place to be and, even though this is a focused trip, I want to quickly visit one or two historical places.
This hackfest has an incredibly high potential to be productive. Major core contributors will be there.
I’m positively surprised that my sponsorship request was accepted. Traveling from Brazil is very expensive. I can’t thank the GNOME Foundation enough for that. I really wouldn’t be able to attend without it.
That’s a great oportunity to get some fresh winter German air. There’s a chance I’ll see snow for the first time ever (ya’ know, Brazil has no snow…).
Even if the average German consumes a lot of meat, appearently there is an unbelievably high number of veg(etari)an restaurants nearby.
It’s cold. I lived my entire life in a place where the worst possible weather is worth a jacket. I’m talking about the possibility of snow. Frozen water falling from the damn sky.
I really hope I can be productive. The last few weeks of my life were insane, and my performance is not at its peak. I want every single cent spent by the GNOME Foundation on me to be worth it.
I also hope that Endless benefits from this hackfest’s outcome.
I don’t speak Dutch. I don’t know how receptive they’ll be with a foreigner in their country that doesn’t speak a single word in their language. (Sorry folks.)
I’ll miss my wife!
Of course, even if I have some fears, I’m extremely happy with this hackfest. Thanks again for the GNOME Foundation for sponsoring me, and thanks Endless for allowing me to attend it.
These days, an online magazine I follow wrote about a topic I love researching. I saw some fallacious, poisonous comments and inadvertedly tried to reason with the individual that wrote those things.
Worst thing I could possibly have done.
Of course it didn’t work out. Of course the individual tried to use every single mean she or he had to make me feel bad, to make me think I’m worthless, my arguments are a piece of crap, I’m a stupid teenager trying to reason with a god-like creature that she or he is.
That made me think about how we usually run conversations through internet. Because I work with GNOME, a thick skin naturally grew. I eventually have people yelling me “y u keep breaking stuff?” or “stop making this piece of crap” or even “ur product is bad, u offend me by releasing it” (and yes, they’re all real comments). After some time, this kind of thing becomes just background noise which we have to work with every day. I can only think that other contributors faced the same kind of top-notch treatment.
It makes me wonder how did we get in this rotten state where people try to push you down for nothing but a few seconds of selfish, ego-driven pleasure.
Is there anything I can do, right here and right now, to improve this situation? How can I encourage people to have non-violent conversations? How can I create meaningful dialogs in this chaotic place where people exchange bad words as part of their routines?
Extending this to the GNOME community, what can I do individually to make our community an even warmer place where people can develop themselves and find use for their skills? What can I do to make our community the role model of how a tech community should be?
Some of you might have noticed that GNOME To Do wasn’t released with GNOME 3.22. There is a reason for that: I didn’t have enough time to add new features, or fix any bugs. But that changed, and in fact big things happened.
Lets check it out.
More extensible than ever
You guys know that GNOME To Do has built-in support for plugins, and is highly extensible. You can add new panels, hook up your amazing new feature in various ways, and add new data sources, all without touching the core of the application.
For this release, I ported the ‘Today’ and the ‘Scheduled’ panels to be plugins. That means that you can customize most of your experience withing GNOME To Do now – we ship various plugins and a default experience, and the user selects what fits him/her the best.
I, for one, don’t use the ‘Scheduled’ panel that much, so I simply wiped it out of my way.
It feels very fresh to customize it to perfectly fit my workflow. But that’s all that happened!
Pretty much a requirement to me, subtasks are very important to my workflow. I usually have a big task (usually a project) with many subtasks. That required a huge work to make it happen in GNOME To Do, but the result is quite nice.
You can drag a row over another one, and tada!, you just made the dragged row subtask of the hovered row.
One more step into making GNOME To Do my default task list app.
Dark theme support
Dark theme was basically non-functional on GNOME To Do. Because it heavily relies on custom theming, many CSS code it used to ship only worked well on light themes. Since I don’t override my dark theme override setting, and because no one ever provided a patch, this was never fixed until now.
And to demonstrate how the plugin system is powerful, I added a tiny plugin that switches between dark and light variants, hoping that it can be used as an example plugin for newcomers.
What about the release?
I will release GNOME To Do 3.22 after some more testing – I’m pretty sure there are very specific corner cases that I didn’t managed to reproduce, and someone will fall into it.
Overall, I think this is a nice feature set to land, and I’m quite happy with the current state of GNOME To Do. Of course it can use some improvements, but I’ll focus my development on new plugins, new data sources (Todoist someone? Remember the milk? Here we go!) and exotic features like statistics about your productivity, RPG-like task management, etc.
And, as tradition dictates, a nice new video showing this hotness:
Excited? Join us in creating the best tasklist management application ever. New contributors are always welcomed. Join #gnome-todo room at the GNOME IRC server, test the application, file bugs – every single contribution matters.
Today, we had the first GNOME release party I’ve ever attended. All thanks to the organizing efforts of Jonh Wendell – really, we owe you one!
While this release party was small, I was surprised how well the conversation flowed. I thought that 1 hour would be enough, but I was plain wrong! Stayed for 3 hours, and only leaved because I really had to.
I gave a simple talk about Flatpak, an overview of how it works and why is it important. The feedback was great, really – the attendants appearently were interested in learning about it, and we had a really productive discussion about the topic (after almost 2 hours of sidetalks before I started presenting it).
Jonh cared to bring a GNOME cake and, while I couldn’t it eat, it’s officially the first GNOME cake I’ve ever seen 🙂
I’m happy I found some time to go there (almost 1h30min journey to reach there, but worth every single second). GNOME community in São Paulo, do show up at the next release party, and lets have a great time again. Thanks folks!
Today, the Calendar Team had the first meeting in history. Isaque, Lapo, Renata, Vamsi and I attended it, and the meeting was extremely productive! In fact, we were able to sketch out the general direction that GNOME Calendar will head towards.
What’ll be added
Lets start talking about the additions that Calendar will have.
A New Sidebar
Our design samurai came up with this idea and it was immediately completely welcomed. We want to do a simpler, less cluttered version of this:
The search would behave just like the redesigned GNOME Control Center, and in fact, using a sidebar fixes many issues we currently have with GNOME Calendar, like the search popover and random glitches all around.
The sidebar will be able to be hidden, just like Nautius’ sidebar, so people can have their old Calendar again, behaving just like it used to behave. Stay tuned.
Vamsi has been working on Week View for the past few months. It’s harder than it looks like! Still, he’s working on it and we plan to have the week view by the end of this year. The current state is described by him in his blog post, and here’s how it actually looks like (be aware – IT’S NOT FINISHED):
There’s still a lot of work to do, but we’ll get there eventually 🙂
This is something I myself use frequently, but cannot do with Calendar. Obviously, this will be integrated with GNOME Contacts and will support mailing the attendees.
There are some pain points that we want to change in GNOME Calendar. Thanks to Renata, we have a much clearer picture about the big bottlenecks of Calendar now: adding new calendars and promoting Online Accounts.
Calendar Management Workflow
Based on Renata’s usability testing results, we’ll improve the way people manage calendars by changing its workflow. We’ll use this oportunity to finally implement the initial setup wizard, which we have mockups for quite some time now:
We’ll also turn the calendar management dialog into a wizard-like dialog, and make it more pleasant to work with.
The current Year View is not in the greatest shape possible. The single biggest issue right now is that the months in Year view are different from the months in Calendar (and GNOME Shell):
Fortunately, Isaque has a deep understanding of the Year view, and we’ll turn Year view into a GtkFlowBox-based widget, and share the same month widget (and behavior) all around. Exciting times ahead!
What’ll be removed
Nothing (just a bait for the trolls :P)
Of course, I didn’t cover every single thing discussed in the meeting. Obvious things like recurrences, more reminders, natural language support, jump to date and many other things are not worth the time – they’ll be added. Period.
In general, I’m very happy that this meeting happened. There is a team of contributors growing around Calendar, and this is awsome! Remember that the very first post in this blog was about the Calendar revival? It was a long way from a dead app to a serious core project. A big thanks for this awsome team that is putting time and efforts to make Calendar a better application – without you guys, there wouldn’t be a Calendar!
Excited? Join us in making Calendar great. Get involved, ping us on #gnome-calendar IRC channel, file bugs and/or document it. Every contribution is endlessly appreciated 🙂
is still true! Between backend reworks, Summer of Code projects and spontaneous contributions from awsome random contributors, here are the things that I’m looking forward with GNOME 3.22 release.
Let’s face it: Nautilus is heading towards a bright future and it’s getting in a very good shape – and the community that is growing around it is absolutely gorgeous. Obviously, this is not random; Carlos Soriano is working very hard to make it happen.
This leads not only to fun IRC chats, but tons of contributions. Nautilus’ codebase had its style unified, making it very nice for newcomers to send their patches. After a huge work on Nautilus’ internals, things are in a better shape now and new features are popping up. If you want a more complete list of Nautilus improvements, check Carlos’ blog post about it. Below, the ones that caught my attention.
I didn’t notice how a batch rename tool could simplify one’s life. I personally wasn’t confident this would be useful, but now I can’t live without it! Thanks to Alex Pandelea, we can do things like this now:
Integrated compressed files
Another detail that required lots of improvements on how Nautilus works is the integration of compressed files. This is the kind of thing that gives Nautilus a kudo for the attention to details. Having progress report in the Nautilus progress popover and a built-in way to create compressed files makes me feel like Nautilus cares about me 🙂 Thanks Razvan!
This cycle I focused my efforts at GNOME Calendar. I already wrote about it multiple times, but in short, Calendar received:
In one phrase: I can use Music now. My music collection is considerable (over 9000 individual songs) and GNOME Music simply couldn’t handle it.
Let me be crystal clear: Tracker is fast as hell. GNOME Music was slow to death. Retrieving the list of songs from Tracker takes about 0.25 second, putting the songs into a window and presenting it used to take ~85 seconds. Yes, that’s right, 340x slower.
Fortunately, this is fixed and will be distributed with GNOME Music 3.22 🙂
This new app is surprising me. A lot. I was trying to play Spyro 3 – Year of the dragon for months, without success. Then I tried GNOME Games – without success too. But at least, I could report my issues to Adrien, and what a supportive guy he is! With his help, we were able to debug my failures and, surprise!, he fixed it right after.
And now, after a journey through different PS1 emulators, I can play Spyro again. I could only get it working using Games from Flatpak’s nightly builds – but hey, it works, that’s what matters.
Yay! That’s very promosing! (Although I wonder how much it will impact my productivity :P)
Thanks to the amazing team that leads the development of Gtk+, it keeps receiving a flow of new features, improvements and fixes so fast that it’s hard to track. This round, I was able to add a small feature, the CSS background-blend-mode property support. It definitely isn’t a big thing, but I learned a lot throughout the whole process and I plan to work on more CSS3 features like filters, blend groups and others (and finally give Lapo all the tools he wants to create his crazy themes).
But wait! The greatest thing that Gtk+ will receive in 3.24 (or rather, 4.0 if I understood the new release scheme correctly) is the Gtk+ Scene Graph (aka GSK), thanks to Emmanuele. I’m looking forward using it in a future release!
Not everything is perfect…
Some things didn’t make for this release. I’m particularly sad about GNOME Control Center, which received a new UI but won’t switch to it because not all panels got ready in time. Also, Nautilus’ actionbar wasn’t good enough too – we weren’t satisfied with the end result, and decided it needs more research and love.
Basically, everything I touched outside GNOME Calendar. Sorry, folks!
… but we’ll get there!
So now it’s time to start planning the next cycle – this time, I want to try something new and decide some features based only on community input. I’ll run pools and decide the priorities with that, ask around and really try to get the community involved in the whole process. Stay tuned!
I’d like to thank my employer Endless for allowing me to work on GNOME – it’s awsome that I can do what I love to do as part of my job. Thanks, Endless!