Re: Column view update & issues

[Francesco Fumanti <francesco fumanti gmx net>]

Hello Trevor,


First of all, thanks for implementing the column view.


> For the last two weeks I've been implementing a 
> column view for nautilus.  Most things are 
> working well at this point with mostly hooking 
> up preferences and a just discovered drag and 
> drop issue and the issues in this email left 
> before all functionality is basically working 
> and just bug fixing and tweaking.

I suppose, that you are not talking about the 
issue of the window, containing the source of the 
drag and drop, raising to the front when the drag 
and drop starts!?


> It's to a point where I am using it now as my default view.

I can fully understand that.
:-)


> The real difficulty in implementing a column 
> view is the fact that FMDirectoryView seems to 
> be more designed for view that only show a 
> single directory at a time.  This used to always 
> be the case but since the combined list/tree 
> view it no longer is.  When the new listview was 
> implemented some functionality was added so that 
> multi-directories views could exist.
>
> The biggest problem is that there is no way 
> (that I know of) to change the location from the 
> view (so the pathbar updates) besides to use 
> NautilusWindowInfo and the open_location call. 
> This works but has the side effect that it 
> resets the current view so all current directory 
> monitors are removed and have to be re-added 
> which there isn't a convient way besides the 
> FMDirectoryView add_subdirectory call.  This has 
> the side effect of causing every column in the 
> view to reload. For small directories it doesn't 
> really cause a problem.  But large directories 
> end up taking a long time to load or using the 
> toolbar or the shortcut to move up a can 
> directory cause similar pain.

That seems to be bad news. For the moment, on my 
ubuntu computer, I am using nautilus in list view 
and I already have disabled all previews to speed 
it up. (2.8GHz celeron d)



> This also makes you unable to add new 
> directories to the column and get the properties 
> for the directory that makes up the column 
> (though for properties you can just move the 
> column to the left and select the folder).  The 
> listview simply only adds new subdirectories to 
> the root of the tree  and only changes the 
> location if you open a new folder which then 
> becomes the new root for the tree.

In other words, instead of putting the 
subdirectory in the list, the subdirectory gets 
its own column at the right of the column of its 
parent.

>  As I've implemented the view I've wanted a way 
> to set the location of the pathbar (along with 
> the needed history) but without having to reset 
> the view (ie. don't cause the view to have a 
> begin_loading call and don't remove current 
> monitors, etc) and leave all management to the 
> view (the view can add files with 
> add_subdirectory).
>
> Even adding this the issue of all directories 
> reloading would still exist for typed in 
> location though i think this could be worked 
> around in the view to a large degree (it 
> woudln't be an issue to open location didn't 
> remove all monitors. We can re-add them easily 
> enough but the view could be out of sync if 
> something changed between the time it was 
> removed and added again hence the reason why we 
> need to use the add_directory call to issue we 
> are really in sync).

Unfortunately, I don't have the knowledge to 
fully understand the preceding paragraph. But I 
will try to post a few comments:

I don't know how a typical Nautilus user acts, but I would assume:
- gui users will usually not type in directories; 
if they like to type, they will probably use a cli
- the real usage of the location field will 
probably occur for the copy and paste commands:
-- for the copy command, I think that you took a 
good decision to make the location field update 
with each new column so that the user has the 
complete path.
-- for the paste command, I am asking myself: 
When typing/pasting a location, for example 
/home/donald/documents/letters/, does the column 
view build up all the 4 columns home, donald, 
documents and letters? Or does it only build one 
column, in my example, the letters column? I 
don't have a definite opinion about this; may be 
leaving the choice to the user in the preferences.


>  We could always just not allow the properties 
> and creating folders and live with the reloading.

Again, I afraid that I don't have the knowhow to 
understand what you mean. Probably, because I 
don't know exactly what you mean by the terms 
properties, view, monitor,...

Anyway, in my opinion, speed should be an 
important criterium in the decision taking.


>  Eitherway i hope to have the code cleaned up 
> this weekend or the first of next week and hope 
> to get something at least available in bugzilla 
> or on the list for others to try.

May be a few words about the usage from my point of view:
- the user should be able to scroll any column up and down at any moment
- when the user clicks on a folder and there is 
no room on the right for a new column, all the 
columns should scroll to the left to make room 
for the new column
- I suppose that at the left of the first column, 
there is a static pane/column with all the 
available volumes. I would really appreciate if 
the user could also add applications (in reality 
links, representations,  references,...to 
applications) to that pane. If the user adds for 
example an editor to that pane, he can simply 
drop a document from a directory column on the 
editor to edit the document. This is very 
convenient.


Finally, even though I was not able to respond to 
your specific question, I hope that this answer 
can nevertheless be useful to you.

Have a nice day.

Francesco Fumanti