Nautilus port to GAction, GMenu, and Popovers – Penultimate last step

So,

Finally I have all working and change as per the mockup in https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/nautilus/nautilus-menus.png

The positioning and size of icons are also changed to https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/nautilus/nautilus-next/grid-zoom-levels.png and https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/nautilus/nautilus-next/list-zoom-levels.png

Pictures

12
3

So, how much change is it?

The main patch touch 24 files, a clean up of -6210 lines of code, and added +2802

For me the most important part was deleting 6000 lines of code. Nautilus was using lot of legacy code, codified in an intricate way. Cleaning up those lines makes the maintenance of the application a lot more pleasure, and a little more smarter.

So what is the work still needed?

Basically, make sure I deleted all the legacy code and make sure every case is still took into account now with less lot code. Hopefully next week I will have a patch ready to review. I guess the review part will be a little long, since there’s new ideas that probably reviewers will argue.

After that, create the new API for extensions and make extensions work.

Hope you like the new changes in nautilus!

Advertisements

36 thoughts on “Nautilus port to GAction, GMenu, and Popovers – Penultimate last step

    1. I know gtk allows that at some point, and I don’t see any problem (with the port of the toolbar to .ui files in wip/gaction) to have it like you want. But I don’t have time to look at it right now =(
      Try ask in IRC maybe?

  1. Thanks for the great work. Nautilus needed that. While, removing 6000+ lines of legacy code is a major milestone in Nautilus’ development, IMHO…, I also hope to see a bit more work in this cycle towards adding some features in nautilus like the typeahead improvements as well as the path bar improvements.

    1. For me, new code/features comes after the current one is clean and updated. If not is just adding more burden…
      Btw, what are the pathbar improvements?

      1. The return of Typeahead-File-Navigation would return Nautilus into the league of high-value file-browsers. It is a drama since 3.6, the keyboard navigation through the search is a slow and underministic pain.

        It is known as Typeahead-Find, but it is not about finding your searching anyway, it fast selecting and browsing.

      2. The return of Typeahead-File-Navigation would return Nautilus into the league of high-value file-browsers. It is a drama since 3.6, the keyboard navigation through the search is a slow and underministic pain.

        It is known as Typeahead-Find, but it is not about finding your searching anyway, it fast selecting and browsing.

        I don’t think theres a league like that, or that option makes it inside or outside but the general feeling.
        Said that, it’s my personal priority for 3.16 to find a better solution for this use case. Not that I care at all for my personal use, but I completely understand those people that complaint in this specific case.

      3. ThanksSaid that, it’s my personal priority for 3.16 to find a better solution for this use case. Not that I care at all for my personal use, but I completely understand those people that complaint in this specific case.

        Thank you 🙂

  2. the first picture of the post have thumbnail of 2.png but point to 3.png.

    also in the first picture, isn’t better to say “sort by…” instead of just “sort”?

    Anyway thanks for your great work!

  3. It’s probably too late… I often change between list/icon view .. it would be really good if these could remain on the toolbar.

    Alternately … allow right clicking on items and select those to be docked on the toolbar – so; as in web browsers – power users can keep certain buttons on the toolbar, while everyone else gets the minimal interface.

    1. Personally I’m not convinced about modifying the UI based on the user, seeing a bloated Nautilus wont be good for any party I think… Working good for all users should be out of the box.
      Anyway, I can’t imagine a “power user” saying: nice! now I can select all items with a button in the toolbars. No more ctrl + a.
      If the user care that much, it can use shorcuts, and I made sure I didn’t deleted any of them…

      1. That was what Joel said about the Microsoft toolbar. I could not disagree strongly enough. For that use case I always and immediately put the equation editor on the toolbar for Microsoft Word. I teach math, I use the equation editor more than I use bold. But how many people insert an equation as often as I do? 0.5% of the population? Less? And frankly some users, like me, prefer to use the mouse than memorize shortcuts. I simply do not agree that you can create an interface that is ideal for all users, the use cases are simply too divergent.

        (From now on it’s Carlos Soriano)
        I don’t have idea how to reply to your comment (seems it is a limit of levels) so I edit yours.
        So, I don’t know who is Joel, but ok. Yes, as you said your use case is probably not common. But we try is cover the most common use cases for the most part of users.
        What to do with the uncommon use cases of the less part of users? Well, I guess there’s three ways.
        1- Dynamic UI. This can bloated the view and also make the application to actually behaves differently for different users, making it more complex (a deployment can be different than what you have in your home just because the admin likes that way instead of the default one, so not always it makes the user experience better). Also, maintainability and design burden.
        2- Shorcuts/other ways. This sounds reasonable, don’t bloat the view and every deployment of the application has the same behavior. Downside is that you have to do two cliks or use shorcuts instead of the mouse, but still your uncommon use case is covered.
        3- Trade offs. Just not giving that option and let the user find another more suited application or live with it. Sometimes for colliding interest you have to make a decision and sadly since you can’t do the UI for every use case and user in the world, you just have to do a sacrifice for the benefit of more people.

        So as long as I can, I would go with the lesser evil of the options, shortcuts/other ways. Although I already took some little trade offs, since it was colliding interests or technical limitations and we have to move forward and don’t be very stuck.

      2. That’s right! Using the keyboard for seasoned user is always faster than the mouse. The balance between a well-known set of shortscuts and a unbloated UI must be kept.

        Sadly some shortcuts of Nautilus could be now only discovered through knowledge of conventions (Probably F2 or Strg+R rename a file?) or a look into the help (which documents F2 as solution). In case of “Rename” the shortcut isn’t anymore “teached” through the UI, because we have no classic menu-bar.

  4. It used to be possible to zoom the previews/icons to extremely large sizes. This obviated the need for a separate image browser. Dunno why it needs to be limited to 128px now.

      1. I don’t mean image viewer. I mean the ability to make the thumbnail/preview lager than 128px. Why not allow to zoom more? To, e.g. 512px?

        If I want to copy images around, sort, select, etc, then having larger previews can be very useful.

        Don’t call it an image browser, call it a regression in feature in Nautilus.

    1. So answering your last comment (seems I can’t reply to your reply).

      I don’t mean image viewer. I mean the ability to make the thumbnail/preview lager than 128px. Why not allow to zoom more? To, e.g. 512px?

      Because it’s barely unusable even in 1920×1080 screens, only one thumbnail per row on half tiled (which I guess is how you see and move files). This needs other solution.

      Don’t call it an image browser, call it a regression in feature in Nautilus.

      Be careful with that statement, it is subjective and can be seen in different angles. If I personally feel that having 512px thumbnails is an error, it’s not a regression, but a fix. And for me it is a fix.
      I agree on finding a solution for this use case thought, but not the “solution” we have right now.

      1. But zooming is an action done by the user. If the user wants to zoom more (because he just needs 1 or two columns per screen, or he’s got the resolution) then he can. I can zoom my word processor document to extreme levels if I need to.

        This idea “nobody ever needs that” is dangerous.

    2. But zooming is an action done by the user. If the user wants to zoom more (because he just needs 1 or two columns per screen, or he’s got the resolution) then he can. I can zoom my word processor document to extreme levels if I need to.
      This idea “nobody ever needs that” is dangerous.

      Again, this is subjective. Probably an app developer (i.e. nautilus developer) won’t add a web browser and a game inside nautilus because “someone could need that and it’s dangerous thinking the opposite”.
      edit: The example is a little exaggerated, sorry for that, but you get my point =)
      So we have use cases, and we need solutions. That’s the goal. The goals are not the tools themselves, i.e. keep the web browser and the game in nautilus just because.
      That’s my personal vision. I’m happy to hear others visions of course, is the way we learn and change. But in this case I would need something more specific, i.e. use cases, pictures, why not other solutions, proposals, etc.

  5. Did I ready it right, that there will be an API for third party plugins for Nautilus? Where can I find more information about that?

  6. Quick design idea: in the mockup I notice “Open with ” (a secondary app)…. a really solid choice for the secondary app would be “Most Recently Used” (for that file type), as this is more often than not the app you want to use.

  7. A query on different topic , my brother and i use shared internet connection, he uses Windows 7 and i use ArchLinux and Windows seems to have higher priority in bandwidth allocation than Linux. Any idea?

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s