GNOME Bugzilla – Bug 45202
add a time delayed popup tree view to folders icons
Last modified: 2012-08-13 22:12:15 UTC
From Bugzilla Helper: Add some kind of popup tree view to folders (the popup tree view would look sort of like regular tree view). This popup tree view would pop up after one lefted the mouse pointer over a folder icon for a short time, or it could be activated by the a middle mouse button click. This popup tree view should behave just like the regular tree view, but also folders in said view, should be able to expand in a simular time delayed fashion or by clicking on said folders' expand button with either the left or right mouse button during drag && drop action(ie one would always expand folders with the free mouse button). This would allow one to be able to drag and drop (left click+hold or right click+hold) objects onto sub-folders in that popup tree view. There should also be some kind of a bar on the top side of that popup tree view. A right click + hold and drag on that bar should allow one to either create a new window with the targeted folder, if the "drop" occurs on the desktop, or to partition nautilus view into two if the "drop" occurs in the same window. * REPRODUCIBLE: Always * STEPS TO REPRODUCE: ** folder pop tree view time delayed ** 1) run nautilus 2) leave mouse pointer over a folder this time period should be short but not too short. ** folder popup tree view middle clicked ** 1) run nautilus 2) middle clicking on any folder tree view would popup ** Create new window with targeted folder ** 1) run nautilus 2) cause popup tree view to pop *** by either method *** 3) right click + hold on top bar then drag to desktop new window is created with targeted folder ** Partition nautilus view ** 1) run nautilus 2) cause popup tree view to pop *** by either method *** 3) right click + hold on top bar then drag and drop in the same window nautilus view should be partition into two ------- Additional Comments From sullivan@eazel.com 2001-03-13 08:53:22 ---- This sounds like a novel variant of the Be-style Move To/Copy To menu items with their hierarchical folder selection. Giving to Arlo to think about. ------- Additional Comments From eli@eazel.com 2001-03-26 11:18:56 ---- SPAAAAAAAAAM! (Jon Allen has taken these components; QA Assigning bugs to him.) ------- Additional Comments From arlo@workthatmouse.com 2001-04-09 22:25:47 ---- I think we should do this feature. Pavel and I have talked about it in the past. Pavel... any idea how tough this owuld be to do? ------- Additional Comments From arlo@workthatmouse.com 2001-05-14 04:04:21 ---- I know Pavel doesn't (okay, none of us) work here any more, but whenever his bugs get moved over, this one can tag along... ------- Additional Comments From snickell@stanford.edu 2001-07-23 00:38:52 ---- Taking bugs previously assigned to Pavel, assigning them to myself. Will parse them out at my leisure , but many are GnomeVFS bugs we should look at for 2.0 ------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:48 -------
Changing to "old" target milestone for all bugs laying around with no milestone set.
I have no clue what the usefulness of this is, but it seems like a usability thing.
Its useful because frequently when you pick up a file to copy it, your desired target isn't current visible. This is roughly equivalent functionally to "Spring-Loaded" folders in MacOS. Not sure how I feel about the relative merits of the two, but trees are a convenient interface for navigating and visualizing file heirarchies, so this seems reasonable as an altenative to spring-loading (that said, spring loading has the advantage that it doesn't introduce a new interface element).
Spring folders are requested in bug #44001
*** Bug 140278 has been marked as a duplicate of this bug. ***
*** Bug 143241 has been marked as a duplicate of this bug. ***
This is more or less how the list view works these days (in nautilus CVS).
I don't know about the original author's intentions, but, I'd like to see something analogous available in icon view, as a way perhaps of side-stepping the silly "spring-loaded folders patent." Don't know whether this answers that need or not. I'm rather envisioning this as a pop-up overlay window, more like a pull-down menu than the "expanding" list (tree) view.
> as a way perhaps of side-stepping the silly "spring-loaded folders patent." I'd like to see deveopers do what they do best and implement the best solution available. I'm convinced we need a configure flag of some kind so that we can exclude patented systems oonly in countries that force us to do so and not allow all of Gnome to be dragged down and held back until such time as the legal matters can be resolved. More importantly though I think Microsoft file explorer expands trees if you hover over them for a while. I suspect the patented aspects of Spring loaded folders are very specific and we shouldn't assume they apply without checking or we should avoid checking and risking the legal exposure, it just isn't worth the grief of trying to do a patent check on everything.
Alan: I totally agree with you. I'm especially in favor of a configure flag for patent-related implementations, which will cause endless threads on almost all distro mailing lists - which is a good thing. We really have to ask maintainers whether they are willing to support this step.
how are these discussions valuable?
Apologies for the offtopic discussion but using the bug report to point it out instead of sending a private mail is just as bad as just as offtopic. I think it was offtopic to bring up patents in the first place, but I'lly and try and suggest something to the foundation list about the greater patent issue and legatilities so the nautilus developers can get on with what they do best, developing software.
no need to apologies, my question was for Christian but I've parsed the sentence about distributions wrongly. Anyway the issue should be discussed for GNOME rather for a module so foundation is probably a right place for that, thanks.
It isn't clear to me why this would be any more effective than navigating to a folder in the usual way. Would it be quicker? We already have bugs for quickly accessing recently visited folder on drag and drop folders: such as drop downs on the path bar or using the back history as a drop target.
(In reply to comment #14) > It isn't clear to me why this would be any more effective than navigating to a > folder in the usual way. Would it be quicker? Yes, because when releasing the mouse button, we're supposed to go back to the original location. They're called spring-loaded folders, and might be patented, or not.
Given that we now have Copy To / Move To that don't require DND and that the other part of this proposal seems close to a certain elastic type of folder for which we have a bug open and a host of other issues with... There is no point keeping this open any longer. I'm going to close this won't fix.