Re: more bugs....

[Ryan Muldoon <rpmuldoon students wisc edu>]

> 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.  
> 
> 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.

> 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.

> 
> 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.

>  
> 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....

> 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.

> 
> 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.

> 
> 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.

	--Ryan