Re: more bugs....

[Dave Bordoley <bordoley msu edu>]

On Tue, 2002-06-18 at 04:49, Alexander Larsson wrote:
>  
> > bug 40048 -- display directory sizes instead of item counts 
> > 
> > Currently we display directory counts. Personally i like these and find
> > them more useful than size counts. 
>  
> I think directory sizes makes more sense from a usability standpoint (you 
> may want to delete the largest directory, but you rarely care about the 
> number of files in it). But since the cost of calculating the directory 
> size if so high (need to recurse into all subdirs) I think having 
> directory counts as an approximation is good enough.
> 
> We do show the directory size in the properties dialog anyway.

I'll leave this open, if you think that sizes make more sense than there
is no reason to just close it. Perhaps someone will come up with the
magic algorithm to make this work :)

>  
> > bug 44633 -- Cannot rename default icons on desktop 
> > 
> > A feature request to be able to rename mounted file system icons and
> > trash (since home and start-here can be renamed). I think renaming trash
> > is pretty crack, and nautilus generates the mounted drive names to be
> > unique, so i think we should just stick with the current behavior.
> 
> Renaming mounted volumes seems to be a reasonable request. Its not high 
> priority, but its still reasonable. Even better would be if it read the 
> volume name and used that for the icon, and then renaming it changed the 
> volume name. (Wouldn't work for CDs of course.)

Good point!

> 
> > bug 44772 -- double-clicking file name should start renaming (not open
> > file) 
> > 
> > Personally i think clicking should never start rename, we have a rename
> > option in the context menu, this is much cleaner and prevents users from
> > accidentally starting rename. I would actually like to see click for
> > rename removed from the list view as well since I'm always accidentally
> > starting renaming when i just want to open a folder
>  
> This sounds like a ui detail that is very hard to get right (in fact, it 
> seems neither windows nor mac got it right). Right now we're totally 
> punting it, but the current method is sort of contrary to the direct 
> manipulation model nautilus uses. 
> 
> I wouldn't be against someone experimenting with this, but we have to test 
> the behaviour a lot before accepting it.

I'm still very against this, as you've mentioned no one else has seemed
to get this right. The list view currently has this and I'm always
accidentally starting the rename operation(even when using single click
mode).

>  
> > bug 46306 -- No way to change a link's target
> > 
> > Is changing the target of a symlink a reasonable unix action?
>  
> It's normally done (in the shell) by creating a new link over the old one. 
> Of course that is a lot more work in nautilus than a shell. I think it is 
> a "reasonable" unix action, but certainly not common. Keep this bug 
> around.

Basically I was quoting john sullivan's comments on this bug, i don't
really care either way though.

>  
> > 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 wit> > bug 62201 -- Do not show dot files in Sidebar: Tree, even if "show dot
> > files" enabled 
> > 
> > Why should we ignore the user chosen preference. I don't see the benefit
> > of special casing this.
>  
> Yeah. It sounds pretty confusing.h nautilus though.
> 
> I think this sounds like a great idea. scripts are for user customization 
> or special needs, not core functionallity. 

ok maybe we can create a context menu item add to => some virtual
folder. Where the virtual folder can be a placeholder folder for files
that should be added to a tar/zip etc. or maybe a virtual folder for
files to burn to a cd (integrated cd buring would be way cool, at least
for data). What do you think?

>  
> > 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.
> 
> The crux folders look good at 400%, but the link emblem really look bad. 
> And it's such a simple icon too. Making it an svg makes a lot of sense to 
> me.

maybe one of the art guys could do a quick one for us :)

>   
> > 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.
>  
> DaveB wants to remove stuff, film at eleven. :)
> 
> I would like a larger version of the blue trashcan, but since arlo doesn't 
> work on gnome any more that will be hard i guess.

We probably should create a new default theme that uses the same color
palette as the stock icons so that the default nautilus theme better
compliments them. I know gtk is planning on making slight changes to its
default theme in 2.2 so that it compliments the stock icons better see
bug 80691.

>  
> > bug 84209 -- Display of text preview inside of nautilus icon cannont be
> > turned off on a per-file basis 
> > 
> > User is concerned that they store their passwords in a text file and
> > cannot turn off icon previewing per icon. They are worried that a co
> > worker will see the icon preview and hence their password. My opinion is
> > that text preview should be all on or all off. plus you shouldn't be
> > storing passwords in unencrypted text files anyway.
>  
> Uhm? That bug number is a galeon bug.
> 
> Anyway it sounds like a pretty low-prio issue. I guess it could be nice to 
> have, but the ui to control it would probably clutter up the menus. The 
> easiest way to "fix" it is to add a few newlines (or text) at the start of 
> the file.

oops bug 84029, this is definately a ui issue. My question is does the
limited benefit justify the added ui elements? Imho, no since i figure
if you're so concerned you can either add a few newlines as you said or
just turn the feature off.


dave