Development of Nautilus – Popovers, port to GAction and more

So for the last two weeks, I have been trying to implement this:

The popovers!

In an application that already use GAction and a normal GMenu for everything is quite easy.

But Nautilus is not using GAction neither GMenu for its menus. Not only that, Nautilus use GtkUIManager for managing the menus and GtkActions. And not only that, Nautilus merge parts of menus along all the code.

Also, the popover drawn in that design is not possible with GMenu because of the GtkSlider.

So my first step, when nothing was clear for me, was to just trying to create a custom GtkBox class to embed it on the popover and try to us the current architecture of nautilus.

It didn’t work, obviously. Fail 1.

Then after talking with some Gedit guys (thanks!), I understood that what I needed was to port Nautilus to GAction first. But, I will have to find a solution to merge menus.

My first week and a half was trying to find a solution on how to merge the menus, along making the port to GAction and refactoring Nautilus code to make it with sense and being used to the code of Nautilus.

The worst part was the complexity of the code, understanding it and the its intricate code paths. Making a new application test with GMenu and popovers merging menus was kinda acceptable.

To understand why I needed to merge menus recursively, this was the recursion of nautilus menus that was done with GtkUIManager along 4 levels of classes. That diagram should have more leafs (more classes injecting items) at some levels, but this was the most complex one.:

Dibujo sin título

So after spending more than a week trying to make it work at all costs,  I figured out that merging menus recursively in recursive sections was not working. That was kinda frustrating.

Big fail 2.

Then I decided to get another path, with the experience earned along that one week and a half.

I simplified the menu layout, to be a flat layout (still I have to merge a one-level menus, so a new way to merge menus was born), put all the management of the actions on the window instead of having multiple GtkActionGroups sparsed on the code as Nautilus had previously, make the update of menus centralized on the window, attach the menus where it makes sense (on the toolbar), and a beautiful thing, the toolbar of nautilus (aka header bar) is now on a xml gresource file, not longer making it programatically =).

That last thing required to redo a good part of the toolbar, to for example use the private bindings that GObject provides (and then be able to use gtk_widget_class_bind_template_child_private) or sync the sensitivity of some widgets that were synced directly modifying the actions on the window instead on the toolbar, etc.

And thanks to the experience earned in the fails before, it started working!

Then I became enthusiastic to add more and more part of nautilus ported. After the prototype worked this morning, all was kinda easy. And now I feel more (like a very big difference) confident with the code of Nautilus, C, GTK+ and GObject.

Here’s the results



It’s still a very early prototype, since the port to GAction is not completed. I think I have 40% of the port done. And I didn’t erased all the code that now it’s not necesary. But with a prototype working and the difficult edges solved, that doesn’t worry me at all.

Work to be done is:

* Complete the port to GAction, porting also all menus.

* Refactor to make more sense now with the current workflow of menus and actions.

* Create the public API to allow extensions to extend the menus. Luckily I was thinking on that when creating the API to merge the menus inside Nautilus, so the method will be more or less the same.

* And last but not least, make sure any regression is known (this is kinda complicated due to the possibly code paths and supported tools of Nautilus)

Hope you like the work!

PD: Work is being done in wip/gaction but please, don’t look at the code yet =)

42 thoughts on “Development of Nautilus – Popovers, port to GAction and more

    1. Your comment looks not so convinced =P I guess you don’t like some things. Yeah, me neither.
      For example separators between the firts row of icons and the next one, spacing problems between icons, shape of icons, not having a GtkSlider for the zoom, etc etc. But it’s something I will look into (not sure if solvable currently).

  1. You really really want to out all the GMenuModels at the nautilus-application level. Basically you have one single model shared by all the windows, while the GActions are per window. Otherwise things will break in unexpected ways

    1. I had that advice from you in the process of doing it, and I tested it in any way I could imagine, but couldnt see the problem at all. I’ll reach you tomorrow so you can help me to understand why =)

      1. There are a few reasons for this:
        * some menus are per app (e.g. the app menu) and you want a unified way to deal with them
        * GtkApplication has support to magically loading a file called menus.ui from the application resources so that you do not need to do things manually
        * other reasons I now do not recall that desrt told us 😛

  2. Will the icon view with selection mode be implemented in this cycle ? thats would be very welcome for touchscreen users

  3. Why oh why do you people insist on making a single mouse action now take two or more?

    Please stop this madness.

    One could go back and forth bewteen views with a single click but now you are moving it to an addition level. Why?

    1. In the same way we have New Folder in a menu or Select All in a menu. One could argue: why do I have to do two clicks to create a folder? why not an icon to create a new folder in the toolbar? Then if we follow that for every menu item we end with a toolbar that doesnt make sense at all. So now the design try to group those actions in a way one could expect them to be based on the related action they do.
      The view change in buttons directly in the toolbar was something outside the menu when it should be inside, like the Sort menu item and all the other items. And now we solved that issue =)

      Probably a designer can explain it better.

      1. The solution, would be to do as Firefox. Nothing by default, but allow users the ability to configure as they wish. So you could customize the headerbar to add icons / actions of interest.

      2. I see your point, and I have arguments in favour and against. if a patch is done in that matter I’ll be neutral, but I wouldn’t do it for the sake of doing it (hope my words are not rude, sorry if so). I didnt see a lot of applications doing that solution except firefox. But I’m not the maintainer, so it’s not my call.

  4. I kind of agree with George.. I like having icon and list view on the toolbar.. I wouldn’t mind having Open New Tab on the toolbar either. Having things accessible in a single click is better than digging through menus, I have nothing against having them in menus but they make sense on the toolbar.

    Also bring back split pane view, please.. 🙂

    1. But then other people will ask for other icons. It’s a not end. That’s why we have designers who try to fullfill most of cases and have still sense on the UI.
      Sorry, I’m not sure pane view is in my priorities. tbh, I never used that and I kinda forgot what it was like.

    1. yes I guess. I still didnt look into it, but I won’t port all extension nautilus could have. I will port one to do an example with the new API and let extension authors port their extensions.
      Of course it can be exceptions tho, we will see.

  5. Any hope of ever getting the split view back (or at least a plug-in system that’s powerful enough to allow for implementing it as a plug-in)? Ever since split view was gutted I’ve hardly ever used nautilus, because it’s just too cumbersome for the use cases I previously used it for.

    1. It’s not in the designs for now. I guess you can emulate that having two windows, if I remember well what the split view was.

      1. Split view is two file panes side by side, like this:

        Split view is used to *avoid* having two windows side by side. For example, if you move first window, you don’t have to move a second window. Positioning windows is a rather cumbersome task in floating window managers.

      2. Thanks for the screenshot. And whats the problem with using two windows? It’s just dragging it to a side to reposition or use shorcuts, I guess the same as having an option for a split view.
        In my personal opinion, I don’t like it at all, and the design gets more complicated in that way. I think others workflow can be better.
        To be honest that screenshot just convinced me about that being a bad idea.

      3. Well, with two windows you end up with an extra side pane, you cannot fullscreen the application, etc.

  6. Wow, looks awesome!
    I really look forward to GNOME and GTK+ 3.16!

    However I have a suggestion for the v-shaped icon that allows to change views: wouldn’t it be better if it updated to actually represent the current view mode (list view or icon view) otherwise it is no really descriptive…

    Idea: what do you think if view mode toggled between icon view and list view when clicking/tapping on it, and it provided the options to customise the view (ordering, size, etc) by pressing and holding. This way people wouldn’t have to dig through menus to change the view mode. However, I don’t know if people would find out that they can customise the view with a press and hold on the button, or if it is feasible.

    Anyway, I think these designs you presented look way better than the current ones, great job!

    1. The first idea, is actually what designers want, simply I didnt implement it yet.
      For the second one, I think it’s too much difficult to discover that.
      Thanks! =)

      1. Yes, that’s what I thought!
        Anyway, I think I can afford clicking twice to change the view mode… it’s not like i’m changing it every 30 seconds… 😛

        Keep up with the good work 🙂

  7. Why is there a “New Tab” option in the app menu? That doesn’t seem right, app menu actions are supposed to apply changes globally, to all instances of the application. “Sidebar” seems questionable too, I would expect a sidebar toggle to work on a per-window basis, not globally, but I guess that’s a matter of design. (IMHO app menus should be scrapped entirely, or maybe reserved for window manager actions, but that’s off-topic.)

    1. Hi Emmanuel,
      I’m aware of that patch, I read the code a few days ago, and could be really cool to have it. But I think better port to GAction first and then that patch will be even better with the new structure.
      I though that we can work together in that patch. You already did the most difficult part, I could help with the port to gaction and try to polish those hard edges you talked about in the email.
      Reach me in irc as csoriano and we can talk =)

      Thanks for the work btw!

      1. great to hear at least someone went through it 🙂
        well i’m available if you need anything. IRC i think won’t work for me too much, timezone differences and so on. You have my email, I’d like to help if it makes sense. If you think it makes sense to get the gaction part in first, no problem. Let me know when it’s done and I can sync my code at that point, and even finish the listview part at that point, if you want.

        BTW sorry I didn’t congratulate you on your work. It looks great, happy to see such changes coming up, all in the right direction! I was just a bit frustrated by the lack of feedback I guess.

      2. I completely understand your frustration. But actually a few people (some gnome developers) reached me about your patch. I guess we failed at the point of actually telling to you that we apreciated it and we were excited about it figuring out who could help.

  8. Otherwise I prefer the current nautilus look for the sorting set-up (by name, by modification date..). All the radio buttons drawn on the right make it look very overloaded to me. On the nautilus 3.10 that I currently use the labels are a little offset to the right and the current sort only has a circle on its left indicating it’s the active one. Much more “light”.

    1. That is automatic and you can’t control it directly if you use GMenu directly with gtk_popover_new_from_model. But things are going to change soon and allow to use some widgetry in the menus, so that will look nicer soon, although the radio buttons being like that is a design decisions that designers were not happy to do, but necessary. Hope they find a way to have a lighter radio button.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: