Memyandi42 / gnome-menu-file-browser-applet

Automatically exported from code.google.com/p/gnome-menu-file-browser-applet
0 stars 0 forks source link

Option to only show folders? #19

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. open the menu.
2. mouseover a folder with a large number of files.

What is the expected output? What do you see instead?

The expectation is for the menu to stay responsive, somehow.  What happens 
is that displaying a menu for a few hundred files takes a long time*.  
Provided it can't be easily sped up to deal with lots of files** an option 
to give up and maybe give a count instead of list them all, and let the 
user open the folder in nautilus*** might be preferable.  

* real wall clock twiddling the thumbs time with the panel unresponsive
** which is understandable, of course
*** through the usual method of the applet, not an error dialog or 
anything.  the idea here being speed and unobtrusiveness, after all.

What version of the product are you using? On what operating system?

0.5.3, from the .deb, on Ubuntu 7.10

Please provide any additional information below.

Maybe I'm wrong and only listing the folders won't save any time, I don't 
know where the bottleneck is, and I suppose if it's getting the folder 
listing in the first place, it won't do any good to trim it afterwards.  
I, a lowly user, will not presume to know the easy answer.  I'm just 
suggesting a compromise I'd be happy with if it sped things up a bit.

Additionally, I might just prefer an option to -never- list files, only  
folders, and/or let a click on a folder open it, rather than a click on 
its listing inside itself.  That would make for uncluttered and hopefully 
zippy drill down (sorry for the buzz...) to open the working folder.  A 
bit like a graphical version of 'cd Documents/ClarkAccount/2007/'

Apologies for the feature request.  I know they're a nuisance while you 
try to just get things working in the first place, I just figured it made 
no sense to sit on the suggestions.  Ignore all this if it suits you, and 
thanks for the work so far, it's a new favorite.

Original issue reported on code.google.com by Peter.J....@gmail.com on 21 Nov 2007 at 9:40

GoogleCodeExporter commented 9 years ago
Hi There,

I thought about this option when adding the show/hide hidden files option and 
decided
against it. I could think neither of a use case that really called for this, or 
a way
to implement the feature such that you wouldn't constantly be toggling this 
setting.
I guess one option would be to show a maximum of (say) 100 files/dirs and 
include a
"show/all" or "show remaining x entries" button at the end that would populate 
the
menu with the remaining entries. Though I agree that opening directories with a 
large
number of files is slow, if you know you're going to open nautilus or whatever 
in the
end, you might as well do it from the start.

Convince me otherwise.

Original comment by bertol...@gmail.com on 21 Nov 2007 at 7:42

GoogleCodeExporter commented 9 years ago
Hey Peter,

I should have read the rest of your post before replying!!! I do not know if the
bottleneck is getting the folder contents or creating the menu, but it would be 
very
interesting to find out. As for your suggestion to open a folder by clicking on 
the
folder menu-item (not the self referencing folder header), I originally wanted 
the
applet to work this way, but gtk does not support this behavior (see issue 7). 
In the
end you would still have to display the contents of the directory to open it, 
and if
the directory contains a large number of directories, you still (after a lot of 
work)
have the same problem.

Maybe the option I mentioned in the previous solution would be a better 
solution. And
 some profiling to highlight the bottleneck would definitely be good.

Original comment by bertol...@gmail.com on 21 Nov 2007 at 7:51

GoogleCodeExporter commented 9 years ago

Original comment by bertol...@gmail.com on 6 May 2008 at 10:59