On Thu, 2009-12-03 at 17:04 +0100, Cosimo Cecchi wrote: > While I completely agree about enabling browser mode by default, I'm > not completely sold on Nautilus not drawing the desktop by default:
As a start, here is what the gnome-shell design docs say on the desktop: Used for both ephemeral, and working set data finding and reminding. Given time, the constant stream of things to do, the constant remainder that does not get done, and the unwillingness to categorize and archive manually, and the fact that the solution doesn't scale (due to being spatially bound) results in the system breaking down. On top of this - so to speak - is the problem that this data lives underneath all of the current activities on the computer and is therefore very difficult to reach. Which also tends to reduce its effectiveness for finding and reminding. It also doesn't provide any form of prioritization. In the Shell design, the "desktop" folder should no longer be presented as if it resides behind all open windows. We should have another way of representing ephemeral and working set objects. The reminding function of the desktop is really only available immediately after login. Once any activities are started its effectiveness is dramatically diminished. Starting the Journal automatically at login will have a equivalent effect and have the advantage of being easier to access later. Trashcan Target The need for a trashcan target is greatly diminished by removing the desktop folder from the computer background. However, to remove the need for it one needs to go a step farther and drop the use of the spatial file management (ie. the desktop metaphor) altogether. It will be necessary to build a Trash capability into the Journal Summary and history archive that are described in a later section. If we need a metaphor at all then perhaps a better one is to "forget" the object. > * even with many applications opened, the desktop is just one > click (or one keystroke) away from you (Ctrl+Alt+D or the > "Show Desktop" applet). Yes, its quick to reach, but so is the activities overview (press the windows key or move the mouse to the top-left corner. It all depends on why you want to reach the desktop. If its for something like launching an app/location then doing that via the activities overview is as efficient as the desktop (and its an advantage imho to only have one consistent way to do this). So, this argument is only valid if you're doing something you can't do on the activities overview. > * it's a very big space to save things. If we're going to have > something like a file stack in gnome-shell, we should make it > sure it has the right amount of space. For instance, I find it > confusing to use the stacked "Downloads" icon on the OSX dock, > as it becomes just too messy and out-of-control when the number > of files is high. You can always clean up your desktop instead > when there are too many things on it, just like you'd do with > a real one :) It is very big, but its often covered and its limited in space (and thus doesn't scale). Its also problematic in that its fixed size changes when the resolution changes meaning you might "lose" files when that happens. The main advantage to the desktop is really that its a logical default storage location for starting something and for temporary things that is easy to reach. If we remove the desktop the likely place that things like this would be done is the home directory, but thats not as nice as its full of stuff thats always there, so you can't easily clean it up or get an overview of only the stuff you've temporarily created. > * orthogonal to the previous one, there are some items which are > very handy to have on the desktop anyway, for instance, newly > mounted volume icons. Ideally it should be as easy to reach these with gnome-shell as the desktop, and if its not we should instead fix it. Using the activities overview its pretty easy to reach a mounted volume as they are listed on the left. However, for the case of a newly mounted volume we should probably integrate with the shell notification system so that plugging in a cd will show you some notification that this is now availible, letting you quickly click on it to open the mounted location. > I agree with this; as I see it, the g-s search is something like > Spotlight's dropdown menu; if you click a button, a nautilus windows > would open with the full results/set of actions you can take. If > you're going to integrate metadata more into Nautilus, I'd not be scared to > see something more than bare filesystem hits there in Nautilus' search > window, though a good UI for that would be mandatory. I'm always worried about adding non-file things to the nautilus views. A lot of people has historically used gnome-vfs modules + nautilus to create "lists" of things (fonts, themes and whatnot). This is almost always a bad idea. All of the nautilus UI is specialized at showing files and their properties. And the operations available on items expect them to generally act like normal files. Adding other types of objects always leads to strange behaviour due to this. (Not to mention that a custom list dialog could contain the special features needed to make listing the new type of object better.) Additionally I think its kinda unexpected to open the file management application and have its search return a preference dialog. Especially with the new focus on "file management" rather than being a shell. However, it would be cool for instance to have the search results in gnome-shell have a link in the "files" section of the results that opened up a nautilus search. It would also be nice if the search result picked up things like custom icons and emblems from nautilus. And if the files had context menus with things like "open with other...", and "show in file manager" operations. > I've always liked the idea of a file well, but I'd rather see this as > some sort of "temporary stack" where you put all the resources you > need > to accomplish a task (maybe with an option to save them, and associate > it with a shell activity/workspace), rather than a permanent > file-system > folder. What do you think of my proposal about piles? > By the way, if we're going to stop drawing the desktop, what would be > drawn on it and who would be responsible for that? If nautilus just stops this then the default will be for gnome-settings-daemon to set the desktop background and for X to render it. However, if gnome-shell instead managed it we could do nice things like having different backgrounds for different workspaces. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc al...@redhat.com alexander.lars...@gmail.com He's a shy Catholic cop on the run. She's a plucky Bolivian safe cracker operating on the wrong side of the law. They fight crime! -- nautilus-list mailing list nautilus-list@gnome.org http://mail.gnome.org/mailman/listinfo/nautilus-list