Bug 457 - Single click to switch files
Summary: Single click to switch files
Status: RESOLVED ANSWERED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: General ()
Version: 2.8 Alpha 2
Hardware: PC Mac OS
: Normal enhancement
Target Milestone: master
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2011-08-25 18:44 UTC by Nat Friedman
Modified: 2016-12-14 16:56 UTC (History)
7 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED ANSWERED

Description Nat Friedman 2011-08-25 18:44:36 UTC
Double clicking is a pain. Single clicking should switch to a new file.
Comment 1 Mikayla Hutchinson [MSFT] 2011-08-25 18:52:31 UTC
This won't be usable until we implement browser-style document navigation. It'll be easy accidentally to open ridiculous numbers of tabs, and tab management is already dire. When we have browser-style document navigation, I agree absolutely. And that can't come soon enough.

http://monodevelop.com/Developers/Tasks/General/Workspace_Usability_Overhaul#_task_a_General.Wb.BrowserLikeNavigation
Comment 2 Nat Friedman 2011-08-25 18:54:47 UTC
I'll open another bug about removing the tabs :-).
Comment 3 Mikayla Hutchinson [MSFT] 2011-08-25 18:59:57 UTC
Beware it's a pretty large task - to do it without breaking lots of things, we need to rework MD's document and navigation model, so at least a couple of weeks - but it's been the #1 item on my wishlist for about a year :-)
Comment 4 Nat Friedman 2011-08-25 19:01:30 UTC
I'm not sure why we can't just remove the tabs and make single-clicking switch files. You're saying that MD's internals are too inflexible to make that easy?
Comment 5 Mikayla Hutchinson [MSFT] 2011-08-25 19:30:30 UTC
You could do that trivially, but there are a lot of subtleties. The biggest issues are that users will no longer have a way to know which files are unsaved, and memory use would balloon because files (and corresponding widgets) would never get closed. Then you have to consider the effect on the document switcher (control-tab), and the impact on how people actually switch beween "current" files.

We could probably get something usable done in a couple of days and polish up the UX in a week, and do things like browser-style tabs (i.e. with separate navigation histories) and memory reduction (split buffers and view state from the widgets so we can discard more) later, but please read my link, and don't underestimate it.
Comment 6 Miguel de Icaza [MSFT] 2011-08-29 18:22:31 UTC
This would only balloon if users accidentally click on the wrong file, and that is likely less common than single stepping through your source that opens a lot of files during that process.
Comment 7 Mikayla Hutchinson [MSFT] 2011-08-29 18:47:36 UTC
There are plenty of ways for this to become annoying if it's not done right. For example, if I right-click on a file to use the context menu, it becomes selected, but the chances I want to open it are near-zero. Also, if a file opens in an external or a "special" editor such as the Xcode integration, context would immediately switch away from MD, which would be a nasty surprise. And I don't think there's any way to avoid being annoying in the use cases where users select the file but don't wish to open it, for example when they want to run a command, such as cut/copy. And of course, the user might be beginning a drag event. And those are only the thing I can think off off of the top of my head, so I'm sure it'll need some tweaks once it's done.

Anyway, at the very least this means you cannot use the treeview's selection or activation events. You need to track the left mouse down event and left mouse up event and confirm that they resolve to the same item in the tree, and that a drag event did not start. Then, if the item has a default viewer and it's an internal viewer, open it.
Comment 8 Miguel de Icaza [MSFT] 2011-08-29 22:06:02 UTC
That is a very valid point, so a quick solution would likely be something we regret.

Changing the milestone to 2.10, so we can sort out the actual details then.
Comment 9 Nat Friedman 2011-08-29 22:19:37 UTC
When the time is right, I recommend looking at the way TextMate handles all these things. It feels very natural to me and single click opens the file.
Comment 10 PJ 2013-11-19 16:32:24 UTC
This bug was targeted for a past milestone, moving to the next active milestone.
Comment 11 Marius Ungureanu 2013-11-23 09:37:53 UTC
I think we already have browser tab style navigation.
Comment 12 Mikayla Hutchinson [MSFT] 2013-11-23 15:00:57 UTC
No, we do not. Not even close.