Re: Come fix bugs! (Batteries included)
- From: Alexander Larsson <alexl redhat com>
- To: Danny Milosavljevic <danny milo gmx net>
- Cc: Nautilus <nautilus-list gnome org>
- Subject: Re: Come fix bugs! (Batteries included)
- Date: Wed, 13 Oct 2004 17:21:26 +0200
On Tue, 2004-10-12 at 20:12 +0200, Danny Milosavljevic wrote:
> 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
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!
] [Thread Prev