The Road to 3.28: Calendar and To Do

New tasklist view in To Do 3.27

Greetings my GNOME friends!

It’s been a long time with no news. I guess work and masters are really getting in the way… good news is that I’ll finish masters in 2 months, and will have some free time to devote to this beloved project.

“Bad” news is that, after almost 6 years, I’ll finally take some time to have a real vacation. I’ll stay 3 weeks out of the loop in February, a time where I’ll be traveling to the other side of the world, watching the sunset at the beach with my wife. Without a computer. While it’s unfortunate to the community, I think this time is necessary for my mental health – I’ve gone way too many times through the almost-burned-out state recently.

But even with all of these thing in our way, thanks to the help of awsome old and new contributors, Calendar and To Do received a lot of new features!

Calendar

Lets begin with my beloved Calendar. My focus for the past weeks was rewriting the Month view. It was a hard, painful process, but I can say for sure now that, of the very few responsive widgets in GNOME, the Month view is the best one! 😛

The most substantial changes were:

  • The day numbers are at the top of each cell now. This is thanks to the hard design work of Allan Day, Jean-François and Lapo.
  • Each cell now only shows the overflow button when absolutely necessary. When implementing this new behavior, a few longstanding issues were fixed.
  • The Month view now finally has a fully working, sane code to deal with RTL languages.
  • When clicking the +N button, the cell “zooms in” and display the list of events. This is a big design improvement over the popovers that we were using.
  • Code-wise, the Month view code that position the events is an order of magnitude simpler and easier to read. It may sound like a purely technical matter, but it has user-visible effects too: easier, cleaner code means more features and less issues in the future.

Of course, no words can make people as excited as a sequence of pictures! Lets check this out:

 

The animations were implemented usuing the animation framework in libdazzle, all thanks to Christian Hergert’s work on GNOME Builder. Kudos!

For the next cycle, thanks to the hard work of a new and awsome contributor Florian Brosch, this is what’s coming next:

Weather indication in Week view
Weather indication

We’re on track to land the features that were proposed for this cycle. You can check out the plans at the Roadmap page of Calendar. You can also get help us with these tasks with design, code and testing!

To Do

GNOME To Do also received a lot of attention already. We’re going through a big redesign, thanks to the leading design work of Tobias Bernard, and the results are already gratifying.

The immeditaly noticeable change is the tasklist view:

New tasklist view in To Do 3.27
New tasklist view in To Do 3.27

 

The rows are entirely draggable now. I’ll continue working on these features, but more importantly, I want people to take some of this work over and contribute to the project!

Talking about managing tasks, GNOME To Do was moved to GitLab! I can’t state how much of an improvement it is over the previous Bugzilla approach. We now have an updated and organized Kanban Board:

 

GNOME To Do in GitLab: the Kanban Board
GNOME To Do in GitLab: the Kanban Board

The reason for that is to have a consolidated workflow:

  • A designer moves the task to “Design” column and works on it.
  • Once design is settled, a developer moves the task to the “Development” column and fixes/implements the task.
  • When the task if implemented, the developer moves the task to “Code Review” column, and a maintainer will review the code.
  • Once the code is reviewed and the code landed, the task is moved to the “QA” column, where a tester will pick up and test it.
  • When all the regressions and issues of that task are fixed, the task is closed

So far, the experience with this workflow has been outstanding. We were able to find out much more bugs due to QA being a first-class citizen in the process.  Filing bugs is now a breeze too! There are bug templates already available, and I took the burden and made a colossal cleanup and organization of the bug list:

GNOME To Do in GitLab: Issue Templates
GNOME To Do in GitLab: Issue Templates

I encourage everyone to not trust me and go check it out: https://gitlab.gnome.org/GNOME/gnome-todo. The downside is that I’m feeling incredibly demotivated to check Calendar bugs in Bugzilla now 😦

We’re Not Quite There Yet

While many of these changes are super exciting, this is just the first part of the cycle. There are much more to work on, and the more people get involved, the more we will accomplish. Things are moving in a fast pace, and I’m incredibly happy with the direction of these projects.

To help pushing community involvement, I went ahead and wrote a page describing how can you help testing. With Flatpak, this is ridiculously easy – and yet, absolutely necessary! So, don’t hesitate to get in touch and help us shaping the next GNOME version.

See you all around o/

Advertisements

Improved half tiling available in Mutter 3.26.1

A late night announcement: the improved tiling patches (shown in a previous blog post) were merged in Mutter and and GTK+3, and will be available in GNOME 3.26.1 / GTK 3.22.23 (not yet released; should be available this week).

I’d like to thank Florian Muellner, Matthias Clasen, Jonas Adahl and AlexGS for all their support, time, code reviews and testing.

Have a wonderful night!

Visual revamp of GNOME To Do

Greetings, GNOME friends!

I’m a fan of productivity. It is not a coincidence that I’m the maintainer of Calendar and To Do. And even though I’m not a power user, I’m a heavy user of productivity applications.

For some time now, I’m finding the overall experience of GNOME To Do clumsy and far from ideal. Recently, I received a thank you email from a fellow user, and I asked they what they think that could be improved.

It was not a surprise when they said To Do’s interface is clumsy too.

That motivated me to experiment and bother our designers about ways to improve GNOME To Do. With the great help of Tobias Bernard, a super awsome contributor, we could figure out a way to improve the current situation.

Opaque Task Rows

One of the problems of GNOME To Do was the translucent task rows. Priorities would be semi-transparent colors applied on top of transparent rows.

Of course this mess could lead to things like this:

Mess
Can you tell which tasks are high, medium and low priority tasks?

After some investigation, a lot of experimentation and feedback from multiple design team members, we could come up with this:

New colors
All opaque rows with priorities at the borders.

I personally think this is a small, but huge improvement over the previous state. When you have to stare at tasklists for hours, the minor annoyances are what causes the biggest frustrations.

Inline Editing

Another big aspect of To Do that was the task editor panel. This was initially made based on some old mockups, but this proved to not be the ideal experience.

The biggest problem was that there were no connection between the editor and the task. Of course there is an arrow pointing to the task row, but consider that:

  • The task title is edited in the task row
  • All other fields are edited in the side panel
  • The arrow might now be obvious to spot
  • The real representation of the task was the row, not the panel

So Tobias suggested me inline editing of tasks. I went ahead and implemented it, and the result looked actually very good!

Inline editing
Editing the task where the task is represented.

The necessary width was reduced, and now the window can be shrinked to small sizes. And it works nicely on Dark Themes too:

Dark theme
New rows on Dark Theme variant

This work already landed on master, and will be part of GNOME To Do 3.28. And, of course, our traditional sequence of images:

 

Any comments? Thoughts? Please let me know in the comments! And don’t ever forget, you can always get involved – you just need to get in touch, and join us at #gnome-todo at irc.gnome.org.

Enjoy!

GUADEC + Unconferences | 2017

This year’s GUADEC was amazing. I’m really happy I could attent it this year (even though my tasks are accumulating and I’m really afraid to look at my emails again…). I’m still in Manchester so, if anyone wants to meet me and buy me a tea, do get in touch!

There were quite a few talks that I enjoyed. I can’t really name one that I liked the most, but on the top of my list are:

I had a special interest in Richard’s talk. He raised many relevant questions and exposed how complicated it can potentially be the problem of donations and payments. More about that in the future.

Calendar & To Do

I had the chance to sit down and see a power user interacting with GNOME Calendar. It was an unique and enlightening experience. I was able to see a few areas where Calendar can do better in terms of UI/UX.

Unfortunately, GNOME To Do didn’t have the same luck. I’m still somewhat unhappy with the current UI of To Do, but I’m running out of ideas on how to improve it without a complete rewrite (which I simply don’t have time to do now). If you’re a GNOME user with any kind of background on design, ~please~ get in touch: I’d love to gather some feedback on To Do!

GTK4

I had the chance (and honor) to be present at the discussions for GTK4. In these discussions, we did a big list of topics and discussed each one of them in details.

This slideshow requires JavaScript.

I admit that, during these discussions, I felt like a kid at times – the GTK hackers are incredibly smart and skilled people. The other side of the coin is that, while I was feeling like lagging behind them, I also felt honored and happy to be surrounded by such amazing people.

The biggest problem to solve now is the accessibility stack. After digging into the topic and clarifying how it works, we concluded that this topic was too big and complex for that moment, and deserved a hackfest of its own. We’ll organize one during the next months.

Wrapping up, I can’t state how productive these discussions were. Thanks to Matthias Clasen, Benjamin Otte, Christian Hergert, Cosimo Cecchi and everyone else that drove the discussions. We now have a solid GTK4 roadmap that I’ll move to the GNOME Wiki in no time.

GNOME Shell

An unexpected thing happen during the Unconference days. When talking to my good friend Mario we asked ourselves: how can we improve our own Endless tasks by upstreaming our features?

Endless OS shell has many features that GNOME Shell doesn’t, and maintaining downstream patches is expensive and simply not cool. One of these features was specially important, as it is difficult to maintain and lots of GNOME users frequently ask for.

This specific feature was considered in the past, but had many design constraints and we end up never solving it design-wise, nor implementing it.

This is about to change.

After a rather spontaneous group discussion, we found solid solutions for all the relevant edge cases of this feature 🙂  I’m sure Mario will write about it in the future, and probably will implement it as well, so stay tuned!

Because, in case you forgot:

banner down

(And yes, I purposely didn’t say which feature I’m talking about – but I’m sure many of you can guess that :P)

Mutter

After a long explanation and discussion with Florian Müllner (and of course, getting him a well deserved beer for being the GNOME Shell and Mutter maintainer!) the path for quarter-tiling is much clearer now.

The original idea is to implement tiling support using constrained edges, rather than tiling states. But this is hard, and now I believe it’s effectively impossible to do that.

Olivier Fourdan tried to propose a Wayland protocol for that, but discussion ended up freezing and no progress was made for a long time. I admit I’m kinda scared to try to send  these changes upstream… see the bug’s feedback (sometimes I forget that the GNOME community is much more welcoming than many other FOSS communities).

I now have a real problem to solve, and the time is not enough. Perhaps it’s time to declare bankruptcy?

Acknowledgements

I’d like to thank the GNOME Foundation for sponsoring me. I sincerely hope that my engagement and contributions pay off this investment!

I also thank my employer Endless to let me join. The upstream contributions we’re doing are valuable for the community, and in turn it helps us lowering the number of downstream changes to maintain.

sponsored-badge-shadow

Say hello to the new Wi-Fi panel

The new Wi-Fi panel

Hello my GNOME friends 🙂

Y’all know that we’re taking big steps to move Settings (a.k.a Control Center) to a brand-new, super shiny layout. As a courtesy of our beloved designer, Allan Day, we have mockups of a new Settings layout that is both modern and preserves (most of) the functionality we already have. He blogged about it in the past.

I found those mockups quite nice, so I decided to work on them!

As YouTube people say nowadays: I’m a simple man. I see a good mockup, I implement it.

Before switching to the new layout, though, we needed to get rid of the panels with a sidebar. Namely: Online Accounts, Keyboard, Network, Printers and User Accounts. Thanks to Felipe Borges, who reimplemented a few panels himself, we were able to progress faster than expected!

This time, I added the new Wi-Fi panel. Check this out:

The new Wi-Fi panel
The new Wi-Fi panel

 

Compare this with the current Network panel, which still has a sidebar:

The current Network panel
The current Network panel. Notice that the panel sidebar looks bad with the new Settings shell (that already contains a sidebar).

 

With the new Wi-Fi panel, we’re close to making the new Settings shell the default one; the biggest blocker now is the Network panel, which I’m already working on. And finally, after more than a year working on the new Settings layout – and with the help of many super awsome contributors! – we’re almost there 🙂

And our traditional sequence of pictures:

 

Oh, and did you notice? The connection editor dialog was also redesigned! It’s much simpler and saner now, do try it out and let me know what you think.

The new Wi-Fi panel has a few advantages:

  • It’s beautiful 🙂
  • It handles multiple Wi-Fi adapters slightly better
  • It’s just easier to use
  • (Future) When the host doesn’t have a Wi-Fi adapter, the panel won’t be visible

Afterword

I’d like to say a big and warm thank you to all contributors that made this possible, and specially to Bastien Nocera and Rui Matos for reviewing all this work and many other patches.

There’s still quite a lot of work to do, and it won’t be easy, but we’ll eventually make it 🙂

Improving productivity with GNOME Builder

Hello community,

as you can guess, I’m a heavy user of GNOME Builder. I use it every day to build various things, most of which you guys know of already 🙂

Because I spend so much time on it, it is essential that Builder simply Just Works ®, and perfectly. Builder sometimes shows a rough edge here and there, but all in all, it’s a masterpiece. It’s awsome in many aspects! Christian Hergert really deserves our respect (and, why not?, many free beers too!)

However, it wasn’t enough.

I like to focus on my tasks, and I usually do it by making the window fullscreen. Even if Builder is already great, it doesn’t support fullscreen.

So that’s what I did.

Let the work speak for itself:

 

Thanks to Christian’s quick fingers, it is already in master. From now on, this will only get better.

Enjoy!

Even faster GNOME Music

Hello my GNOMEish friends!

This afternoon, I felt an urge to hear some classical music. Perhaps because I’m overworking a lot these days, I wanted to grab a good hot tea, and listen to relaxing music, and rest for a few minutes.

My player of choice is GNOME Music.

In the past, I couldn’t use it. It was way too slow to be usable. After a round of improvements in a sleepless night, however, Music was usable again to me.

But it was not fast enough for me.

It was taking 15~20 seconds just to show the albums. That’s unacceptable!

The Investigation

Thanks to Christian Hergert we have a beautiful and super useful Sysprof app! After running Music under Sysprof, I got this:

Sysprof result of GNOME Music
Sysprof result of GNOME Music

Clearly, there’s an area where Music hits the CPU (the area that is selected in the picture above). And, check it out, in this area, the biggest offenders were libjpeg, libpixman and libavcodec. After digging the code, there it was.

The performance issue was caused by the Album Art loading code.

The Solution

Looking at the code, I made a simple experiement: tried to see how many parallel lookups (i.e. asynchronous calls) Music was performing.

The number is shocking: Music was running almost 1200 asynchronous operations in parallel.

These operations would be fired almost at the same time, would load Zeus knows how many album covers, and return almost at the same time. Precisely when these lookups finished, Music had that performance hit.

The solution, however, was quite simple: limit the number of active lookups, and queue them if needed. But, limit to what? 64 parallel lookups? Or perhaps 32?

I needed data.

The Research

DISCLAIMER: I know very well that the information below is not scientific data, nor a robust benchmark. It’s just a simple comparison.

I decided to try out a few lookup limits, and see what works best. I have a huge collection, big enough to squeeze Music. I’m on an i7 with 8GB of RAM, 7200RPM spinning hard drive.

It was measured (i) the time it took for the album list to show, (ii) the time for all album covers to be loaded, and (iii) a quick score I made up on the fly. All of them are of the type lower is better. I ran each limit 10 times, and used the average of the results.

Time comparison
Comparison of various lookup limits

The “No Limits” columns represent what Music does now. It takes a long time to show up, but the album covers are visible almost immediately after.

First conclusion: limiting the number of lookups always performs better than not. That said, the problem was just a matter of finding the optimal value.

After some trial and error, I found that 24 is an excellent limit.

The Result

In general, the initial loading of albums with the performance improvement is around 73% faster than without it. That’s quite a gain!

But words cannot express the satisfaction of seeing this:

Enjoy!!

Smarter half tiling in GNOME Shell/Mutter

Hello GNOMErs,

I think that, at this point, at least a good part of the community is aware of the many new features that are planned to arrive with GNOME 3.26.

I’m particularly looking forward a better tiling story in GNOME Shell and Mutter.

And, y’know, I’m not exactly a referrence in being passive about my own personal technological wishes. Heck, I love hacking stuff so much that it naturally happens even when I’m sleepless and under headache. Perhaps we can call that organic hacking? 🙂

Anyway, I can’t just sit down and keep waiting for something I could work on, right?

And that’s why this happened:

This is obviously a work in progress. You can track the progress of this smarter half tiling in bug 645153. But, sssshhh don’t tell anyone, this is actually part of the future quarter tiling feature!

Have a wonderful night! o/

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:

$ ./autogen.sh --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

If you’re reading this post, please also read the one about GNOME 3.26. I’ll leave this post here for historical purposes, but you should disconsider what I say here.

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