On Fri, 2002-06-14 at 17:56, Dave Bordoley wrote: > On Fri, 2002-06-14 at 17:38, Ryan Muldoon wrote: > > > > > bug 46306 -- No way to change a link's target > > > > > > Is changing the target of a symlink a reasonable unix action? > > > > > This could be useful, if in the "properties" dialog there were an option > > to change the link target. > > Yeah but what i was saying does this operation really make sense with a > unix symlinks... > Well, effectively it would probably remove the symlink and make a new one. But I don't see how this matters...if the functionality is useful, why not have it? > > > > > > bug 47806 -- Changes to column widths are not saved > > > > > > List view. I don't think we should be saving column width because the > > > contents of a directory may change. In this case it makes more sense for > > > nautilus to automatically resize columns to optimal lengths (as it seems > > > to do already). > > > > > State should be maintained wherever it can be, I think. I want my > > windows popping up as I last left them. > > Thats a different issue. windows should maintain there sizes (i think > frank fixed this), but as for column widths isn't making it > automagically work just better? > No, I am not just talking about window sizes and locations on the desktop. I mean *state*. Ideally, the directory should be shown to me exactly as I last left it. Possibly the most annoying thing about Nautilus right now is that if I scroll down halfway in a nautilus window, click on a folder, then go back, I am at the top of the directory again. Although this is a different bug number, it illustrates my point. State should be maintained to as great a level as possible. > > > > > bug 70543 -- please add commands to bzip or tar and bzip to the > > > right-click menu > > > > > > Isn't this what scripts support is for. I do think it would be nice to > > > include some default scripts with nautilus though. > > > > > This is a specific case of a general problem - there should be a way to > > do more with specific MIME types. Scripts aren't even determined by > > mime type, so you could have like 50 scripts in a list, when only 2 of > > them apply to the type of file you're looking at. Some way of having > > "shell hooks" for other apps would be nice, so they could insert things > > into the right-click menu for given mime types. > > Regardless I don't think this belongs in the current nautilus ui. We > have a mechanism for providing such a feature, it is called scripting, > and in this specific case mime types are not an issue at all, since the > option to gzip or bzip would be available for any file. Now ungzipping > or unbziping will eventually be handled by nautilus very nicely, by > allowing the user to traverse a tar, gzip or bzip file in the file > manager, but this is a different issue. > Well, as I pointed out, scripts are ok, but not a good permenant solution to basic functionality needs. I really don't see the harm/expense as leaving the bug with a "wishlist" milestone as a placeholder for desired functionality. Once Nautilus handles the zip and tar files via gnome-vfs, then you can close the bug. > > > > > > > > bug 47829 -- link emblem doesn't look good when zoomed in 400 percent > > > > > > link emblem is a png, maybe in the future we should use svg for all > > > emblems, but currently folders look pretty bad at 400 percent as well. > > > > > Well, that's the theme's fault, so it is a bug. Some png-based themes > > handle this fine by making larger versions of all of their icons, so > > huge zoom factors still look good. Whether there should be a separate > > place to file bugs against themes is a different question. > > My argument here is that the default theme is unmaintained, is it worth > keeping open bugs against it. The obvious real solution is to replace > the default theme with one from someone on the gnome art team who will > maintain it. > Well, that is why it might make sense to have a "themes" or "gnome art" category in bugzilla. > > > > > > > > bug 47103 -- need scaled version of Trash icon in default theme so it > > > looks good > > > > > > Complains about the fact that default trash icon doesn't scale. > > > Considering that the existing nautilus themes are pretty much > > > unsupported, I think we should just close this. In the long term we'll > > > probably just want to replace the existing nautilus themes with ones > > > that are more gnomish anyway i would guess. > > > > > Maybe this just suggests that there should be a place to file theme > > bugs.... > > see above... > > > > > > bug 47902 -- Support Windows .ico file format > > > > > > I don't think we should be bending backwards to support non free specs. > > > > > Don't we support gifs already? There's nothing wrong with at least a > > placeholder "wishlist" bug for getting .ico support on gdk-pixbuf, or > > wherever the appropriate place is. > > my basic point, is that wine will add icons for windows programs > installed through it to the desktop. This should be good enough we don't > need to bend over backwards to support a non-free icon spec, especially > now that we have a free one available. > Well, maybe some volunteer will want to support .ico files. The reality is that there are a bunch of graphics in that format. I agree that pngs are cool and all, but that's like saying that OpenOffice shouldn't support Word files because we like xml better. > > > > > > > > bug 68391 -- Themes are in strange directory > > > > > > Complains about the fact nautilus themes are in usr/share/pixmaps. I > > > think this is a non issue since user installed themes are stored in > > > ~/.nautilus/themes > > > > > Actually, I think this makes a lot of sense. It has always bothered me > > that nautilus themes are in /usr/share/pixmaps, as there are also xml > > files. It also seems that we have /usr/share/themes. Only gtk puts > > stuff there for now, but they namespace their themes by putting them in > > a gtk or gtk2 directory. So it would be nice if all gnome (and kde) > > themes moved there. This would also make "metathemes" easier to > > distribute, because it would all be a single directory with a bunch of > > subdirectories. > > but there is no user visible issue, since only the root user can change > these anyway. It would break backwards compatibility, and as for the > longterm, nautilus theming will probably change drastically in the > future once the freedesktop icon theming spec is adopted and used by all > apps for icon theming (ie. you'll no longer theme just nautilus but all > apps will use the same icon theme for mime type icon theming). I just > don't see much benefit here. > Well, the reality of the Linux userbase right now is that they *do* install their own themes, because there are a lot more home users than business users. This will probably change, but not this week. In fact, every linux user that I know that bothers with themes at all installs them as root in whatever directory is appropriate. And then there is also just the elegance aspect. Why put crap all over the place when there is a place specifically for it? It wouldn't kill anyone to keep the bug open as a placeholder...maybe for 2.2. > > > > > > > > bug 65058 -- add a way to do operations as another user (as "sudo" does > > > on the command line) > > > > > > Seth expresses a concern about security in this bug. Personally I'm > > > against this, based on the assumption that gnome is most likely to be > > > used in more large scale installations, where most users don't have root > > > access anyway. For home users is pretty easy to just use sudo from the > > > terminal. > > > > I think a good goal is to try and get away from *ever* needing to drop > > into a terminal. I should be able to choose to run an app as a > > priveleged user. Redhat has something for this, that prompts you for > > the root password, when you need to run an app that must be root. > > Ximian has another solution for Red-Carpet. It would be cool if there > > were one consistent way of doing this, and also if you could rightclick > > or shift-rightclick on an app icon and get the "run as root" option. OS > > X does this somehow, as does Win2000. Since "simple" things like > > installing software, burning cds, etc require root, it would be a crappy > > user interface to require users to drop to a terminal whenever they do > > these fairly routine tasks. > > In gnome, apps that require root access will prompt you for a root > password. So i think this adequately addresses your issue. > (gnome-toaster, gdm configurator etc.) I think having the specific > ability to run nautilus as root in a user visible way though has limited > benefit, as mentioned before in the installations where gnome is most > likely to be used most users wont have this access anyway. > Only if things are set up correctly...I've seen gnome-toaster start plenty of times as a normal user, and watch people get frustrated to no end. And a root nautilus would be really useful sometimes. I like to use nautilus for my file management, but if I still have to use a terminal for any complicated file management, why bother? > > dave > -- > nautilus-list mailing list > nautilus-list gnome org > http://mail.gnome.org/mailman/listinfo/nautilus-list
Attachment:
signature.asc
Description: This is a digitally signed message part