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 -- nautilus-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/nautilus-list
