GNOME To Do 3.24 release, and it’s shining

startup notification

GNOME To Do is a personal task manager for GNOME. It uses GNOME technologies and integrates very well with the desktop. And now, it’s finally being released!

The 3.24 version comes with a few nice features and, most importantly, whole load of bugfixes. Let’s get started!

Autostart & notifications

GNOME To Do now (optionally) autostarts once you log in and keeps track of your tasks! This is what I see now when I log into my laptop:

startup notification
Thanks for letting me know, To Do!

To Do also detects when you put your machine to suspend, and if you resume in the next day, another notification is triggered. Isn’t it nice when your task management tool allows you to focus more on actually working on your tasks than in managing them? I certainly love not having to worry about the tasks for the next day 🙂

This behavior, of course, is optional and configurable. There is a new “Run in background” plugin that allows you to fine-tune this behavior:

Editing plugin options
Editing “Run in background” plugin options

Improved panels

A lot of bugfixes landed for Today, Scheduled and Unscheduled panels. The most important one in my opinion is the ability to select which tasklist the new task will be added. Check this out:

selecting the tasklist
Selecting the tasklist in Today panel

These panels also don’t show the date anymore. It’s not very useful to show “Today” in every task, when you’re already in Today panel, right? The same logic applies to the Scheduled panel, where you can see the date already:

scheduled panel
It looks very nice!

Todo.txt integration

Thanks to our awsome new contributor, Rohit Kaushik, we now have Todo.txt integration! This is disabled by default (it still need some polishing) but you can easily test it by running the autogen script like:

$ ./ --enable-todo-txt-plugin

Now you can just enable it in the Extensions dialog:

Captura de tela de 2017-04-24 09-33-32
Enabling the Todo.txt plugin

Select a Todo.txt file (you have to create on manually if you don’t have one):

Selecting a Todo.txt file
Select a Todo.txt file

And you can use it just like a regular tasklist!

Todo.txt + GNOME To Do
It works 🙂

Thanks Rohit!

A few considerings

A few new features were showcased in this blog post, but to me, the topmost important change is the stability of GNOME To Do. I’ve been using it regularly for the past couple of weeks and it’s pretty stable, but I know that bugs are there, just waiting for someone to trigger them.

If you see To Do crashing or behaving oddly, please file a bug at the gnome-todo product in GNOME Bugzilla. And make sure to join #gnome-todo room at GNOME IRC and say hi. With your help, we can make GNOME To Do the best personal task manager out there!

I’m not looking forward 3.24

Not until it’s fixed.

Those who follow my work are used to read my “Looking forward ” posts, and they appear to be quite popular. This cycle, however, I’m not looking forward the next GNOME release.

That’s because I’m disappointed.

Very disappointed.


#1 – GNOME Shell

UPDATE: I was told this is an Arch-specific issue.

UPDATE 2: This is not an Arch-specific issue. This is now fixed in bug 781194, and will be available in the next GNOME stable release.

Let’s start with GNOME Shell, which is the single topmost important piece of software for end users. I was super excited with the new Night Lights mode, because as you may know, I suffer from insomnia (and fixed many bugs when I couldn’t sleep!).

When it landed on Arch Linux’s gnome-unstable repos, I’m pretty sure I was one of the first ones to test it.

But Shell keeps crashing every ~4 minutes. After 5 or 6 crashes, it logs me out. Needless to say, I lost work multiple times. That’s incredibly annoying.

If anyone is experiencing that, please join us in bug 781194 for we’re trying to find out why those crashes are happening. Fortunately, Philip Chimento is super nice and is working day and night to find out what’s going on.

But that’s still disappointing.

#2 – WebKit2GTK+

UPDATE: This was a regression in WebKit2GTK+.

I try to use Epiphany. I really try. But no matter how much I try, it fails me every time.

Looks like I can’t use keyboard to handle my Google Inbox mails. That’s a show-stopper to me.

#3 – Calendar

UPDATE: Thanks Debarshi for explaining this. He states:

There is a reason why crashes reported by ABRT are marked as ‘private’. Like all backtraces, the ones on those bugs often have passwords and private data in them. I have seen a few over the years. Hence those bugs are only accessible to Fedora contributors by default. Which makes sense, because, as you pointed out, they are Fedora bugs, and users already trust the Fedora community to ship secure software.

Why am I disappointed with my own piece of software? Well, I’m not disappointed with Calendar itself, but with the bugs around it.

It all started with bug 778419.

As you might know, I’m very urgent when it comes to crashes on Calendar. Sometimes I stop urgent tasks to fix crashers as quick as possible. Recently, I received many complaints that Calendar was crashing, but I couldn’t reproduce any one of them and worse, the debug logs weren’t helpful.

Here enters bug 778419.

Appearently, there is a issue management thing called FAF in Fedora. Nice. And looks like it catches many bugs. Super nice! But then, why am I disappointed?

Well, it starts out with me not being a Fedora user, nor watching Red Hat’s bug tracker. GNOME is agnostic to distros, and should stay that way. That’s why we have GNOME Bugzilla instance running, right? So people can report GNOME bugs, in… well, GNOME bug tracker.

But that’s ok – I can eventually see FAF and have some downstream feedback. But here is the catch: appearently, some bugs are private. Isn’t is nice when you can’t see the issues of your own app? Even nicer when appearently downstream doesn’t really care to report those issues upstream. This is clearly stated in the bug.

Let me restate this: GNOME is agnostic to distros. I refuse to watch Red Hat’s bug tracker.

#4 – Software

I was super, super excited to try GNOME Software’s Flatpak integration. I never really used Software since it (i) does not behaves super great in Arch, and (ii) isn’t better than Arch’s pacman.

But I thought Flatpak would change this scenario. Flatpak is not great at command line, building a Flatpak repo is still way too hard for humans, and OSTree’s progress reports don’t really report the progress, but throw random numbers for you to figure out what’s going on. But I was hopeful that all we needed was a good UI for it.

Do I have to say how disappointed I was to see Software falling apart when installing and updating Flatpaks?

I won’t waste any paragraph describing how it fails. You just need to have Software, Flatpak and a repository to see the action.

At Last

Some of you might think this is a rage post. It is not. I use GNOME every day, and I am fixing GNOME every single day of the past 3 or 4 years. I wouldn’t use it if I didn’t love it. It’s indeed the best desktop environment for Linux to me. And I of course will fix every single issue I described here.

But I think we can do better. Much better. Of course, everyone can come here and say “well, you can fix that by yourself until I don’t”, but is that a good approach to this situation? We’re failing in maintaining and improving the platform, and that’s a serious, collective issue. We have unbelievably good hackers around, it’s not the lack of skilled people, nor resources, that is cracking us.

What can we do to improve?

I’ll leave this question broad and open like that, and I’d like to hear the opinions of the community. Let’s just try to keep the level of the respect acceptable.

By the way: Shell crashed 11 times, and I was kicked out of my session twice, until I could finish this article

GNOME Music: the road to 3.24

(Disclaimer: this is a guest post from Marinus Schraal, the maintainer of Music)

GNOME Music has just been released, a good time to reflect on what has happened last development cycle.

A goal for Music is to make it an exemplary application of GNOME/GTK+ Python programming and make it an entry-level project for new contributors. However the codebase was a mixture of coding styles and oversized multi-functional classes. Python is a powerful and easily accessible language, but the downside is that it can quickly get out of control if not some constraints are set on how to use it. So we started a rework to split up some of the bigger source files and enforce PEP-8 (code-style) & PEP-257 (docstrings) on new commits and bring existing code in line with it. We are not quite there yet on the clean-up front, but we have come a long way and going forward it is gonna get better.

This effort also entailed that we put off some feature additions and mainly worked on core issues, like grouping albums correctly. Album grouping has always been a sore point for Music and is usually mainly visible with for example ‘Greatest Hits’ albums being all presented as one album or with the wrong artist. Over time Music has had a lot of bug reports of this and similar issues. The underlying reason is that Music is purely metadata driven and is actually completely dependant on the data that is provided by Grilo and in turn (for local media) Tracker. If this metadata is incomplete or incorrect then Music cannot correctly display it.

So that is why we worked with the Tracker folks – in particular Garnacho – to get some indexing issues fixed and I think we did come a long way. However, to get the right experience you need to re-index your music files with a recent enough Tracker (at least 1.12) to get the metadata correctly indexed. Music can’t (understandably) force re-indexing and it’s only available via the following command line command.

$ tracker index -m audio/mpeg -m audio/flac -m audio/x-vorbis+ogg -m audio/mp4

It re-indexes the most common audio mime-types. Of course, this is based on the assumption that your music is tagged correctly to begin with. Note that tagging is prone to be taste/ripper/format specific and is often incomplete, we had to make some informed decisions here what we consider ‘correct’.

We also reworked the album art code, which in most places now supports HiDPI art. Because of changes in Tracker security policies we were forced to add some code to do local art retrieval in Music itself. It is ultimately not what we want, but it has to do for now. This also caused some stability issues in the 3.24.0 release, which should hopefully be resolved in the current release.

Part of the clean-up meant we wanted to get rid of libgd as much as possible this cycle as most of it is superseded by regular GTK+ widgets. We made some good progress, replacing (and speeding up) the albums view significantly, reworked the single album view and notifications. Kudos to Feaneron who did some heavy lifting here. There’s still more work left here coming cycle(s).

Despite the focus on making Music future ready code-wise, there were many user-visible improvements all over the place. To list a few:

  • smooth progress bar movement
  • smoother seeking
  • an empty state for the playlist dialog
  • new playlist entry for the playlist dialog
  • a shortcuts window
  • addition of composer information to the album view
  • the ability to search by composer
  • album disc separation
Captura de tela de 2017-04-12 12-27-07
Keyboard Shortcuts for GNOME Music

The most satisfying about this is that most of these contributions were made by a number of different new contributors, so a big thanks to everyone who made Music better this cycle.

Onward to 3.26

The rewrite has brought to the surface some rough edges in Music. There are some things that used to work and might not at this point, maybe because they were held together with band-aids and actually need more work to get right. There are things we want (remote sources/live updating/proper indication of played tracks/etcetera), but we can’t do yet. The core infrastructure is lacking.

The one big thing we want this cycle -besides finishing what we started last cycle- is doing the rework Feaneron blogged about earlier: having a single core model that drives the different views. This would solve a plethora of currently hard to tackle issues, some of which I just mentioned. From there we would be able to land bigger new features, like the GSoC work done on tagging & webdav sources. The Core Apps hackfest was a big part of crystallizing what needs to be done here.

Of course we cannot do this without help and we hope to see you soon on IRC (#gnome-music), on Bugzilla or check the Wiki for more info.

A final note on Tracker

In the past we used to ask people to hard reset their Tracker database if something went wrong or seemed out of whack, meaning it would be fully cleared and rebuilt. A lot of effort has gone into Tracker to make it more robust and stable. At this point we strongly suggest to not do a hard reset lightly; Music is using the tracker database for keeping track of things like playlists, favourites and played count. This might extend even further in the future.

If you have a problem with Tracker, don’t wipe it and the exclusive data that might live in it’s database: file a bug, seek help on IRC (#tracker) and we can work from there.

How I became a GNOME contributor

Recently, I was asked by my fellow GNOME friends to write how did I transitioned from nothing to a GNOME contributor. The intention is to motivate people to engage. I don’t think my story is that exciting, but, well, why not? If someone gets motivated and start contributing, goal achieved. But beware: there ain’t any TL;DR here. it’s just a long story.

So, where should I start?

From Childhood to Early Contributions

My relationship with computers began at early age, since I was literate by my parents using an old computer we gained from a relative. I remember searching “how to create exe files” around 2004, and that search result yelled me a Yahoo! Answers question with “you need to learn a programming language. Start with C”.

And so I did.

My first app was a command line calculator. Moving to Linux was a natural step. And that introduced me to GNOME, and Gtk+. By that time, Gtk+ was still 2.6. I did some small apps for personal use, like an app to track new habits. Unfortunately, those apps are long gone.

And that’s how it all started.


Fast forward some years and, one day, while using a GNOME app (can’t remember which one!), I saw an unstranslated string! I researched a bit and found out that I could translate and contribute to the Brazilian Portuguese translation team. This was 2012, GNOME 3 was just released, everybody were still very angry, things were very confusing.

My first upstream contributions back to the end of 2012, fixing and adding some missing translations.

At that time, there was one project that draw my attention: a new, unreleased app called GNOME Calendar. It was under heavy development in a branch called ui-review, no packages were available… and yet, I simply loved it. The developer, Erick Perez, is highly skilled. This app was a hidden gem.

Unfortunately, development of Calendar stalled and I spent more than 1 year checking the logs almost every day, waiting for changes.

They never came.

… and GNOME Calendar

“This project was too good to die”, I thought. “I have to do somthing.” First, I tried to finish the design specs of Calendar. You can still find it in my DeviantArt page (click here to check it out).

Then I ran Gedit, opened some files and started hacking Calendar. My very first work was on the Week view prototype we had in there. The video of this new feature is still available:

Notice that the second article of this blog talks about that 🙂

Erick saw that, sent me an email, I attached some patches to Bugzilla, and this is how I officially started contributing to GNOME. At the same year, GNOME Calendar had its first release ever – and this makes the third article of this blog.

GNOME Foundation and Google Summer of Code

After increasing my contribution rate at GNOME Calendar, Erick suggested me to get a Foundation membership. In Januray 2015, I applied and was accepted (yay!!). At the same year, I decided to apply for a Google Summer of Code project at Nautilus. The mentor was Carlos Soriano.

The GSoC project was very successfull, and not only Nautilus received the improvements, but also Gtk+ itself. This is when the “Other Locations” view was introduced, and a big code refactor landed (and allowed Nautilus to improve much more!)

Captura de tela de 2015-12-11 02-45-11
The results of that Summer of Code project

Fun fact: while organizing the tasks of the GSoC, I couldn’t find any personal task manager for GNOME that satisfied me. I took one week and create GNOME To Do to organize my tasks.

With that done, the only step left was presenting that work at GUADEC.

GUADEC and Endless

The presentation at GUADEC was good enough, and meeting the people behind GNOME was one of the most remarkable experiences in my life. At that GUADEC, I met Cosimo, who works at Endless. I remember he downloading the new Gtk+ version and saying “look at this cute ‘Other Locations’ button!” (!!!) 🙂

A few weeks after that, I was contacted by Endless, where I am up to this day. Here at Endless, I’m lucky enough to be able to work upstream almost by default. I’m also happy to be able to make GNOME (through Endless OS) reach more people around the world.

What’s next?

New Control Center, more features in Calendar and To Do, and some other surprises I’ll write about in the future 🙂

The new Online Accounts & Printer panels (and other related news!)

Greetings, GNOMErs!

If you’re watching closely the GNOME Control Center iterations, you probably noticed it already has a bunch of new panels: Keyboard, Mouse & Touchpad, and other panels like Sharing, Privacy and Search that don’t need to be ported.

I’m pleased to announce that the Online Accounts panel joined this family.

Check this out:

Captura de tela de 2017-02-23 10-27-19.png
The new Online Accounts panel

This panel was easier to be ported since the codebase was already somewhat recent. It now features a single-column layout, which fits perfectly the next shell of GNOME Control Center.

Editing and creating accounts are now handled in a separate dialog:

Editing an account
Adding a new online account

But that’s not all!

The new Printers panel

Thanks to the always awsome Felipe Borges, we have a brand new, super shiny Printers panel. Most importantly, it has colored ink indicators! Dude, what else could you ask for?

I’ll let Felipe himself write this one in details, but why not tease the audience? 🙂

Captura de tela de 2017-02-23 10-45-52.png
Super beautiful Printers panel (uh… no printers here)

Lets shout a big thanks to this great GNOME contributor!

m(_ _)m

What’s left?

In order to permanently switch to the new shell (the one in the screenshots), there are three major panels to be reworked:

  • Sounds: required to switch to the new shell, the Sounds panel will probably be very time consuming.
  • Networks: another required and hard panel. This panel will be split into Wi-Fi, Mobile Broadband, and Networks, and it’ll probably require a lot of work too.
  • Details: each tab in the Details panel will be split into a separate panel. It’ll be mostly manual work, and it’s easy (anyone interested in picking this one up? 🙂 )

This work can be tracked here. Excited? Join us in creating the next generation Settings application – contributions are so appreciated!

Meet the new Week view

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:

Introducing the Week view

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
  • Being beautiful
  • Handling too many events

And so it goes. You can create all day and multiday events very quickly:

Creating all day, multiday events by clicking the header

Of course you can also create timed events with the new week view! Check this out:

Creating a timed event in the week view’s grid

And, as always, the traditional sequence of pictures with an awsome rock-ish soundtrack!


Excited? Join #gnome-calendar IRC room at, 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 history about Gtk+, Vulkan and Wayland

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:

The Fishbowl running under Wayland and rendered with Vulkan

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 layers work 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!

The future of GNOME Music

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.

Long ago…

There was an app called GNOME Music. It was written as a quick prototype in JavaScript. Then, another version of the same app was written in Python, and this snaky version of the app was more complete than the other.

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:

Music codebase as it looks right now

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:
      • Albums
      • Artists
      • Playlists
      • Search results
    • 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
      • Data sources
      • The Player
      • Album art cache
      • MPRIS
  • 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:

Next architecture of GNOME Music


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.

And the Sun starts to shine again on Music land.

Core Apps Hackfest afterthoughts

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.

App-specific discussion


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).

GNOME Calendar

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.

Generic discussions

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.

I somehow got involved a lot with GNOME Music development, so we discussed how can GNOME Music handle that. We ultimately realized that it’d be better for everyone if we do it The Right Way © and land the code refactorings and backend work before even attempting to do that. This will avoid having to implement the feature twice (before and after the refactoring) and frustrating people with eventual breakages.

This won’t affect GNOME Calendar nor GNOME To Do at the moment, so this discussion wasn’t my focus.

Some Highlights

There’s a bunch of things that happened during the hackfest that I’d like to highlight:

  1. 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.
  2. The new Online Accounts panel patches were reviewed, and started to land on the main codebase. Thanks Rishi!
  3. 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.


New features in GNOME To Do

It’s been a while, folks.

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.

Many plugins are available now – and the list will grow.

I, for one, don’t use the ‘Scheduled’ panel that much, so I simply wiped it out of my way.

GNOME To Do without the ‘Scheduled’ panel

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.

Management of subtasks is done by Drag and Drop

You can drag a row over another one, and tada!, you just made the dragged row subtask of the hovered row.

Subtasks in GNOME To Do

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.

The new Dark Theme plugin in action.

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.