El mar, 10-02-2004 a las 06:21, Alexander Larsson escribió: > > The reason we use $home as cwd when launching things is that that makes > it the default saving location for most app fileselectors. It also makes > relative pathname files written by the app (including core files) end up > in $home (instead of /usr/bin where it would otherwise end up for most > apps). That does make a lot of sense, when apps are launched *from the gnome menu*!!! Not when apps are launched via file associations or shell scripts. > > > 2. Almost all of the times, when I have two Nautilus windows open and I > > right click on a file on the first window and tell it to "Copy", and then I > > go to the other window to tell it to Paste it via the context menu, the > > Paste option is greyed out. I have to *reload* the second nautilus window in > > order to let it know that an item is ready for pasting. I find this behavior > > very weak for a file manager, because cut/copy/paste is what it supposed to > > be doing *well*. > > You don't actually need to reload the window to make the paste menu > work, selecting a file is enough. But it is rather lame, yes. > > The underlying reason for this is a problem with X11. There is no way to > get told when the owner of a selection changes, so we can't update the > sensitivity of the paste menu. The fix for this is in the XFIXES X > extension, but that hasn't ended up in a widely distributed Xserver yet. > I added some code to cvs that makes it notice changes from inside > nautilus, so the basic cut/paste cycle in nautilus should work better > now. It can still be confused if other X clients modify the clipboard > though. > > > 3. Please provide a way to have Scripts on /usr/share/somewhere, so more > > users in the system can try out scripts automatically. The Dropline Gnome > > distribution wanted to do that, but they didn't find a way for Nautilus to > > recognize any other location for scripts other than in the ~ so they shipped > > with none. > > The exact behaviour of scripts need to be though about some more. > Directory merging always creates problems and complexities, so I'm not > sure we want that. I'm not even sure we want to expose scripts as-is in > a way that everyone is forced to see them. Perhaps two menu items "See scripts available for all users" and "Go to my personal scripts folder", in a shorter fashion, can do it? > > > 4. Editing/creating/managing MIME types & their exec/view apps is currently > > a real mess on 2.4.x. It blows my mind everytime I need to add an app or > > modify an app for a given filetype. I hope an elegant solution is at hand on > > 2.6. Have a look at the BeOS way if that helps: its GUI is really intuitive > > for this kind of thing. (I can provide screenshots if you need any samples > > or ideas, just let me know) > > We are aware of the fact that the mime ui is bad. Unfortunately we > didn't have time to do much about it for Gnome 2.6. > > > 5. Please provide a fifth option on the last tab of > > nautilus-file-management-properties to let the user decide if they want > > their image files to be previewed or not. Currently, images bind together > > with the HTML/movie and other files, and in my opinion, the Image previews > > should have their own drop down option because they are very "common" on the > > average user's file system. So, please leave the HTML/movie files together > > with the "other previewable files", but provide its own option for Images. > > Especially for images, it would be best if we also get the option to decide > > how big we want the thumbnail to be (up to 128pix) and this option should be > > set on folder-by-folder case. This way, I could do what I can do with OSX's > > new Finder or Explorer. Use the file manager as my image viewer for my 3,000 > > digital photos that I store. Especially because all image collector apps on > > Linux suck (none is as powerful as iViewMediaPro -- I am not talking about > > iPhoto/gThumb/kinkatta kind of home apps), so I would like the file manager > > itself to be able to handle simple actions like variable image size per > > folder. A file manager is not an image viewer, and Nautilus is definately > > not a Konqueror monster, but what I am asking I believe is within the scope > > of a modern file *manager* without making things complicated or adding truly > > uneeded options. > > Perhaps we should have a separate preference for normal images. Thats > even possible to set up already using gconf-editor. However I disagree > about adding the thumbnail size prefs. If our photo managers suck we > should work on fixing them instead of adding some of photo manager ui to > the file manager. > > However, this all has to wait until next version. We're in hard UI > freeze. > > > 6. Please provide a checkbox/knob to make Nautilus remember the background > > images or colors on folder case by case. I would like my home ~ to have a > > nice girlie background image with fade pink hearts, but I don't want my > > /usr/local/bin to be the same. ;-D > > As someone said, this is already possible. Although the UI isn't that > great. A great UI that allows both of these isn't that easy to come up > with though, and we are tossing around some different ideas about folder > backgrounds. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl redhat com alla lysator liu se > He's an underprivileged playboy paranormal investigator from a doomed world. > She's a pregnant wisecracking doctor with the power to bend men's minds. They > fight crime! -- Manuel Amador (Rudd-O) GPG key ID: 0xC1033CAD at keyserver.net
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente