The next big thing

GNOME 3 has come a long way since 3.0. When you compare what we have now to that initial 3.0 release, the difference is quite huge. Though it might look similar, the experience of using it has improved dramatically. This improvement is a major achievement, and has only happened thanks to the tireless efforts of the GNOME community.

With each release we’ve achieved a significant improvement to the overall experience. We’ve filled out the experience with major new features like system-wide search, the lock screen, online accounts, and a raft of new apps. Also, when necessary we’ve made major design changes, such as with notifications.

Much of this work has been a hard slog: reviewing every little bit of UI, and improving it one step at a time. We had round after round of Every Detail Matters to get the shell up to scratch, just as we’ve refined the apps with each subsequent release.

Not all of this work has been glamorous or exciting. Gradual refinement, release after release, isn’t something that makes the heart race. However, this kind of dedication has been absolutely essential, and it’s essential that it carries on: that we keep up the pace of improvement, so every version is better than the one before.

It’s important to remember the progress that we have made, because it is easy to forget how far we’ve come.

At the same time, when you are in the routine of making iterative improvements on a time-based schedule, it is easy to lose sight of the bigger changes that are happening around you. It is here that I want to draw attention to two significant developments that are currently happening in the GNOME project.

Application sandboxing

Alex’s incredible work with xdg-app is a subject that gets talked about a lot, but it really can’t be emphasised how significant it is for GNOME as a project.

The cross-platform and security aspects of application sandboxing are important, but there’s a lot more to it than that. It will enable us to improve the whole user experience, by enabling the OS to be more robust and stable, and by improving performance. It will also allow more flexible release cycles for applications, without having to wait for the next version of a specific distro, and it promises to transform the application developer experience.

This could have significant implications. Perhaps it will be the end of the six month release cycle for many GNOME applications?

GTK+ Scene Graph

Development of the GTK+ scene graph has been trundling along in the background for some time, thanks to Emmanuele. It is really starting to get somewhere now, and will allow interfaces that make greater use of animations.

There are some obvious uses for the GTK+ scene graph, but there are also many other possibilities and real scope for experimentation. The introduction of more widespread animations could have a revolutionary impact on how we design and create GNOME applications.

Putting it all together

Each of these initiatives has developed independently, and it’s easy to focus on them individually. However, I think that we should be viewing them as elements of something bigger: the next significant evolution of GNOME. We might just be on the verge of the next big thing, the next evolution of GNOME.

And since we are potentially at a major turning point for the platform, it is worth thinking about other changes that could form part of new vision for GNOME 3. For example, one thing I would particularly like to see is a greater emphasis on cloud integration, so it is possible to have a fully cloud-backed GNOME experience. I’m sure there are other changes that we should also be considering.

GNOME still needs to keep iterating: slowly and gradually improving every aspect of the user experience. At the same time, it is healthy to periodically think about the big picture and bigger changes. I think we have the basic ingredients for a new vision for GNOME 3: something new, exciting, and potentially revolutionary.

27 thoughts on “The next big thing”

  1. Hi!
    I’m really looking forward on “GTK+ Scene Graph”. That will become interesting. While cloud integration doesn’t bother me, I would be really careful about it.

    Priorieties:
    1. Do locally a good job
    2. Do remotly a good job (on standardized protocols like SSH, FTP and WebDAV)
    3. Cloud stuff controlled by me (e.g. Owncloud)
    4. Cloud stuff by some company

    So what is the general problem with the “Cloud”?
    Is not on the machine of the user and therefore always slow and potentially unrealiable. If the data is stored not on your very own server you are no longer controlling your data, which is against the ideals of free software.

    So what is the technical problem with the “Cloud”?
    The break the APIs! Not you!

    A desktop has to be usable over years or even decades. The frequent creation, selling and liquidation of so called “startups” is a problem. Furthermore these companies (and here especially Google) doesn’t care much about stable APIs to third parties.
    I just remember all the pain around 2-Factor-Auth and Google. A horrible nightmare! You’ve ended up with two options, upgrading the howl GNOME (Fedora in this case) or switching to a reliable protocol like IMAP.

    If you desire to integrate more remote services like cloud I recommend strongly to stick with well known protocols or define APIs on your own.

  2. To me, the biggest improvement that could be made to GNOME 3 would be to remove that slow and clunky feel to it.

    Seriously. The user interface is easily the best we can get on GNU/Linux right now, and yet, I always feel obligated to try out Xfce at some point to realize it’s so much nicer to use. It feels light, because there is no stuttering at all that ruin the user experience. And then I come back to GNOME 3 because the integration is so much better, among other aspects.

    This is all caused by the shell. Poor architecture decisions were made at the very beginning of the project, causing Javascript to be able to block the compositor thread. It was hard to notice on X11, but the issue has always been there. Now with Wayland, every stutter is visible because the mouse cursor stops responding entirely. https://bugzilla.gnome.org/show_bug.cgi?id=745032

    If we want to move forward, this issue needs to be resolved. It would make GNOME 3 finally usable on slow computers, and actually nice to use on powerful computers.

    1. It’s a personal suggestion, not an announcement. I don’t think that any of these changes would strictly require a major version bump.

      1. as a developer i kind of disagree with this. xdg-app will provide complete 180 to how one can deploy his app. just this definitely warrants 4, if for no other reason than enabling clean break where apps can simply say they need 4.0 min.

        move as big as that is much harder to adopt if you say 3.22 instead of simplify it with 4

    2. Please no!
      It is the first time since 3.6 that Nautilus provides a fast file navigation by Type-Ahead-Navigation[1]. Furthermore this is also working in the GtkFileChooser. An nice progress bar for file operations and so on.

      Thanks to Matthias Clasen and Carlos Soriano and others!

      Furthermore that GNOME-Shell itself feels slick since some releases and is fast for keyboard users (Press Key and Type!) and easy for mouse users. And we’re getting now a decent development environment with Builder!
      Yes. A lot of things went wrong, to much features (especially Nautilus 3.8 – 3.16 and Terminal) were removed and Gtk+ lost a lot of support through Sun and Nokia. But GNOME3 begins to feel really good and mature. I would improve it instead of destroying and rebuilding, because it is already getting better and better on a good base.

      And know the hard truth:
      Firefox – Still Gtk2
      Gimp – Still Gtk2
      Inkscape – Guess what…
      Wireshark – Tries to move to Qt…

      I would strength the platform. Parasite (now with awful boring name…but everywere available!) was a very good first step.

      [1]https://csorianognome.wordpress.com/2015/09/04/nautilus-3-18-comunicating-changes/

      1. Hey hoschi, I’m not advocating abandoning recent improvements. We should definitely build on the progress we’ve made so far.

        1. I know that Allan and improving things is always right!

          I just want really be careful with any premature suggestions. The lost of beloved features in the past years was really a problem and now a lot feature have returned (some even in better shape) with GNOME 3.18 and it feels better that ever. And there is space fur further improvments :)

      2. At least the nightly builds and the developer edition of Firefox (Aurora) use Gtk3. I don’t know when this will migrate to the release version (or if it already has migrated).

  4. The 3.18 release has been one of the best for GNOME.
    Thank you for your tireless efforts.

    I have a question: What about an app for RTC in GNOME? Empathy will remain the default messaging application in GNOME?

    Thanks

  5. A UI refresh for Empathy (Single Window Mode) would be really pleasant. But I remember that Allan didn’t succeded to get developers behind this idead.

    Sadly XMPP suffers a problem: No video/audio (Jingle) support on any major plattform, despite GNOME and KDE. Their is no Windows client but Jitsi and Android, as well as Jolla a completely lacking of this. Google constructed Jingle, included it in Android and removed Federation to XMPP (killed half of my contact list).

  6. I’ll probably get shot for this…but… Themes?

    I don’t mind the Gnome3 GUI, but it is very different. Maybe there should be a “Professional” theme that was closer to the old-school Window 95 layout.

    I’d love Gnome to be a general drop-in replacement for Windows boxes. The default Gnome 3 GUI is just too alien for this.

    1. GNU/Linux is not an alternative to Windows. It is a completely different operating system, with a lot of awesome and different features and a very own heritage. Same for GNOME, it is a completely different UI than the Windows-UI and doesn’t offer a Windows like experience.

      What you want is ReactOS.
      Most people who are frustrated about GNU/Linux or unhappy about anything are trying to use it as alternative to Windows. And with a similiar UI it get even worse, the UI of Windows will suggest that the system behind is “similiar” what is wrong.

    2. “Professional”? or… “How we did it in stone age under dodo overlords”. i think second would be much more suitable name ;)

      calling it “Professional” would say what? that desktop they ship is not the desktop they believe in since there is a so called Professional version of it that looks and works nothing like default?

      3.18 default is simply by far best desktop i ever used in my life

  7. I would really like a better window management to be implemented by the shell. For example: there are desktop spaces but all window icons are shown on the dock. This is contradictory. It is the same when you switch the windows by pressing alt+tab because all windows are also shown by default. I think that they should decide whether they want people to use desktop spaces or not and be consistent with the decision they make.

    And it is absolutely annoying when you have several windows of the same application open and you cannot distinguish/find easily the window you want from so many other windows. On the Windows interface the corresponding thumbnails are shown when you click on the icon on the bar. In my opinion something like this should be implemented by the GNOME shell. I know that you can right click on the icon and see the list of window titles but given that all thumbnails are already shown in the screen, why not to show just the corresponding windows when you click on the icon?

    I really appreciate the work made by GNOME people but I think that it is this kind of things which could mean a huge step forward and perhaps not all those cloud stuff.

  8. Out desktop-experience need to evolve to a front: font management. What we need at first is an user-space font-manager for fonts, able to view system-fonts, able to make personal collections/catalogues of fonts, with gtk widgets (eg. the font-selector dropbox) able to {find,use,share} fonts, with a way to switch between collections.

    The second step, outside the desktop-experience, should be at system level (eg. with systemd integration) to control every single font installed, paths (local or not). In other words, a XFS (X Font Server) renewed and ported to the lowest (system) level.

  9. Hey Allan,
    GNOME 3 has made huge progress, and won me over since 3.14.

    However, there’s still a lot of work to do on the apps.
    Some apps are very CPU heavy for no reason: agenda for instance, is constantly using 30% of my i7. Photos takes a bunch of CPU and time to download photos from my online account, with no indication of progress.

    1. The CPU issue in Photos is one of the many known deficiencies of GtkIconView. Taking a stack trace (gstack $(pidof gnome-photos)) while it is eating CPU will confirm this.

      The solution will probably involve GtkFlowBox.

  10. When I switched from my Openbox-based desktop with cherry-picked GTK3 applications to Gnome (it was around the time of 3.8 IIRC), to be honest I forced myself to adapt because I wanted to be ready for the eventual advent of Wayland.
    But my feelings have definitely grown into love for an amazing platform! :)

    What I really would like to have in the future (but I don’t know if it’s even possible because of the non profit status of the organization) would be cloud synchronization of settings, accounts, extensions and the more the merrier!
    I’d gladly throw my wallet at you for a paid service that helps maintaining server costs!

  11. It would be great if Gtk-with-scenegraph and no longer need Clutter as a seperate thing.

    Hopefully using the new GL based tech will simplify implementation and make cross platform Gtk more of a reality – it would be great if builds for Windows and OSX would be integrated into the Gtk build infrastructure.

  12. I like the idea of having a bunch of core apps. Mail and RTC need such an app. I’d like to use a set of small and nonetheless well integrated apps for mail, chat, calendaring, contacts, notes and todo: Evolution is quite complex. While Empathy is missing OTRS and its development (almost) has stopped, Polari supports IRC only, while XMPP would be more important (to users, not devs only). The development of Pidgin keeps slowing down and Jitsi is changing its focus. We have OTR now in the Telepathy framework. It’s time to convert Empathy into the chat core app … anyway, I really love GNOME. Thanks a lot, guys :-)

  14. My biggest concern is:

    Deprecation of UIManager in Gtk4. There are no replacement that can handle toolbars and merging and unmerging. We use Addins in our application and need to be able to merge in Menu and Buttons(toolbar). This need to be solved, either by making the new GAction stuff handle Toolbars and merging/unmergin or be undeprecating the UIManager.

    The change to Popover in comboboxes. A popover can’t be lager than it’s parent window and the is a problem. I know that Wayland will fix this, but this need to work on Windows and Mac OS X aswell.

    Cross platform is very important to us.

    1. You should definitely bring these concerns to gtk-devel-list.

      I can quickly answer on GtkUIManager: merging and unmerging can be done with GMenu and GAction; we are kind of phasing out large toolbars, but you can use containers like GtkStack and GtkRevealer to build different toolbars and showing them when modes change, instead of merging/unmerging widgets. Ideally, though, adding support for toolbars to GAction and GMenu should be feasible. We’re definitely not going to undeprecated GtkUIManager — it’s redundant to two different APIs (GtkBuilder and GMenu/GAction), and it cannot be retroactively fixed to export menus on the session bus, which we consider a key functionality for multiple platforms: GNOME, Unity, and OSX.

      As for combo boxes, I’m not sure I follow; combo boxes haven’t been moved to popovers. There’s a plan for a simplified widget that uses a popover, but it hasn’t landed yet. Popovers do extend outside of the window on Wayland and, ironically, it should be easier to make them do the same thing on OSX and Windows than on X11, because of the various grabs that we even have to emulate on those platforms, and that led to the creation of popovers.

      It all comes down to: are you willing to help out with improving, testing, bug fixing, and QA-ing the backends and functionality you need? GTK is not a “black box”; we don’t have engineers working full time on supporting different platforms, or doing QA. If you have an issue, you *need* to get involved — like the Elementary developers, or even corporate developers using GTK in their consumer products. What you cannot do is picking up GTK every 12/24 months, list the things you use and that have been deprecated, and not put any work into ensuring that the direction the toolkit is going towards also includes your use cases — because, at the end of the day, the people that do work on GTK do exactly that.

Comments are closed.