Hi,
It has been long time without a blog post from my side.
So we know Nautilus has a fame of being a little controversial, and is one of the most used Gnome applications given that is used in Ubuntu and in most of the distros as the default file manager even if they don’t use much Gnome apps.
We, as always, made some changes trying to make Nautilus modern and a more enjoyable experience to use, between the design team and the Nautilus developers. That requires lot of changes, and of course the path to achieve that is not easy, and some changes doesn’t make much sense without the others, but we need to do it step by step. So sometimes changes feel a little out of place, even if at the end of what we plan for nautilus, they will make it much better.
Sometimes, we do changes without being sure about if it or not, but we need to try them so we make them and we wait for users/developers/designers using the development version to provide feedback. The problem is that not a lot of users are testing the development version, and therefore we get the feedback then the release is already out and we cannot make UI changes.
Recently, some colleagues told me that some changes will make people angry if we don’t explain them, and my answer was that I didn’t saw those users at all, and that for me or for my close people they think the changes are fine. Which obviously is a problem =)
On the other hand, I heard some users that complain that we (as Gnome) don’t listen. So better facts than words:
- Users said that the items in the list view now are too big so they can’t take a quick look at files. We changed it: https://git.gnome.org/browse/nautilus/commit/?id=017561649ac1013b9d7a6f7e473a6061b2f176fb
- Users said that changing the F5 shortcut was disruptive. We reverted it: https://git.gnome.org/browse/nautilus/commit/?id=b3d37f7fe1b37e1594fb76edbbbc575858faf5e8
- Users complained that the slider doesn’t save the zoom setting, even if have been like that for 15 years. We changed it: https://git.gnome.org/browse/nautilus/commit/?id=986eafd989bdaf8ad003a61e2ed0fa8d21dab87b
- Users said that they wanted to open multiple files with a different app. We changed it https://git.gnome.org/browse/nautilus/commit/?id=bac36a5c59b0fd8f56d96025eb326f3d30f24f5f
But seems we don’t communicate well enough when we do good or bad, and people is loud when something is bad, not when something is good, so we only heard the bad things about it =)
So colleagues ask me to do a better job communicating changes in nautilus, so here we are, let’s bring some light to the development of Nautilus:
Here is what we plan for the next two releases (nothings is settled, and is mostly my ideal TODO list to keep control of nautilus ideas): https://wiki.gnome.org/Apps/Nautilus/Roadmap
Here is the mockups for Nautilus, this is the final result all we want to achieve (as before, nothing is settled and things change radically): https://github.com/gnome-design-team/gnome-mockups/tree/master/nautilus/nautilus-next
Here are the specific bugs/anoyements/complains I want to take care for 3.18 (that means, either solve them or take a decision if it is not a bug or what): https://bugzilla.gnome.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=26940&product=nautilus&target_milestone=3.18
I’m adding new ones and fixing them every few days, so keep it as a bookmark in your browser =P
You can change the milestone to 3.16 to see what bugs I want to fix or take a decision for the stable version as well.
Enhancement which I think are cool to have usually go to milestone=future, but seems there were already a few there, so I’m not following all of them, just a few I added.
In the 3.18 list you can see one that I’m trying to fix now because of latest users feedback, the default zoom in the icon view, which some users found them too big.
So what changes we did lately on the development version that you would be interested on?
We added a dialog for creating new folders as presented in: https://github.com/gnome-design-team/gnome-mockups/blob/master/nautilus/nautilus-next/create-folder-wires.png by the awesome Allan.
We think is a good change since it provides feedback, like the file already exists, the file name is invalid, etc.,instead of what was happening before that is: you create a folder, put a name,and if the name is invalid or already in use a big warning dialog opens and cancels all the operation! That was….pretty bad. Also, the New Folder dialog is usable on touch. Here is the commit https://git.gnome.org/browse/nautilus/commit/?id=6ae3384aa4a0cba83ff803418fb08054980027d8 .
So thinking in the same way we did the same for renaming files https://git.gnome.org/browse/nautilus/commit/?id=420423d12a13f708f60b20d65e1f3b1aa2e9d7ff , and now you will get a dialog when renaming files and you will get feedback if the name is not adequate. This change doesn’t involve any more clicks or keyboard changes, so everything works as before, but instead inline, it opens a dialog for feedback and to be touch capable.
Hope now it’s clearer how we work with Nautilus and where are we looking to go.
Hope you enjoy our work! 🙂
PD: English corrections please, very welcome, sometimes I don’t know how to say a sentence better, and I’m looking forward to learn.
And since this is my personal blog, a personal thing. But I recommend to read it if you want to convince me personally to make a change that you think is important for you (but you could convince a different maintainer anyway):
For Bugzilla, please: if you don’t have anything very valuable and logical and calm to add, don’t do it! It will just make us to lose our willing to fix it and we will just ignore it if the discussion goes too far, and I really want to fix them, so please, let me fix them. But feedback with use cases, pictures, comparatives, etc. are very welcome, and are the kind of thing that will turn a discussion from “not going to change” to a “oh, you are right… we will change it” as happened with the changes I listed previously.
Lately I had to warn two users because of insults in Bugzilla. I want to make it clear, and only talking personally (since most of the people are more flexible in that topic than me), any insult to a colleague, etc. or bad behavior and I will stop reading at that precise moment and ignore you for further interaction, warning the admin to take care about it. I can’t stand if a person that I don’t know on the street approaches and insult me or my colleague, so I don’t think I have to stand it on Bugzilla neither. I want everyone to feel welcome in our community and not afraid because of those people behaviors. We are not in a bar with 4 beers with our close friends where we insult each other every 3 words (who doesn’t? 😉 ), we are working in a community with different cultures, thoughts, and ways of life; so we have to find the common factor between all the people. And that involves no insults and good behavior.
csorianognome.wordpress.com 
Hello!
Thanks for communication before things are finally changed! Good approach!
My very first idea:
Please don’t remove control+r, this is the default action to reload on Nautilus, Epiphany and Firefox and many other applications. Instead add F5 as well, so we can just use both, which is a common practice:
+ nautilus_application_add_accelerator (app, “win.reload”, “r”);
+ nautilus_application_add_accelerator (app, “win.reload”, “F5”);
Second idea:
You change the rename dialog? Is it a modal dialog, or it is attached to the top-right corner like the new folder pop-over? The later would be far more better, because a modal-dialog cannot be moved *ouch* and maybe covers already existing file-names *double ouch*.
Third idea:
Add a item to the menu to create a empty file. Nautilus currently cannot just create a file and it the major feature of a file browser to create, delete, move, copy or rename files and folders.
Currently we have to use a template as workaround, which is really ugly and must be known by the user and therefore you need the template folder even if you don’t use it. Which is just a mess.
Thank you! I appreciate your work!
By the way, the new designs look good and it a seldom case the I’m eager to get them.
Hello,
Thanks for your feedback and actually read the commit and the code =)
For 1:
One thing I wanted is have a single shortcut for each action. But seems users use both of those 60% 40%, so probably I will need to enable both as you said. The code is not as simple as you post, but more or less =)
For 2:
It’s a modal dialog, and it provides feedback is a name already exists, so is fine. But we are thinking about using a popover instead to be less “brain focus loss” disruptive.
For 3:
It’s true that for Templates you need to know it, and a folder just there if you only use it for text files could be too much. But it’s a standard, and I think creating new types of files doesn’t correspond at all to the File Manager. For example, why text files and not blender files? Why someone that use plain text files has more importance that one that creates blender files?.
I wonder if what we could do is show clearer what the templates folder is in some manner (like a initial nautilus tutorial or so maybe?)
But one thing is true, this is a controversial topic, so therefore we need to think a solution/trade off for us all.
Cheers!
Thanks for your answer!
For 1:
I suspected that you can’t use the differenct shortcuts easily for the same action. I hope you can allow usage of both shortcuts.
For 2:
Popover like the “new directory” dialog sounds really nice and consistent. Especially this would allow to see that there is already “001.jpeg”, “002.jpeg” and “004.jpeg” so “003.jpeg” is free. On my mind is not just the error message, but also the affordance provided through Nautilus to see the existing files.
For 3:
The word “controversial” is so true.
Nautilus is a generic file manager, create, modify, delete,move or copy files and directories. I don’t want create a special text file. Just create plain file, no special semantic. It is up to the user to add “behaviour” through the filename or extension.
Your example with a file for Blender is correct and negative. For a positive example I just relate to my working behaviour, I create a file and with a name and extension like “*.h, *.hpp, *.c, *.cpp, *.txt or *.conf”. I use a file browser pretty much like “touch”, create that file and let me store – later – some bytes into it.
I don’t create “Documents” therefore I don’t rely on the howl “Templates” thing.
Thanks
Bye
Thank you for this blogpost, now I finally know what’s going on. 🙂
For 2:
Below hoschi has a really good argument: you sometimes look at existing filenames for reason other than avoiding duplicates.
For 3:
I think you are right: the Templates folder is a correct solution. Simple and easily extensible. I use it even though I have only 2 templates in it: an empty file and a bash script. If people don’t like this folder to clutter their $HOME, they can hide it with a .hidden file. I do this. (But I admit that .hidden file is hardly discoverable.)
And one thing that bothers me: why does the undo popup in Nautilus look so alien? Like it wasn’t a part of Adwaita at all. I’m sorry to say it, but I just find it ugly. 😉 Personally I would like it to look like Gedit’s “Do you want to reload the file?” bar and Nautilus’ “Restore Files/Empty Trash” bar. These widgets IMHO look a lot better and definitely more native.
I expect Ctrl+R to refresh too. I would never have thought to try F5.
Yeah, seems there are more people like you and people thinking the opossite. Not sure what to do if allow both (not a big deal… it doesn’t even worth that much discussion =)) or wait until we have the shortcuts overlay from gtk for 3.18
Intetesting, I never knew about Ctrl+R until now, F5 has always been the standard refresh button to me.
The only application I can remember which uses *only* F5 was the old Internet Exploder from a lost company named Micro$oft. Shudder…
Next step: removing the tooltip kind of text that comes on the bottom of file list… It says something like “filename (size)” by default. Ok, ok, but it comes when I hover the mouse on top of a line that already says “filename size etc”. It provides no extra value whatsoever.
ALSO, when you are attempting to select the line on the very bottom, when the list scrolls already, this motherfucker comes always on top of the line you are attempting to select. You have to kind of move your mouse around it, hoping to find at least 1×1 pixel sized part that hits the line underneath the tooltip kind of popup text.
This has always been around on Gnome 3, and apparently no one cares about usability around here. That part of Nautilus is one of THE largest usability brainfarts I have seen in the last a few years. It’s pretty much legendary already.
I’m not sure if you read my last comment. I won’t allow statements like “apparently no one cares about usability around here”.
Also, what I actually think is you didn’t read the post at all. It’s clear in the roadmap I posted that we will remove the float bar for 3.18.
So if I made the effort for a better communication, I expect the same effort to read at least if you plan to have a voice here.
I did a mistake. I referenced my last comment that talks about insults when you didn’t insult at all and some people made me aware of my mistake, sorry for that.
What I wanted to say in my previous comment is: This is my personal blog and I don’t want to deal with empty statements from someone who seems didn’t read my post or at least the links I posted.
Only constructive statements please. It can be something like: In this bug report I didn’t feel listened, I did this this and that and read how gnome bugzilla etiquete and reach people on IRC in a constructive way and I felt not listened at all. Then we can take a look what happened and try to fix it for future and for everyone, since precisely we want to avoid people making an effort, being good, and not feeling welcome.
Getting rid of the float bar makes sense for list view but for grid view it is a handy feature that I’d miss if it was gone.
We will provide whatever the status bar provides in smtarter ways
IDK about list view, but in grid view it’s really useful to quickly see the size of a file.
Really good to communicating these changes 🙂
I have double-click mapped to ‘roll up’ windows, and this seems to no-longer work with the new style windows that nautilus uses.
what does that means? “roll up”??
I think he meant hiding the window body so you have only the window’s titlebar
Roll up, is something macos ’till 9 used to have. It hides the thole window body but the titlebar.
Ah okay. Sounds not very useful at first though…
Set window effect to shade in dconf for mutter, then double click titlebars of some windows
Just so you know, Nautilus is crap, I just can’t stand it!
It was good back at the day where you could’ve have per directory settings e.g. “sort order” and “zoom level” – once again – p e r d i r e c t o r y.
That is also probably what your critics meant when they complained that the slider doesn’t save the zoom setting.
Besides that, removing all types of right click menu options and scattering them all around some infrequent settings buttons was a bad move too – to say the least.
Oh, and how about changing well proven conventions which actually contribute to users work-flow at every whim you feel (which happens way too often BTW) and not leaving them at least the option to revert things back in case they aren’t comply with your standards – just saying, don’t be surprised users are left with bad taste in their mouth afterwards.
To demonstrate why it’s more efficient, imagine you have a Videos directory filled with dozens of video files – when you want to select a video to watch, it’s hard to find specific one among that mess you have there. Alas! you can sort the folder by date, increase the zoom level so you could see the thumbnails – and voila, you can easily find what you want.
On the other side of the road, you also have plenty of other directories filled with all kind of files with only mimes and no thumbnails – in this case high zoom level would only hinder your search, since the bigger the icons are the less can be squeezed per row. Add to that you have no clue when each of these files was generated / modified and you’ll conclude that sort by modification is useless in this case, on the hand sort by name might not be.
P.S. what feature are you planning to drop (without warrant) next? let me guess, perhaps you should get rid of tabs, after all what purpose do they serve when you can simply open another window instead – GNOME is all about minimalism don’t you know…
P.P.S. My deepest apologies for the harsh criticism, yet sometimes I feel you GNOMErs deserve a slap on the face to remind you that first and foremost you are part of a community and not some closed source corporation driven by the lust for money, sheesh… may it be and this would serve as your wake up call
This is a perfect example of bad feedback, something like this would surelly be not listened to and as a bonus can demotivate people willing to spend their time on the application. Thanks for posting.
It’s «bad feedback» because you don’t like it, of course.
No. It’s bad feedback because is just an empty rant, threaten prople and is disrecpecful towards people.
Let’s see what happens if you go walking on the street, someone you don’t know approaches you and slaps you. Will you thank him for it?
And this doesn’t have any discussion for me (so don’t try it).
… maybe your father should have beaten you more …
Sorry for that. But I really got angry, when I read: “yet sometimes I feel you GNOMErs deserve a slap on the face …”
This. Even though it could be written more eloquently to say the least.
Hi,
Thank you for your work and your reports, it’s really appreciated!
Sadly, our FOSS community isn’t asshole free.
Not a nautilus-related comment. Just wanted to say that a blog is not a mailing list, and that you can actually create links with meaningful names, instead of throwing all the raw URLs…
It’s intentional, I strongly prefer to see raw urls, and I don’t like when people write something like:
Here(this is a link) are (this is another link) some (another one) examples (yep another one)…
I feel it confusing and I would like to know what I’m clicking on.
I do the same in the gnome wiki pages I created.
You don’t like the Schneier style? 😛
Personally I always hover on the links before I click them to see where they point. But this might be a problem on mobile though…
I’m mostly happy with Nautilus there is not much to criticize – but I have two wishes since years, please add those features 🙂
First idea: possibility to hide less used items from the left “navigation bar”
Nautilus 3.16.1 on Fedora shows in the navbar (don’t know the right name) items I – and I thing many others – don’t use very frequently.
For example I mostly never click on the ‘Computer’, ‘Browse Network’ or ‘Connect to Server’ buttons. Most times I run Nautilus on a non-maximized window, therefore I would like to replace some navbar entries with bookmarks.
I also mostly never use the ‘Recent’ button and would like to hide it as well (other users might use the button a lot).
My dream navbar would have no separators and look like this:
* Place buttons (Home, Documents…)
* Bookmarks
* Trash
* Mounted external devices, if any
Second idea: middle mouse click to close tabs
All applications allowing to create tabs can close them by a middle-mouse click, except GNOME apps. This “non-default” behaviour annoys me a lot and I can’t quite understand why GNOME has to do it differently. All Browser, IDEs, [what ever ships with tabs] allows middle-clicking to close tabs, Nautilus should too. I would really like to know the argument why GNOME does the tab thing differently.
The last years Nautilus has evolved nicely, thanks for all the hard work to make Nautilus a better file manager!
First idea: Yep! We are working on that and it’s due for 3.18. Take a look how much simpler is the sidebar in the mockups on github I posted in the post.
Second idea: I agree, wondering why it is not like that. Can you report a bug report on Nautilus bugzilla as a enhancement? I will ask designers why we don’t implement that on, say, epiphany (Web).
1. Nice, thanks so much
2. Bugreport already exists since years, but they rejected it, not a bug…
https://bugzilla.gnome.org/show_bug.cgi?id=558889
https://bugzilla.gnome.org/show_bug.cgi?id=458059
The following is only to the best of my knowledge.
The issue is a bit delicate it seems. It would be inconsistent to implement this for every app like we did with the close buttons for the tabs. (Yes, every app seems to handle closing by itself.) There is a constructive discussion at https://bugzilla.gnome.org/show_bug.cgi?id=725123 for adding it to GtkNotebook which would be the ideal case, however it would first need an API for adding those close buttons (https://bugzilla.gnome.org/show_bug.cgi?id=705487) and an undo operation for this since closing is a destructive action and if we don’t have a “reopen last tab” like epiphany from the app side we need to have a general undo for GtkNotebook. (There have been some rants on some of the duplication bugs too.)
After all the first step to do this would be solving 705487 (close API for GtkNotebook) first but right now nobody seems to be interested enough in code reusability here. (No insult intended.)
Aah I see, I didn’t in all of those downbacks
First of all thanks for all your work.
2nd: do you have plans for including advanced tracker features in Nautilus?
Something like deep file search (ex. text “foo” in file bar.txt) or tags?
A way to add tags, and show all files with a specific tag in Nautilus would be really cool
tags and deep search is already there, would love to see it integrated in Gnome and in particular in Nautilus
Nico
No, was not planned because I didn’t know that! Sounds really cool!
Can you point me to some source?
https://wiki.gnome.org/Projects/Tracker/WhatIsTracker ? XD
I wondered, a few days ago, why Nautilus did not allow the search by tag, while we already had all the necessary 🙂
Nice, search on text of files looks like something we want for sure. Not sure why we didn’t do it before, I will ask.
nautilus search doesn’t have full text search and stuff like that since nobody ever implemented it, consider that basically no one was taking care of nautilus for a long time before Cosimo and then you.
when one creates/renames a folder sometimes the new foldername is related to other folder names within the current (project) folder. with the new create/rename folder dialogs you present, they seem to cover the current folder view. please consider an option so the content isn’t always covered and reading other foldernames stays possible. i like the looks however 🙂
Can you give an example? Because if it is the same I am thinking, there is a enhancement request similar to this that could actually work better with a dialog.
For example I have downloaded a file with a filename like oNhb5f64ha.jpg and I have renamed it to 2015-05-01_oNhb5f64ha.jpg. Then I download a second file: a7an234rbc.jpg and I click rename, because I want to do the same as with the first file. But then I forget which date format I used. Should it be 01_V_2015 or 05.01.15? I want to look at the first file, but the modal window is in the way, so I have to close it, remember the format, click rename again and hope I didn’t get the format wrong. If I could move the rename window away for a second, it would be better. (And it would be even better if I could rename inline as it always was done – then I could see both names and you could use an inline popup to tell me about illegal/duplicated names.)
BTW do you also warn about illegal names on FAT/NTFS drives? For example ‘:’ character in a filename is legal on ext4, but not on NTFS drive.
Oh and I just had the idea: you could put the rename/create dialog into a bar that’s part of the window, but doesn’t scroll with the content. See this: http://a.pomf.se/dygdug.png http://a.pomf.se/izhwch.png
I have a question abot that mockup for the nautilus menus that was linked to in the roadmap, https://github.com/gnome-design-team/gnome-mockups/blob/master/nautilus/nautilus-menus.png. Namely, the app menu has a “New tab” entry. Should that entry really be there? “New tab” is a per-window option, and the app menu is specifically intended to host menu entries that apply to every application window, not just the current one. I cannot think of any rationale for this. “New window” makes sense, but “New tab”?
Yeah was an error in the mock up. When I implement mock ups I always check with Allan, and modify some things.
For example:
– set as a wallpaper was not removed
– templates was not removed
– compress was not removed
– order of new tab/new window was changed to match firefox/chrome
That’s actually a reason that mock ups shouldnt be taken very seriously, but better receive feedback and notice (like you did) than nothing at all.
Thank you for your work.
Changing the default icon size was not obvious – before reading this post, I did not even realise there was a setting in preferences.
Now, before the change to default sizes, I had never needed to have a smaller default (on my large monitor, the new default is too big, though I suspect it would be right for a laptop.)
Anyway, thank you for your hard work. Nautilus is a good and useful app.
The only feature I “miss” is an overview screen that is in other file managers, but I understand that this is just duplicating the information that is already in the sidebar
Yeah that is what happened. So it made me aware of two problems:
– Settings are not obvious. I fixed it already.
– Default icon size could be too big. I’m currently discussing it with designers.
“The only feature I “miss” is an overview screen” can you give me a screenshot, example, or explain it better?
Maybe he meant a Windows style “My Computer” screen?
I can’t edit comments… -_-
I wanted to add that Nautilus has this, but very limited and not discoverable. (“computer:///”)
In general I’m quite happy with Nautilus; in particular I enjoy how you keep removing window “chrome” to let me focus on my files. Thanks!
My main issue is that the size of the “preview icon” of a file is not fixed. If I open my Pictures folder and go to the bottom (I do this quite a lot in my Dropbox folder as the bottom files are the most recently pictures uploaded from my phone), then the files are “jumping” all over the place because Nautilus is changing the size of all file icons (it seems to do this from the top, which imply that my view changes because icon size changes outside my view). This makes it very difficult to look at images in Nautilus. It’s quite easy to reproduce: just open a folder with many images and press “end” on your keyboard.
Yeah so annoying. Can you confirm it happens in 3.16 as well?
Also, this will be just fixed if not now with the rework of the views I plan for 3.20.
Sounds awesome! I’m still on 3.14 but this sounds line a great reason to update 🙂 Thanks!
I am a user, not a developer, and Ubuntu Gnome 15.04 is my preferred distro.
Communication and transparency are critical now-a-days to the success of a open-source project. Users, like myself, are still are still asking “why was compact view & dual plane removed?”. Without communication and feedback, users ‘vote with their feet’. I stumbled onto this blog post whilst searching for how to install Nemo.
Developers and General Users habit different areas of the internet. If a developer wants genuine feedback they must ask their questions in places where they will be heard by all.
Today’s world is a very stressed and superficial place. The anonymity of the internet gives people a platform for people to be genuine, and we all must pay the price for their freedom of speech. The ugliness of people’s comments is not a reflection on the internet but on society.
We make design decisions to clean up the UI and make it clear as well. I dislike how much things Windows file explorer and Finder have in their UI.
Yeah they habit different parts of the internet, normally what we try to do is real user testing, like any real software company. But since we are open, we can use internet a little, but I’m not going to spend more time writing and going to specific places to write it than developing code…
Yeah today world is stressed, that’s another reason why I use my freedom to skip any person that I consider a waste of time to deal with (even more if I don’t even know him/her!). Also, for me is clear. I won’t allow on internet what I would’t allow on the street. Is that simple for me.
If you didn’t figure out yet, installing Nemo should be easy, at least on Fedora/Ubuntu/Open Suse it’s in their supported apps. So go to the Software Center (like Ubuntu Software Center or Gnome Software in Fedora/Open Suse) and search for Nemo.
It’s always nice to have a fully written explanation of changes that might be happening in a project such as this where unclear text in a commit can, and has, lead to people jumping the gun. My only additive thing to really say is the mockups linked don’t include the ones from the breadcrumb design page: https://wiki.gnome.org/Design/OS/Breadcrumbs . These breadcrumb ones are quite a bit more recent than the nautilus-next and do modify the design proposed so I am wondering if that discussion involved you or if you had any plans of possibly including them in the greater plans for nautilus-next?
Yes, it’s in the roadmap (as you can see in the link I posted in the post) for 3.18 and I’m currently working on it.
I though they were in github as well tho
Not that I could see, all the images in the github with the breadcrumb bar have the center-aligned one. It’s good to hear that it’s being worked on, I wasn’t quite sure whether the roadmap entry covered what I was thinking about.
I can’t reply to the last one.
Right, the mockups are not in github and the roadmap says nothing about a rework on the UI. Good catch, I will fix it.
Thanks for paying attention.
@csoriano89
“Users said that the items in the list view now are too big so they can’t take a quick look at files. We changed it:”
Could you please do that for Grid view as well? Or has it already done? I could not verify because I do not use fedora rawhide.
And about that new dialog:
Sometimes I do not want to use any names. I just want to create 20 random folders (with mouse), use it & then dump it. So in that case if a user hit enter without putting a name, folder name should appear as Untitled Folder, Untitled Folder1…etc.Is this same here?
Also please add Disqus to this blog to login & comment.
Thanks.
Hi,
It’s one of my items marked for 3,16 to take a decision. I actually wrote this specific issue in the post saying what specific complain I’m taking care right now.
20 folders for dump them? Can’t see the real user case behind it. Can you explain further?
Disqus here? Can I do that? I would really like to =)
About the size of icons in the grid in 3.16. You say: “Users complained that the slider doesn’t save the zoom setting, even if have been like that for 15 years”. I think you can find a reason for people complainings and your answer about default zoom level there: they noticed the fact that changes weren’t saved because they *felt* the need to change the zoom level, which they didn’t before! My real problem it’s with the _minimum_ size. You are now providing 3 possible sizes, and the minimum one is still too big for me. Make more choices available please! Once you have a slider, why limiting it to 3 choices? when a user sees a slider, thinks to be able to move in a continuous range. Instead, they find 3 choices, the smaller of which is bigger than the previous default!!!
Hi, first: Thx for reaching out that way. I liked reading your blog-post.
Where can I find the bugzilla-issue for “Use GtkPathBar instead of NautilusPathbar” (A feature already planned and in progress for 3.18)?
I think, that https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/breadcrumbs/overflow1.png (Approach 1) is good, but I think that “…” in long folder names are problematic. Imagine folder names that start and end the same. I’ve seen that in owncloud, too. To be sure that I am in the right directory I need to go back to it’s parent and click again not knowing wether I was already in the correct subdirectory.
Besides, will CTRL+L still work to enter the path the old-fashion way?
Hi,
So I fixed it in the Roadmad, you have now the link there =)
Yes, the old fashion path is not going to dissapear.
Do you mean this Roadmap? https://wiki.gnome.org/Apps/Nautilus/Roadmap
yes
.. because there I cannot find the link to the bugzilla-issue.
There is no bugzilla issue, I just added the mockups link
Hi, great post, and I think this is very constructive approach!
Just a note, not directed at you personally, but maybe it helps understanding some of the “criticism”. It was a long time ago, but what turned me off personally from running testing builds and contributing on the bugtracker was the removal of keyboard navigation
in folders, replacing it with search. That change generated a lot of protest (and I’m sure a lot of it was not particularly constructive). But there was also great feedback, even while the
changes were in unstable. For example, see this mailing list thread:
https://mail.gnome.org/archives/nautilus-list/2012-August/msg00002.html
Now you can always say I’m just bitter for not getting it “my way” (type ahead was removed), but from the bug reports that followed I just got the impression that the feedback was basically
ignored, and with an attitude. As that mail describes (also see the replies), there are just different use cases for type ahead and search, and no way of “improving the search” is going to
be able to merge them into one. In the bug reports, that wasn’t really acknowledged by the people in charge (as I remember it). The way this change was pushed through despite there being a lot of (imho) good arguments against it turned me off from contributing. It definitely came off to me as “Gnome” not listening, and also that there is a handful of people in charge who just “decide” these things.
Same with this here (gtk, not nautilus):
https://bugzilla.gnome.org/show_bug.cgi?id=744205
OK, not the best bug title. But the complaint is valid (again, IMHO) and it’s totally brushed aside, and the reporter basically told they’re an idiot. That was reported during testing. The
change entered stable, and with 3.16 type navigation is gone from any gtk filechoosers. And – unless the current dir is indexed by tracker, search doesn’t work either. That means it is
completely broken outside of XDG dirs (unless you changed tracker defaults) and for anyone not running tracker at all, e.g. if they run gtk apps on other DEs. How that is not reverted as a
gigantic regression is beyond me. And I had some other itches which I looked up in the bug tracker, found something, and it was immediately clear that nothing is going to change the mind of
the persons in charge.
So, I’m still using Gnome, I think it does way more things right then wrong, and the amount of FUD and hatred thrown at it from the peanut gallery is unfair. But I do ask myself
“why should I even bother” with reporting bugs if they are handled the way the above are. Of course it is not always this way (as you have provided some examples to the contrary), but still.
Sorry for the wall of text.. Hope it provided some more respectful perspective from someone who doesn’t think that Gnome is literally satan but that changes are, sometimes, pushed through without listening.
Hi,
So lot of things here. Let’s try to go per parts:
– About type ahead: I don’t think “type ahead” per se is a good solution, and others solutions came to my mind. They are not implemented, so the current solution with tracker is half backed yes. But as I said in the post, sometimes we have to move forward on half baked changes for a better solution at the end. Maybe with this specific thing, the real solution is coming too late, and that creates the criticism since the current solution is not good enough. But errors happens as well… and I think now is better to go forward and improve it (as we plan for 3.18) than revert it.
– Gnome not listening and some people decide: Yes. And I always preferred to said it clear than lie behind. We decide, the community of contributors and developers, and ultimately maintainers. It’s not a democracy, and it shouldn’t be. Trust has to be gained, and more power on deciding relies on that person that contribute more time on the project.
Listening doesn’t mean accepting what you want. Listening means I want to hear what you have to say and I will take them into account. But ultimately we decide for what we think the best of the outcome in a big picture, and sometimes not for the best of that specific case.
I can understand the feeling of “I can’t change the person mind” in some bug reports. We as developers felt it with other developers, and I’m sure someone felt it with me. Sometimes the opinions are too different, and you cannot do anything about it.
Said that, some situations and changes could have been handled better with the user base (like the type ahead change, at least communicating with people like how I do it now). But that is the most difficult part… and I’m sure everyone tries to handle it as it can.
I appreciate your perspective, thanks for postin!
just to be clear – I totally understand that the people who do the work are the ones to decide, and giving feedback doesn’t entitle you to have stuff changed the way you like it. and in many cases, I am actually quite happy that the Gnome devs pushed things through against some rather trollish backslash, because many of those changes are what makes Gnome 3 great. and that not-so-great feedback also makes it more difficult to have constructive dialog, because I can understand that it wears one down and lowers the willingness to accommodate requests. it’s tricky.
(on that specific keyboard browsing thing though – I still think it was a really bad idea to just yank it out. even though you might not like it personally, it was a really common use case, and there isn’t really any sensible replacement. someone even put in the money for a bounty to have it restored. that patch is carried in Ubuntu, and hopefully will continue to work… but I’m not holding my breath)
I had a lot of trouble accepting that you chose to replace type-ahead find without a “good” solution within 1-2 releases. I wish you had implemented some kind of dconf option to keep the old behavior until the new method is on par with the old one.
Still in gnome 3.14 I see some problems with the new search in nautilus (even though the new behavior came handy in a few cases). For example I’d like to see search results in the current folder first (and more prominently) than hits somewhere deep in the directory structure. Also sometimes it takes a bit of time (maybe ½ sec) until the first hit gets the focus so I can hit return to open the folder. Are these two issue things you have already on the radar/you consider valid use cases within your vision of nautilus?
As I said, some changes needa further changes to make sense. But if sone problem arises (no maintainer) or other problems, then you can’t do nothing but wait for a patch. Nautilus code is not easy and it’s old and not fresh and fun. (Althought for some reason I enjoy it)
Yes. Look at the search mockups. Still I would like something smarter instead of that as you said, but it will be a good short term solution
Tough thing, because even the mention of “search” and “type-ahead” makes me sad.
Definition:
“Type-Ahead-Find” or “Type-Ahead-Navigation”?
I prefer “Type-Ahead-Navigation” because it allows instant navgiation through known files and directories, with the keyboard. Secondary, as side effect it allows some kind poking around, which is a search aid.
Description:
The removal is actually the worst decission ever made, especially because Nautilus “Type-Ahead-Navigation” was even superior over the solution in Windows Explorer and MacOS Finder. Especially there was not “timeout” on typing and you could see what you have typed already in the bottom right corner.
The new search:
Basically it is a search, not a navigation and therefore not a replacement. The new search is slow (on a solid-state-drive) and clutters the screen with similiar named files somewhere down the path. This gets worse, when many files down the path get found slowly. So the results get added over time and move the screen content.
The other thing are half baked things:
On production software, new features could be added carefully, but shouldn’t never cause the removal of reliable and working features. Things don’t need become worse, to become better. Experimental or unstable features should be itself forked, instead of causing forks.
All the critic from many users where ignored on search and type-ahead, which made people really angry an lead to a ugly outrage on bugzilla.
Reading Type-Ahead-Navigation would bring Nautilus back to the league of superiour file-managers.
@csoriano89
I always wish that there were more icon sorting options when you right click on desktop (in env where nautilus is used to manage the desktop). Now that gnome tries to be more open to user voice, any chance that we can have Organize Desktop by {Name, Size, Date Modified, Item Type} implemented?
Hi,
We are not gonna spend effort on the desktop view. Quite the opposite, because we don’t want the desktop view at all, so no… don’t expect that to happen.
I just wanted to say that I really like the way all of you are going! Nautilus is always a very modern and up-to-date application which is just fun to use most of the time. Sometimes though some changes are a bit itchy at first but if you get used to them, the overall experience gets better.
(P.S.: I really love the new file deletion notification!)
thanks =D
I recently got a new MacBook as a work laptop and I’d like to run Arch Linux and Gnome on it, however the keyboard doesn’t have a few critical keys (Delete, PageUp/Down) so I’m unable to use the keyboard to do things like delete a file in Nautilus.
It would be really good to see all Gnome apps adopt a similar system to the Gnome Termainal to allow custom key bindings, but more importantly that system should be documented somewhere as *the* way to do things so that potential contributors can do the work and third parties can implement it in their own apps. There should be guidelines for these sorts of things, maybe even as part of the HIG? After all, it would allow humans to configure how they interact.
Your MacBook keyboard has exactly the same functionality other keyboards have. You need to use the Fn key to enable them — you need to use the Fn key on MacOS as well, anyway.
Delete = Fn + BackSpace
PageUp = Fn + Up arrow
PageDown = Fn + Down arrow
[Written to you on my Bluetooth wireless Apple keyboard on a MacBook Air, running Fedora 22 and GNOME]
Unfortunately it doesn’t. The drivers need updating as the Fn key on the new keyboard does not function.
Hi! The changes look good, I like them. Also the design of nautilus looks REALLY nice. Good job 🙂
There are two things though, which make nautilus unusable (I really mean it!) for me:
1. As others have said: The items in the left side panel can’t be changed. Bookmarks are only displayed on the bottom, but I want to be able to arrange everything myself (e. g. I don’t need a dedicated “Videos” folder).
2. No Compact View.
For the sidebar Allan and Carlos are working on improving it right now. The compact view was basically a work around for icon view problems, with the recent work done on the icon view (which will get addiotional love for 3.20 if not fore the next release) the icon layout is pretty much tighter and imho it’s already way way better than what was called compact view. Can you please explain why it was better for you than what 3.16 provides?
Compact View is necessary to view folders with a lot of files without the need to scroll. My problem with the icon view is that it cuts of filenames to soon and also doesn’t use the space efficiently. I’m still running 3.14, but from the screenshots I’ve seen so far this hasn’t been fixed in 3.16 either.
But it’s good to hear that the sidebar issues are being addressed 🙂
Hey, thanks for all the hard work.
Even now after a few versions, I still have users asking for dual panel. Any chance that we can have it back? I used to maintain a nautilus fork with dual panel some time ago but after a few versions just stop to work on it since source code was much different than official Nautilus.
Btw, since I am also a coder, how I can help with Nautilus? What distro/version you recommend to develop Nautilus/Gnome apps?
Thanks.
For dual panel do you mean the split view, right? In case you are, that was removed since it had tons of issue, which required lots of loves both codewise and designwise to bring it to the quality we wanted nautilus to be so (considering that at the time just one fearless hacker dared to touch nautilus codebase, not much differently from now tho…) the decision was to remove the feature and concentrate the forces on the rest. Also we felt that two windows side by side could somehow cope with the missing feature, considering gnome shell made it easy to do. I don’t think it would be reintroduced now anyway.
It did not have tons of issues (or at least not that I know of, and I was the author of the split view mode). And no, side-by-side is not a replacement.
Hi,
For me using Fedora for developing Gnome apps is the best advised. It’s sad that jhbuild, etc. doesn’t work that well on other distros (patches to do so very appreciated)
How can you help? If you are newcommer search for bugs in bugzilla with the gnome-love keyword. Here is the general wiki to build and contribute to any Gnome project http://wiki.gnome.org/GnomeLove
Can we have compact view back pretty please?
Not from my side at least
Is this where I should ask for thumbnail view mode in the firefox file picker?
NB: this means thumbnails for every file in the current folder, not just the highlighted file.
Maybe this is not the place, but it’s something we want to implement since 10 years ago. And my plan is to do it for 3.20 =)
*Please* leave in-place renaming at least as an option. Needlessly forcing a dialog on the user where it’s neither required nor requested is nothing but intrusive, annoying and ugly.
If you want to inform her that the name is already taken, just pack that into a popover while continuing the renaming and you’ve got zero disruption.
ּּIt’s much more sensible to have renaming and new folder creation separated into two variants each, one with and the other without dialog (shortcuts being, say, F2/S-F2 and C-S-N/Alt-S-N, maybe subject to aforementioned option).
I’d also suggest modelling said dialogs after the present search-as-you-type functionality, rather than mere “name already taken” feedback.
“Needlessly forcing a dialog on the user where it’s neither required nor requested is nothing but intrusive, annoying and ugly.”
Those statements are a little empty and based on personal opinion. As they are now, are not very valuable. i.e. I can say:
Needlessly forcing the user to use the inline renaming it’s neither required nor requested is nothing but crappy, annoying and ugly.
And as you can see, we are not going anywhere…
Instead, i.e. Lapo, one of the Gnome designers, raised some logical well defined points against the dialog for renaming (well, it’s true it is easier for him because he is an expert, of course) . And that’s why we are actually thinking on other variants, like a popover.
In any case, we won’t make it an option, since imho looks like a design decision of the app, not something for the preference dialog.
“I’d also suggest modelling said dialogs after the present search-as-you-type functionality, rather than mere “name already taken” feedback.”
This looks a little messy, maybe? What does it provides?
The search type functionality can be usefull if renaming a file to have a similar bame to another.
It might be worth making a mockup and seeing how it works when attempting to rename a lot of files (ok, maybe 10)…
Using the popover might make the flow a teeny bit longer (eyes have to move to top right to rename).
OTOH I can see how it can provide better feedback in the case of errors.
We could really use a web based mockup to he able to play with some of these ideas I reckon.
I second this. Creating new dialogs can have problems with focusing (especially when you have focus follows mouse enabled) and it seems like an overkill for such a simple task. On the other hand, a dialog would be great when the user tries to set a new name that already exists (it should have options 1) rename the new file 2) rename the old file 3) overwrite the old file – default being on 1)).
Would it be possible to have a feature that shows the drive space for each mounted partition/drive.
It could look something like this:
50 GB Volume — Total 50 GB — Used: 20 GB — %Free 60
Home — Total 80 GB — Used: 40 GB — %Free 50
Winos —- Total 150 GB — Used: 50 GB — %Free 67
yes, some designers wanted this. Can’t remember the problems, if they were technical, design problems, or just that no one showed up with a patch
the GTK3 “save as” dialog not fit in |024×700 (Compaq Mini) screens since GTK3.0 is ther a remmote possibility to make it fit the screen? because it cannot resize for some reason.
That’s a bug. Can you file it to the gtk+ product?
Great changes!! My only concern/suggestion is an ancient issue where the left/right margins in icon view are uneven, and not centered.
Would it be possible to make both margins flexible so that the icons are centered, as is in dolphin/explorer/finder? Right now the left margin is fixed, and the right just expands until a new column is formed.
Do you think we didn’t want that fixed since 10 years ago? =)
It’s a very annoying problem, and it’s because the code used on nautilus predates some gtk+ widgets like the GtkIconView. So you can imagine that Nautilus does everything on itself. That part of the code is the most complex one, and it’s the base of Nautilus, together with NautilusFile (this one is more or less fine).
What we are going to do is rework the views for 3.20. Basically my *only* goal for 3.20 is have a reworked icon view with GtkFlowBox, and make it good enough to be able to use it in the file chooser as well (yay!)
May you can consiser to use popovers all around and no dialogs.
Most information could be provided by, say, a right click, like file properties and actions on it with out a dialog.
Drives could selected to be opened by left click on its icon at side bar using a popover.
I don’t think popovers would be good to provide tons of information, but instead for something simple. Dialogs switch the context and you can concentrate on it, and that doesn’t happen with the popover.
To be honest, I just feel it could be wrong, but I don’t have strong points to back up it. Maybe a designer could bring some light here on both sides.
Imho popovers are mostly like dialogs, with the difference that are visually and proximitywise tied to the content, anyway, like dropdowns, positioning wrt screen edges needs to be considered. So popovers works nicelly when kinda small especially if the positioning varies.
Even with a stack switcher?
Stack switcher or not what matters is the size, if the whole thing gets very big it may defeat the purpose of using the popover at all, since if it covers most of the content the fact it’s linked to something may became irrelevant, see what I mean?
Great news for Nautilus File manager and great work from you guys!!! I believe that Nautilus has started taking a nice shape, in the concept “be simple but yet very powerful” . One thought though: In my personal opinion, the way GNOME and in near future Nautilus are dealing with selection of multiple items is very touch screen centered. For a person working on a desktop computer, with a mouse and a keyboard, selecting multiple items using the “ticking things” method is very frustrating. It actually takes much more time, especially for an experienced user who is used to using key combinations to get things done. Would it be possible to provide a “fallback” for desktop users, not only in Nautilus, but maybe in all Gnome Apps that use this feature?
Thank you very much in advance for your reply!
Hi,
So I’m going to answer from end to start:
No, we are not going to provide a fallback mode or something like that. We (at least me) want a single experience with the application, and make it simpler to develop and maintain, not harder. We want to have the best of the base functionality, not the “so so/okaish” of everything.
But, I agree that selection mode is controversial, and not in the sense of “I don’t like”, but in the actual sense that can make things more complicated for mouse users. That was happening in previous releases, but for example now gnome-photos implements rubberband for selection together with selection mode. So things are improving and still working on it.
One thing is clear to me, this specific change won’t make it to master (at least if I can decide) if the functionality is not in par with what we have now. That doesn’t mean that maybe the change introduced make you do rubberband with the right click mouse, that’s fine (maybe debatable), but those funcionalities must exists.
It looks dumbed down. It looks like an Android app. It looks like it made for consumption not production. It feels like its made for a phone or tablet, not for a desktop.
Does this has something to do to the post? Your comments looks so general and nothing to do with comunicating the recent changes or so. Keep it like if you are posting on a bug report (detailed, some effort,etc) , if not, use your personal blog.
Being able to right click a column header in the details view and select columns would be really useful.. though maybe only in the context of per directory settings:
At the moment I never bother changing columns in nautilus, while on windows I show stuff like Artist in dirs of music, etc
I tend to view directories like Downloads or with source code with details, dirs with pictures or videos Ill usually zoom in a bit on the icon view.
My workflow probably isnt super unusual, any chance of this in future nautilus.
I didnt understand your comment, sorry
Edit: So it will help me if you explain more direct or with screenshots or something.
I just realised the feature I was asking for actually does exist now, so don’t worry (was commenting on my phone).
The other part is per directory preferences – some folders work better in particular views, if I understand things righty then this is/has been removed.
I’m on Ubuntu so don’t have the standard nautilus.
I would use jhbuild, but every time I’ve tried it over the last years it doesn’t work.
I have been thinking about what elgregor01 wrote and an “action bar” makes alot of sense, atleast to me.
I admit his mockup may be crude
but it shows the idea.
I think some of the benefits of having the action bar instead of dialogs for folder creation and file renaming are:
* easier to see names of existing files
* possibility to scroll among existing files yourself
* possibility to let nautilus scroll among existing files as you type
* possibility to click on an existing file and use that name as a start instead of having to type everything in yourself
I also think it creates a cleaner and calmer user experience.
Please let me know your thoughts on this.
Hi,
I think I’m a little lost with all the comment and I’m not sure if I answered him already, but in any case, this kind of proposals are the best. Mockup + simple explanation. So thanks.
In general I don’t like the visuals of it, but it’s just a personal taste, so let’s not block on that. Also you lose the context of what item are you renaming (same problem as the dialog)
for 1- yes, although i cant see much value on it yet
2- um.. not sure I(as a user) want that much liberty which can let me in a state of loseness. Like I click rename,I scroll, and at some point I don’t know which file I was renaming (this doesnt happens with a dialog, but will happen with a popover as well)
3- this is the same as 2?
4- this is already the case for the dialog (I recommenss you to actually try to have a feeling)
for the calmer experience, I agree. But I would go with a popover in any case, if I found a way to fix the lostness the user can have.
While it tackles the cons the dialog approach brings and offers interesting possibilities, being able to “scroll away” the item to be renamed while still allowing the renaming is pretty dangerous/confusing to me, this could be cured but it will increase complexity, so not sure about this approach.
I understand you are leaning towards a popover, but let me just expand a little.
1. I think the value is being able to see how other files are spelled and numbered. Did I spell it like nazca or nasca? Did I use one or two initial zeroes, like 01, 02 or 001, 002? What number in the series am I at?
A popover could still have this benefit.
2. I can see the risk of getting lost.
With a popover you would probably hit the escape key and with an action bar you would probably click on cancel or a close button.
But I think the risk of getting lost is smaller than the reward and also you don’t have to use the scrollbar if you don’t want to.
3. This isn’t exactly the same as 2.
The idea here is when you start renaming the file ant.jpg to spider.jpg by typing the s as in spider, then nautilus could start sorting the file according to the new name for you while you type instead of after you have finished typing. This means the file moves to the other files starting with s and then files starting with sp as you type the p. The benefit of this is being able to see early on that you already have a file called spider.jpg and instead decide to name your file spider02.jpg without ever having to see the error message. Another benefit is that if you get the error message you now have the added bonus of being able to see what file it is that you already have with the name you are trying to use.
You could still implement this sort as you type idea if you decide to go with the popover.
4. I realize I didn’t explain this well.
When you create a new folder you get a generic name like ‘new folder’. If you then decide to click on an existing folder, say ‘photos from southern peru’ that text is used instead and you can easily change southern to northern instead of having to type everything yourself.
This is most likely not possible with a dialog. It could be done with a popover, but most in-file renaming I have seen cancels the renaming when you click on another file and you are left with ‘new folder’. You could still try and see if taking text could work with a popover but I think it would feel a little bit more natural with an action bar.
As you can see I was comparing the action bar with the dialog. I realize now that all the benefits can be had with a popover, except for maybe number 4. Comparing the subtle differences between the action bar and the popover is probably not as easy to do without implementing both, something I fully understand you may not have time for.
I atleast hope you go for the popover instead of the dialog and that you find a good balance on what possibilities to include for it 🙂
1- Definitely, now I see it more clear.
2- Reward about scrolling? You would allow to scroll with a popover and lose the popover there then?
3- I see. How would you manage to show the current element being renaming not interfering with this process?
4- Aaaah nice touch. Not sure if it is not confusing, not dismissing the popover/action bar in clicking a different item. I think I need a designer to explain here.
Number 4 is possible with a popover as well (with some tricks). And yeah comparing design decisions is not very easy… even designers sometimes regret some changes and we programmers “angry” revert them heh. But that’s the risk of being inovative and not just copy the patterns from Android/Macosx/Windows etc.
Looks like the popover is the way forward, and more a more seems clear.
Thanks for the improvements in Nautilus. What I severely miss is a possibility to easily see how much space is left on a device. Previously, this was shown in the statusbar, but now there is no instantly visible option in Nautilus. Please bring this option back, whether it shows the space left in the status bar or in the device list (with a green bar under the device like in Nemo), that doesn’t matter, but for people juggling frequently with different flash disks, hard disks, etc. this is a problem. Thanks in advance!
2. The reward about scrolling is the same benefit as for number 1 but being able to look at all files in the entire folder and not just the ones currently visible in the pane.
With an action bar, scrolling would work really natural, but how to do it with a popover?
One variant is to let the popover scroll away as well and let the user be lost. This would probably make it uncertain for some users if they are still renaming or not. The other option is to not let the popover go out if view. When you scroll up the popover follows the file until it reaches the top. If you scroll further up the popover stays at the top while the file scrolls away. When you scroll down the popover starts following the file again when it comes into view. I’m not sure if this would feel natural to use or not.
Another variant would be to have in-file renaming and only show the popover when the user tries to use an existing file name or illegal file name. Then there would be no popover at all when the user is scrolling only at some points when the user is typing.
3. The current element being renamed could be still while the other files are being moved.
This way the file you are renaming doesn’t hop around so you can still work on the same place on the screen.
4. This is how a save file dialog works. You have a dedicated naming area and when you click on an existing file you get that file name to use. So it works in the case of the save file dialog and it would be more consistent to also have it work in the file manager. I think using it in the file manager would be self explaing since you see that the action bar or popover is still there. It probably wouldn’t work so well with in-file renaming though.
On a sidenote, If you want to really step out if the box, you could remove open file dialogs and save file dialogs completely. They are a remnant from the days when there were no multi tasking. Instead of showing the user these dialogs you could actually show them nautilus instead. When you think about it the difference wouldn’t be that big, you would still present the user with a folder and a file.
The open and save file dialogs have advanced over the years and have become more like file managers anyway.
What is the deal with ok cancel on the top of the windows? I am on Ubuntu 15.04 and that is something that has either not been yet released here or is patched out? To me, it seems completely illogical, it is an action that closes the dialog, so I expect it to be at the end, that is, down. That is a gnome-wide desision? Can it be turned off in preferences?
I took a look at your mock ups and they really look nice. I do have some ideas though.
1. I can see in your changelog that you are going to do something about the float bar at the bottom. I know this has been beaten to death. However, from a system administration point of view it’s really helpful to always know the disk space at a glance. There are patches that place this information right above the column header so that it’s out of the way but always there. It would be nice if this was standard or even an option.
2. I can also see you are doing something with file operations. I like the mock up picture a lot but it needlessly blocks real estate. While knowing how long a file operation is taking is important. I don’t think it’s so important that it should take away real estate for other tasks being done at the same time in nautilus. Since the notifications have moved to the top it would be possibly better if the real-time status is placed within that notification area. That way it’s out of the way, and if people want to stare at a file operation all they have to do is click on the clock and look into notifications to see it.
3. Maybe it’s the version I have (3.16 ubuntu)but you used to be able to click on the location bar and “Paste into Folder” on the current active directory. That was an awesome feature. It actually made copying files into the active directory quite intuitive and solved the issue of where the appropriate hotspot should be when you want to copy into the current directory without clicking on another object meant for another purpose.
Well that’s it from me. Overall good job and I love the direction Gnome and Nautilus are going.
Like the changes. The best DE becomes more and more (and more) polished
I want support for Nautilus Folder Icons to be agnostic to the system.
Eg: Folder Icon information is stored in a .icons folder – this way when I migrate my folders or rsync across my computers I don’t have to set 300 custom icons as I have icons to help me quickly recognize, “Database”, “WWW”, “Documents”, “Backups”, etc… for work project folders.
I have a global icon source located at ~/.icons/ so as long as I rsync ~/.icons & a flat-file that nautilus reads about icon information eg: “cwd:///.icons” I shouldn’t have to set the icons per Linux User, per Computer, etc…
Please, please please, thank you.
Quick question—is there any way to make the icon size smaller? I would guess that this is a “sore” subject, but for us with large screens (I use a 27″ monitor as my main screen)–64 is a very large size. I would be willing to hard code a change if you could point out where it could be made….
Of course, it would be absolutely tops if the control would allow 48 or 32 as a minimum size….. 🙂
First of all, I really like the new nautilus and I’d like to thank you for it. However, as other users have stated, the 3 zoom settings are all much too large for my liking. If you could add 1-2 smaller zoom settings, I would greatly appreciate it.