Re: Come fix bugs! (Batteries included)

[Alexander Larsson <alexl redhat com>]

On Mon, 2004-10-11 at 20:34 +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, 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.

Well, if you increase the delay it might be annoying with the mouse.
To figure out if the change was due to keyboard navigation, just use
gtk_get_current_event() and look at the type of event
   
> > > > * 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 :)

And if that doesn't work, you can make a new virtual method in
FMDirectoryView that does what you want and implement it for icon view
and list view.

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

I'm not sure this sounds right. We don't want the file as displayed on
the desktop to have the size of the whole desktop. We just want to use
the file that the home icon points to when we calculate the size in the
property dialog. This is the difference between and original file (the
icon on the desktop) and a target file (the real home dir).

This actually seems to happen. directory_contents_value_field_update()
seems to be using window->details->target_files when it calls
nautilus_file_get_deep_counts(). I don't know why it doesn't work
though.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an all-American guerilla paranormal investigator who dotes on his loving 
old ma. She's a bloodthirsty Buddhist magician's assistant from a secret 
island of warrior women. They fight crime!