Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
Double clicking is a pain. Single clicking should switch to a new file.
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.
I'll open another bug about removing the tabs :-).
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 :-)
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?
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.
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.
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.
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.
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.
This bug was targeted for a past milestone, moving to the next active milestone.
I think we already have browser tab style navigation.
No, we do not. Not even close.