Re: more bugs....

[Dave Bordoley <bordoley msu edu>]

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

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

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

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

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

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

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


dave