Re: Come fix bugs! (Batteries included)

[Alexander Larsson <alexl redhat com>]

On Sat, 2004-10-09 at 12:35 +0200, Danny Milosavljevic wrote:
> Hi,
> 
> Am Mittwoch, den 06.10.2004, 15:48 +0200 schrieb Alexander Larsson:
> > [...]
> 
> > * history dropdown in Open Location dialog
> > Add a history of recent locations to the Nautilus Ctrl-L Open Location
> > dialog. A good place for this is in nautilus-location-entry.c, which
> > is also used on the toolbar in browser mode and for entering raw uris
> > in the connect to server dialog
> 
> Where to save the history items, where to get them from, will they be
> shared with other components ? Is using gtk_entry_completion ok ?

Where to save is a bit compliated. gconf might not always be save:able.
On the other hand, when it isn't it might be because you don't want to
save such state to the next user (say, in a kiosk situation). Also,
gconf isn't ideal for storing structured things like this (we need to
save time-of-use and the uri). But nevertheless, perhaps gconf is the
best way?

How is epiphany storing this for the location bar? I guess they save the
whole history and use that...
 
> > * DnD drop on window should be more obvious
> > When you drag and drop a file to a Nautilus window the only way you
> > can see if the drop will succeed is by looking at the cursor. We
> > should be highlighting the frame around the directory view when you
> > hover over the view and the drop will be accepted.
> 
> Tried that but seems the entire file for drag&drop window special
> actions is there and has been disabled. Maybe there was a reason :)
> 
> libnautilus-private/nautilus-drag-window.c:
> nautilus_drag_window_register: 'return' statement at the beginning
> 
> Please confirm :)

No. This is unrelated. drag-windows was a hack to try to make drag from
a window not automatically pop the window to the front.
 
> > * 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.
  
> > * 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.

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


Why the file_ok variable? And why check size? its an usigned, so it
can't be negative, and reading a file of zero bytes should be harmless.

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

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a fast talking moralistic cop with a robot buddy named Sparky. She's a 
time-travelling gypsy stripper living homeless in New York's sewers. They 
fight crime!