[Thunar-dev] Proposed preferences for Thunar

[Benedikt Meurer]

Ori Bernstein wrote:
>>I'm more in favour of using dedicated icon sizes (from the 
>>implementations POV). And adjusting icon sizes doesn't seem to be 
>>necessary IMHO. It sounds more like a hack to work-around badly choosen 
>>defaults. I'd say
>>
>>  details/treeview - 22px
>>  iconview (vertical/horizontal) - 48px
>>  thumbsview - 128px
>>
>>is pretty ok for everyone.
> 
> Maybe. Then again, some people will find some of (eg: thumbsview) sizes too
> large, and would want to see the more images at once when finding one, while
> older people (like my great- aunt or grandfather - I've been teaching them
> computers recently) will be squinting at the listview. Even if it doesn't make
> it into the options pane, I think it should be a hidden option. 

A hidden option sounds ok.

>>That won't work with the default treeview widget. We'd need to write our 
>>own treeview, which is really something for Thunar 2.0 (not sure if we 
>>need this anyways, IIRC somebody suggested something similar for 
>>nautilus some time ago).
> 
> Yeah. I was sorta hoping it wouldn't be too hard to get the grouping to display
> that way, but I wasn't holding my breath.

Weird. Somehow I was under the impression that the Nautilus people came 
up with this idea. Now I just realized that Windows Explorer has that 
already since 2003. ;-)

Anyways, it can be done as a custom view if somebody wants it, but the 
default views most probably will be GtkTreeView/ExoIconView-based ones, 
which don't support this kind of grouping.

>>>Directories Spring Open After <slider from 100ms to 2 seconds>
>>>    - Auto-opening directories like ROX. Makes DND easier.
>>
>>Hmhmh... sounds useful. Tho, dunno if it necessary to have an option for 
>>the time.
> 
> Maybe not. Maybe it should be a toggle, or a hidden option. I don't know, but I
> definitely want the feature there.

Hm, just tried this feature with ROX and Konqueror: ROX pops up a new 
window some times or opens the new folder in place, need to check the 
source for the exact condition. Konqueror seems to always open the 
folder in place, tho, it doesn't seem to always do it, e.g. if I move 
the mouse with the dragged item over a folder in the tree pane, it 
sometimes opens that folder in the main view, but not always. Once the 
drop is done, ROX closes the window if it opened a new one, while 
Konqueror jumps back to the drag folder. Rather confusing. I expected it 
to stay at the drop folder because that's the place I wanted to operate.

 From a first sight, very confusing in both ROX and Konqueror. We'd need 
to come up with a sane way to do this, where you don't need to check the 
source to see how it's supposed to work, if we want this feature.

>>>    I also wonder if it's a good idea to store per-directory preferences 
>>>    (window size/position, view type, etc) in metadata if extended attributes 
>>>    are available. IMO, it would make for a nicer user experience.
>>
>>I have no clue about this. I also thought it is very confusing if one 
>>selects 'Icon view', then enters another directory and the file manager 
>>switches to 'Tree view' and you'll have to select 'Icon view' again. 
>>This is one point that drove me nuts while testing stuff in nautilus (it 
>>is also one of the things I really dislike about Windows Explorer). But 
>>maybe its just me. Is there any hidden concept behind this that I don't 
>>know of?
> 
> Well, if I have an "Images" folder, chances are I want to always view it as a
> thumbs view, and so on. Maybe "Remember View Type" should be an option too?

Not another option. ;-)

I guess the behaviour is ok, as that's what most file managers do. Just 
the condition *when* to store the properties for a folder needs to be 
sorted out.

>>>>    - Currently, if you click on a pathbar button which is a superdir of your 
>>>
>>>      current location, the subdirectories of the dir you clicked in disappear
>>>      from the pathbar.
>>>
>>>      Not only is this inconsistent with the GTK filechooser, it makes the
>>>      pathbar less useful,  since if each button represents a directory and 
>>>      can accept drags, you could put a file into the directory from which 
>>>      you just came, or rapidly switch back and forth, or many other uses.
>>>      
>>>      I think the pathbar should check if the current location is a subdir of
>>>      the directory it's changing to. If it is, it should leave the buttons
>>>      alone, else it should clear them.
>>
>>This was changed per botsie's request. IIRC the exact reason was that 
>>it's too confusing for a file manager. Anyways, I don't have any real 
>>opinion here, but whatever the solution will be, it should be targeted 
>>at easy, intuitive usage, not necessarily power users.
> 
> Definitely. However, I think that Thunar should behave a fair bit like the GTK
> file chooser, which implies that the button bar should act like the GTK file
> chooser. Consistency and all that good stuff =P.

Ok, I changed that to act like GtkFileChooser now. :)

greets,
Benedikt