Re: Come fix bugs! (Batteries included)

[Alexander Larsson <alexl redhat com>]

On Tue, 2004-10-12 at 20:12 +0200, Danny Milosavljevic wrote:
> Hi,
> 
> Am Montag, den 11.10.2004, 12:41 +0200 schrieb Alexander Larsson:
> > [...]
> > > > * tree sidebar timeout before load-uri when keynav:ing
> > > > If you navigate the tree sidebar with cursor keys, it will immediately
> > > > start loading the folders as you move over them. This makes keynav
> > > > painful. We should have a delay here before we load the folder.
> > > 
> > > did that, are 300 ms ok ?  (attached, fm-tree-view.diff)
> > 
> > Hmm. Its a bit to short for me when navigating with the keyboard. It
> > only triggers when i hold down the key. Also, having a delay when
> > selecting by using the mouse seems wrong to me. The delay should only be
> > when the keyboard was used.
> 
> Yeah, attached with changes. 
> Do we want to depend the delay on the keyboard repeat rate ? 
> (seems to be gconf /desktop/gnome/peripherals/keyboard/rate)
> 
> If so, how is the relation factor ?

Actually I changed it back to 300, my system was a bit hosed when i
tested last time so my testing was a bit busted. Depending on the
keyboard rate seems a bit overengineered to me, but might be right. :)

Anyway, patch commited.

> > > > * context menu poped up by keyboard appear at mouse pointer
> > > > If you select a file and bring up the context menu (using ctrl-F10)
> > > > the menu pops up at the current mouse position, not the location of
> > > > the icon. This is distracting when you're using keyboard navigation,
> > > > and the mouse cursor could be anywhere.
> > > 
> > > Yes, but it is hard to fix. I tried it in one of my other apps and what
> > > I did was basically,
> > >
> > > Really ugly. I hesitate to clobber nautilus up with that ;)
> > 
> > It can't be that hard to do. Just look at the type of the event that
> > lead to the popup. Ideally, we want clean simple code, but the most
> > important thing is the user interaction behaviour. If we have to add a
> > (small, localized, commented) hack to be able to implement it, thats
> > fine.
> 
> Well as there seems to be a function to get the selection's coordinates
> I'd like to try. Cant find the gtk_menu_popup call however. Help ? :)

Start from fm_directory_view_pop_up_selection_context_menu(). It gets
all complicated with bonoboui stuff though. :(

> > > > * .hidden reading follows symlinks/nodes etc
> > > > When reading .hidden files we should only read it if the file is a
> > > > regular file. We shouldn't follow symlinks, hang if someone puts a
> > > > ..hidden pipe there, or whatever unregular.
> > > 
> > > did that, attached nautilus-directory-async.diff
> > 
> > +	if (!file_info)
> > +		return;
> > 
> > We use brackets around one-liners too. See docs/style-guide.html.
> > 
> > +	/* FIXME check flags for GNOME_VFS_FILE_FLAGS_SYMLINK too ? */
> > Checking for == GNOME_VFS_FILE_TYPE_REGULAR should be ok since we don't
> > pass GNOME_VFS_FILE_INFO_FOLLOW_LINKS.
> > 
> > +	/* or GNOME_VFS_FILE_FLAGS_LOCAL */
> > Non-local .hidden files sound ok to me.
> > 
> > +	file_ok = (
> > +		(file_info->valid_fields 
> > +	& (GNOME_VFS_FILE_INFO_FIELDS_TYPE |
> > GNOME_VFS_FILE_INFO_FIELDS_SIZE)) 
> > +	== (GNOME_VFS_FILE_INFO_FIELDS_TYPE | GNOME_VFS_FILE_INFO_FIELDS_SIZE)
> > +	)
> > +	&& (file_info->type == GNOME_VFS_FILE_TYPE_REGULAR)
> > +	&& (file_info->size > 0);
> 
> Attached with changes.

Commited with some changes (you still looked for
GNOME_VFS_FILE_INFO_FIELDS_SIZE).

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a sword-wielding vegetarian matador on a search for his missing sister. 
She's a mentally unstable insomniac magician's assistant who believes she is 
the reincarnation of an ancient Egyptian queen. They fight crime!