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, thought so too at first, but it turned out that it didnt annoy me
when using the mouse either. But I guess its better to just delay on
keyboard event. But how ? Catch Up/Down/PageUp/PageDown event on
key-press-event ? then return true ? eew...
but I guess it should work out.
>
> > > * 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.
>
The hard part is figuring out the screen coordinates of where in the
tree the cursor (the usually dotted rectangle around a file entry, the
keyboard focus in the tree view, not mouse pointer and not caret) is
currently. But I found
| fm-directory-view.h FMDirectoryViewClass
| GArray * (* get_selected_icon_locations) (FMDirectoryView *view);
| fm_directory_view_get_selected_icon_locations
| Return value: GArray of GdkPoints
by now. Seems to be helpful in what we want :)
> > > * .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.
oops, okay.
>
> + /* 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);
>
>
> Why the file_ok variable?
To make the unref be in one place only. Its kinda to prevent myself from
leaking objects all over the place ;)
But I can change it to two unrefs when being told so ^^
> And why check size? its an usigned, so it
> can't be negative, and reading a file of zero bytes should be harmless.
Well,
* its meaningless to read a .hidden file with 0 bytes
* if I or gnome-vfs forgot to check for some obscure pipe-like-thing it
will most probably not have file size > 0 ;)
Hmm, sounds kinda foolish. I'll probably remove it after all.
>
> > > [...]
> >
> > > * size of home on desktop wrong
> > > If you select properties on the home icon on the desktop, the size
> > > won't be calculated. Selecting it on the real folder in /home works
> > > though. We probably just have to follow the link when calculating the
> > > size.
> >
> > Where is that icon handler code ? found nautilus-desktop-window.c, but
> > its not in there ;)
>
> Exactly what do you mean? Perhaps you're looking for nautilus-desktop-
> icon-file.c? Or maybe nautilus-desktop-link.c.
>
> What you really need to look at is get_target_file_for_original_file()
> in fm-properties-window.c and how it is used when calculating the size.
yep, they all helped. Thanks.
desktop_icon_file_get_deep_counts seems to set zero for all that stuff.
Probably its something like
* changing
- nautilus-desktop-icon-file.c get_deep_counts
to check
details->link (NautilusDesktopLink *link) object
for the deep count.
But it doesnt have that function yet. So
- add that too into nautilus-desktop-link.h. and
- check link->details->activation_uri for the vfs attributes we want
there.
Hmm. It needs file_count, directory_count, unreadable_directory_count,
total_size.
Same like
nautilus-vfs-file.c vfs_file_get_deep_counts
already does.
Proxying should be enough.
Getting from a activation_uri to a NautilusFile should work over
nautilus_file_get.
But there seems to be some on-demand-size-retrieving in
nautilus-vfs-file.c get_deep_counts (file->details->deep_counts_status !
= NAUTILUS_REQUEST_NOT_STARTED), will that be affected by me using
nautilus_file_get and unref all the time ? Guess not.
Just thinking loud here ;) Will try laters.
cheers,
Danny
--
www.keyserver.net key id A334AEA6
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil