GNOME Bugzilla – Bug 306363
Places API (Desktop, Documents, etc.)
Last modified: 2012-12-11 19:02:04 UTC
should not list every drive [it's not DOS :P] should list My Computer for the same functionality should list My Documents should list My Network [if fchooser can work there] should list Recent Documents
*** Bug 137516 has been marked as a duplicate of this bug. ***
I created the bug that was marked as a dup. I agree, but please let's drop the "My"... Microsoft finally saw the light and is removing "My" from "My Computer", "My Documents", "My Music" etc. in Windows Vista. Ever had to describe this directory to a newbie over the phone? "Open 'My Documents'." "Your documents?" "No, your 'My Documents'." "My your documents? What??"
Open folder 'My Documents' (means to the 99.9% windows user to open the folder My Documents) Luke, don't get me wrong, it's not like I like My or Your or Her but let's see GTK+ have it My and add a flag and when Vista is out you enable that flag for Vista and remove My it's not likely that vista will be in more than 50% windows systems until 2008
We should probably avoid copying design flaws in other OS'es and try to get it right ourselves the first time...
hm? I hope the decision makers will not have your opinions.. Design Flaw is to have C:\ D:\ as predefined and not have My Documents and other I say when I reported. GTK+/win32 has C:\ (Gimp or other) user goes: "WTF IS C:\" anyways
Ah, I misunderstood you then. I thought you were saying that we should call the folders by the same name on Unix as is the case under Windows. I definitely agree that sane defaults including the normal "places" in use under the OS in question should be the used. Sorry for the confusion. Maybe the report should be retitled for clarity? I missed the OS == Windows field :-)
In general there are a lot of directries that a lot of users would be happy about if they were automatically recognized: Music / My Music Photos / My Photos Documents / My Docmuents Audio AudioBooks / Audio Books etc. Of course there are i18n issues with this too, but it would be great to brainstorm a list, then cut it down to a resonable subset.
> (Gimp or other) user goes: "WTF IS C:\" Are you sure drive letters are that foreign to average users? At least anybody who has worked in any kind of corporate or school Windows network surely has been exposed to drive letters, aren't they typically (over)used in Windows networks? ("Company R&D stuff is on R: drive, except the recently acquired BlarghCorp still uses the U: drive, your home directory is the H: drive, project FooBar has its own stuff on the F: drive", etc ad nauseam.) Also, don't even people on single user home machines use drive letters for removable drives? Is there even any "natural" way to use Unix-style mounts for them? > Of course there are i18n issues Well, of course one does not hardcode the English names but either have them as translated strings in GTK+, or look up the actual localized name used by the Windows installation.
Re. comment 6 and comment 8: my dup (and my comments above) were in no way related specifically to Windows, sorry, I'm not trying to hijack this bug, it's just that my bug was marked as a dup, but now it's appearing that maybe my comments are not as relevant in this discussion :-) My point was that there should be certain places that are recognized by default, no matter what language they are written in, and added as default bookmarks. That's somewhat related to Nikos' bug, if I understand correctly, but perhaps everyone is talking a different language here. What I think should happen is that if any of a given list of directories is found within the user's home directory, they should just be added as default bookmarks. So "Documents" or "My Documents" for English, "Mes Documents" for French, "Soryu" for Korean (only it would written in Hangul not in romanization), etc. Same for "Music", "My Music", "Ma Musique", "Umak" (Korean) etc. The i18n issue was simply about allowing the user to call these default directories something sensible in any language they want (or having the distro set them up for new users in the specified language), and having GTK pick them up automatically as bookmarks. As for whether every drive should be listed, maybe not, but then again maybe -- I would actually like to see all mountpoints in the bookmark list for GTK open/save dialogs. Otherwise you have to browse to /media or /mnt and then to the mountpoint... and you have to know /mnt and /media are actually there in the first place. It would be nice if hot-plugged media (USB keys etc.) just showed up on the GTK list automatically (it seems like not all mountpoints show up currently).
Tor, mclasen told me you had a patch to ask windows shell on what it should list? if you do not, I think some very common in win2k/xp could be listed about the C:\ D:\ in Windows that is windows (C:\) games (D:\) and moreover they are not listed visually (only if you clik the dropdown menu of Location) where as Desktop My Documents My Computer My Network Places is what the user expects to see.. ps. My Music is not by default predefined. (if such default exist) but I think it does. My Music show up in related to music stuff but that's for the gtk+ programmer to handle
Moving back to GTK+ ... gnome-vfs backend isn't used on Windows.
*** Bug 328119 has been marked as a duplicate of this bug. ***
What we need is a way for the file system backend to provide the list of Places itself, rather than hardcoding it. See http://live.gnome.org/DesktopPlaces for the discussion on this.
Taking off the read-only toggle would be good as well. That way if seeing "My Desktop" etc gets your hackles rising like it does mine (@Luke Hutchison ;) ) at least I can rename it or even delete it.
Can't you just delete ~/Desktop, then?
NO! That's the whole point . everything that is there by default is r.o. I have the popup menu but remove and rename are greyed out , if I look at the source they are created not removable whick would appear to mean also not renameable. line 1469 of 2.8.20 linux source if my notes are correct impl->has_desktop = shortcuts_insert_path (impl, -1, FALSE, NULL, path, _("Desktop"), FALSE, NULL);
What I mean is, can't you just do "rm -rf ~/Desktop", and then the corresponding item in the bookmarks pane won't show up. Let's work on making this consistent across the desktop. The plan is to have exactly the same code running the bookmarks pane of the file chooser and the "Places" pane of Nautilus windows. Then we can look into making certain built-in paths optional. Who wants to propose an API for this?
Just one comment since API is being talked about -- it would be important to have this list be updatable dynamically (a la gamin/imon), so that for example if the user has a file chooser window open and they plug in a USB key, it should appear instantly on the list of locations.
>>What I mean is, can't you just do "rm -rf ~/Desktop", and then the corresponding item in the bookmarks pane won't show up. I believe the expression is "putting the cart infront of the horse". I want to remove a bookmark not the directory it points to. (I would like it to stay gone next time I open a dlg. I guess that means gconf or something, that probably should be a separate issue.)
>>if the user has a file chooser window open and they plug in a USB key, it should appear instantly on the list of locations. If the user inserts removable medium while a dlg is open he should have some sort of means to refresh the display . That would be a lot quicker to implement.
(In reply to comment #20) > If the user inserts removable medium while a dlg is open he should have some > sort of means to refresh the display . That would be a lot quicker to > implement. This already happens automatically if: 1. You are using the VFS backend for the file chooser. 2. Your d-bus/HAL/gnome-vfs stack is configured correctly.
I take it that was more a reply to Luke's request for dynamic update. What I am suggesting is for systems not using vfs that there be a refresh mechanism similar to windows' F5. Maybe this could be a (double)click on the empty space of the bookmark pane or a context menu item , with possibly a hotkey for non-mouse usage.
Would adopting cntl-R as in nautilus conflict with other gnome conventions or usage?
The requests from the opening comment have been implemented for a long time. Closing this bug.