Uploaded CLAW again

[Brian J. Tarricone]

going a little backwards -

Chris Brault wrote:

>P.S. 2: Is there any developer out there that gives
>this kind of fast responce and delivery? And who has
>so much fun doing it? Probably not.
>
hehe, certainly looks like you're really into this project - good stuff ^_^.

>>2) when i delete a file in my homedir, it appears to
>>reread the entire directory, taking another 10-15s
>>    
>>
>In preferences there is a setting for that. It is "on"
>by default at someone else's request (on #xfce). Erase
>the ~/.claw/ directory, then check the preferences
>dialog (there's a button on the tool bar). 
>  
>
well that there is.  cool.

>>4) the treeview starts up without any "twisties" to
>>expand branches, so 
>>the folder icons are flush against the left side of
>>the window.  if you 
>>click on a folder, it opens, a twisty appears, and
>>the folders shift to 
>>the right.  not a major problem, but it's not all
>>that aesthetically 
>>pleasing either.
>>    
>>
>
>That is a minor thing there, whether or not to have
>the drop-down arrows. However, the arrows only appear
>when the contents of that directory are listed. So,
>listing the contents of every member of the root file
>system during startup just seemed too time consuming.
>If you press me on this, though I will add an option
>in the preferences for this.
>  
>
what i've seen done elsewhere is one of two things.  one that i'm not 
particularly thrilled with for aesthetic reasons, another that 
unfortunately incurs a bit of a performance penalty. 1) all branches 
have twisties by default, and only by loading that directory (either by 
clicking on the directory or expanding the twisty) do you find out if 
there's actually a branch off there.  if not, the twisty disappears.  or 
2) whenever a tree is expanded (or, on startup, for everything off the 
root), you peek into each subdir and see if there are any directories.  
unfortunately i can't think of a quick way offhand to do this - if you 
peek in and see a directory fairly soon, you're good, but if there 
aren't any directories, you just spent an arbitrary amount of time 
reading the entire directory (however large it is). i wonder how the 
'find' program does searches when you specify '-type d'....

>5) when i click on an icon in the file view, there's
>no selection 
>box/highlight color, so i have no idea which item is
>selected (if there 
>is one at all).  perhaps that's just my theme, but i
>do know that other 
>apps get the highlighting correct.
>  
>
>
>I will add an option for select by "single click" or
>by "shift-click" in the preferences dialog. I just
>think that the shift click makes you think more about
>what you are doing (i.e. safer)
>  
>
i'm not entirely sure what you mean here.  how is it unsafe to click - 
just click - on an icon and see immediate feedback on the selection in 
the form of a highlight or a rectangle around it (or something).  i do 
agree that 'unsafe' actions should be protected, e.g., a delete 
confirmation dialog.

>>7) main toolbar - several of the buttons are
>>toggles, and should be 
>>ToggleButtons rather than regular Buttons
>>    
>>
>
>Aren't we mister picky today ... I use a repeating
>function to create those buttons. That would require
>me making the buttons individually ... it is done (I
>used toggle buttons, so there).
>  
>
hehe.  i don't think it's all that picky - the point of a toggle is that 
when you select it you can tell, at a glance, whether the option is 
selected or not.  otherwise the only way to know, say, if the "auto 
resize" toggle is selected is to go and do something that would cause an 
automatic resize.  somewhat annoying, imho.  the solution to this, i 
think is to make a wrapper function - an example illustrates best (this 
is pseudocode; i don't know python):
create_menu_item(string name, string tooltip, function callback, pixbuf 
icon, boolean is_toggle)
or, if you want to be more flexible, the last parameter can be an enum 
type, of which you have BUTTON_NORMAL, BUTTON_TOGGLE, BUTTON_...

>>8) once i'm in a directory, if i click or double
>>click on another folder 
>>in the tree, nothing happens.  i have to right click
>>and click 'open' to actually get the files.  this 
>>isn't terribly intuitive (or necessary).
>>    
>>
>
>So you want a quick opener instead of a quick browser.
>The idea behind that was that you can go as deep as
>yout want, without committing. Perhaps you just want
>to check to see if a file is there and do nothing. Or
>perhaps you want to explore deeper before opening the
>files. I mean, who decides at which level we auto
>open?
>That is a tough call man. I'll think about it.
>  
>
this goes hand-in-hand with the lack of initial twisties on the 
directory tree.  now that you mention this point about moving about 
whithout committing, i realise where this comes from.  this is totally 
your call - but if you implement something that either always shows 
twisties (until you read the dir and find out if there are or aren't any 
subdirs), or something that peeks into directories on expansion, then 
you can change the behaviour to single-click and still have this option 
to move about without committing.

>>10) when i clicked the "toggles showing hidden
>>files" button, my machine 
>>shot to 100% cpu and the app froze for about 7
>>seconds.  there was only 
>>one file in the directory i had selected (none
>>hidden), so i don't know 
>>what the holdup is.
>>    
>>
>
>Well, it actually reloads the directory to keep the
>hidden files in alphabetical order. You're thinking
>that I should add them to the table without relisting
>the directory in it's entirety. I could write that
>function, but it would be time consuming and this is
>such a trivial matter. I mean, how often do people
>with half a million items with outrageously long file
>names decide to view their hidden directories anyways?
>  
>
yeah, i understand that, and that's correct.  my only issue is that the 
directory i was in _only had one file total_, and it still took 7s or 
so.  perhaps when you are reloading at that point, you reload _every_ 
directory that's open and cached?  seems to me that you'd just want to 
invalidate all cached directories and reload only the currently open one.

>>12) the menu in the tree pane behaves differently
>>than in the file 
>>pane.  in the tree pane, a right click followed by a
>>release causes the 
>>menu to appear, then disappear.  in the file pane, a
>>click causes the 
>>menu to appear, and the release leaves it there
>>(unless you select a 
>>menu item, of course).
>>    
>>
>
>This is it's default behavior, about which I can do
>little. List menu's are different than popup windows
>for gtk.Widgets.
>  
>
hmm, i'm pretty familiar with gtk, and i don't think that that's the 
case.  perhaps the python interface is limited or confusing, or there's 
something obscure to modify the behaviour?

haven't grabbed your new version yet (assuming you've put it up); i'll 
try to give it a look later. i actually very rarely use a GUI file 
manager/browser on linux/unix, but when i'm at a windows box i make very 
good use of explorer.  at first i thought it was lack of a good command 
line on windows, but then i remembered i have cygwin bash installed on 
my windows box at work, so that can't be it.  the only file manager i've 
really used on linux that i don't feel awkward using is xffm really (and 
even then, i still feel like i'd be more efficient just at the cmdline), 
so i suppose i'm always in the market for new file managers that work 
exceptionally well.  so if i sound overly critical, it's not because i'm 
trying to be a pain, it's just because i have a lot of opinions about UI 
design (about file managers in particular), and this topic is somewhat 
important to me.  if i tried it out and thought you had written a crappy 
app, i just wouldn't respond at all ^_~.  keep up the good work.

    -brian