Multiple-bar touchbar interface #1801
Conversation
This commit features a workaround due to a garbage collection bug. See AwesomeBar.cs line 41
Scaffolding for multiple touchbars and customization later on
Renamed some of the identifiers in my code to be more clear.
Apple's NSTouchBar guide ominously suggests that the identifiers need to be globally unique, so I added constants for them in the form of "com.MonoDevelop.TouchBarIdentifiers.<Identifier Name>" if you customized the bar in a previous build, you will need to re-customize it to get items to appear again since the identifiers have technically changed.
Previously images were generated every 700 ms when UpdateTouchBar() was called
There is a nasty bug that occurs where after the user dismisses the system's touchbar customization UI, there is a significant chance for all windows on the user's computer to become unresponsive until MonoDevelop is killed. Until this bug is fixed, I've sealed off the customization functionality. (if you can customize the touch bar, changing at least one item, five times in a row without running into this bug then it is probably fixed)
Preliminary support for the debugging controls present in earlier builds has been added back in.
|
Hello! I'm the build bot for the Mono project. I need approval from a Mono team member to build this pull request. A team member should reply with "approve" to approve a build of this pull request, "whitelist" to whitelist this and all future pull requests from this contributor, or "build" to explicitly request a build, even if one has already been done. Contributors can ignore this message. |
This makes use of the assets that were added in the last commit
Previously, the images for the run button were loaded as-is, which resulted in a black-on-black button that looked disabled. I enabled the template image effect, which is better-- the button is at a weird size now, but at least it doesn't look broken. Also fixes a bug in the previous commit where I used absolute URLs to load files-- as in, absolute to my home directory on my computer. I'm so, so sorry about that.
Added a button to start up a new solution from the touchbar on the welcome page. Also removed recent items from the scrollview so it stays fixed in place when the user scrolls.
|
In case of "Debug bar, which presents the debug controls" I would expect at least StepIn, StepOver and StepOut actions... But more in general I don't like how everything is hardcoded for example What should be goal/design of this whole thing is... But for other cases like coding, debugging, unit testing... We should respect layouts: This is important part: |
|
@DavidKarlas Thanks for the feedback. This is very much a "first pass" at the UI so your ideas are genuinely useful. Generating the IDs in a more global way seems like a good idea. Probably make a function that constructs an ID for a Command. It's interesting you brought up unit testing… I wonder what controls would be useful in that context? It's definitely worth brainstorming. The step in-out-over buttons are on the to-do list, but do present a problem in that MD must be in focus to use them, making them marginally less useful. There is a private API Xcode uses to work around this, and since MD isn't in the App Store, we could use it... we just have to be careful to code it so if the API breaks MD isn't negatively affected. Unfortunately Apple's customization UI enforces a finite number of Touch Bar items, so we'd still have to hardcode the subset of commands to expose as Touch Bar controls. It's possible to create our own customization interface but it'd take a lot of work. Apple's customization UI is actually wired up in this build but it's sealed off with an ifdef because it seems to cause the whole app to freeze, some bug in Xamarin.mac I think. |
|
Re-Run last unit test would be good start, maybe navigate to failed test source code... Thats why we need to give users ability to set any command in Preferences... They know what is best for them... About MD needs being in focus, thats not issue, even today MD needs to be in focus to listen to keyboard shortcuts for stepping and stuff, thats not really issue imo. |
|
Yeah, but just to make sure we're clear, there are a finite number of Touch Bar controls we can reasonably display in the customization UI. Think 20 as close to the upper limit. As such can't let the users map to any command without implementing a custom customization UI… and since there is no API to detect the presence of a Touch Bar we'd have to make that interface visible on every Mac, even ones without Touch Bars.
…Sent from my iPad
On Feb 15, 2017, at 1:02 AM, David Karlaš ***@***.***> wrote:
Re-Run last unit test would be good start, maybe navigate to failed test source code... Thats why we need to give users ability to set any command in Preferences... They know what is best for them...
I wasn't thinking specifically about unit testing... I'm just saying it should be generic on per Layout basis...
About MD needs being in focus, thats not issue, even today MD needs to be in focus to listen to keyboard shortcuts for stepping and stuff, thats not really issue imo.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
We can always limit how many commands user can add to not crash TouchBar :) About showing it in Preferences... If there is really no way of detecting if MacBook has TouchBar or not, always displaying it in Preferences is small price to pay... |
|
It's not that adding to many items would cause it to crash, it's just that the UI would require a lot of scrolling. If you haven't seen the touch bar customization menu, it looks like this: http://pgj.cc/OnWjau
That being said, what you're suggesting isn't impossible. Basically we could have a menu in preferences that lets you set which items are available for customization, then the user can invoke Apple's UI and add the items they want. It'd be a bit clunky, and I'm not certain it's the best solution…
Side note, I assume the lack of an API to check for TouchBar is because Apple is entertaining the idea of having Bluetooth keyboards with bars on them, and they don't want apps checking for a touch bar on launch, changing the UI & state, and then nothing works if the user then connects a keyboard with a touch bar.
…Sent from my iPad
On Feb 15, 2017, at 1:15 AM, David Karlaš ***@***.***> wrote:
We can always limit how many commands user can add to not crash TouchBar :)
But in general, assume user will remove commands user doesn't need to make TouchBar useful...
About showing it in Preferences... If there is really no way of detecting if MacBook has TouchBar or not, always displaying it in Preferences is small price to pay...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
That editor looks nice, but I'm not sure if it can handle ~100 commands that we have... We probably also want to give user ability to add commands that are introduced by AddIns... So, we need to give option to add any command in case command doesn't have Icon for touchbar... display Text(name of command) For same reason, we should probably always show Preferences editor for TouchBar, that is not real problem... |
|
I didn't design the customization interface, I have no control over its appearance, that's on Apple. Like I said, we can make our own UI, but that would involve creating a drag and drop interface so that the user can visualize things like spacing. And that would require reimplementing a LOT of stuff. And users would hate the weirdness of the UI. I just don't think supporting every command is reasonable.
…Sent from my iPad
On Feb 15, 2017, at 1:36 AM, David Karlaš ***@***.***> wrote:
That editor looks nice, but I'm not sure if it can handle ~100 commands that we have... We probably also want to give user ability to add commands that are introduced by AddIns... So, we need to give option to add any command in case command doesn't have Icon for touchbar... display Text(name of command)
For same reason, we should probably always show Preferences editor for TouchBar, that is not real problem...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Have you considered making this into a VS for Mac Extension? https://docs.microsoft.com/en-us/visualstudio/mac/extending-visual-studio-mac |
|
Sorry it took me so long to respond. I don't think an extension would work here. There aren't any extension points for the Touchbar, and from my experience with AppKit, I seriously doubt there is a sane way for extensions to add Touchbar support. |
The bug that was caused by entering the customization screen seems to be fixed, enabling it again.
|
Any updates on this? |
Hopefully this pull request isn't too big, but it took me this long to get around to enabling all of the features present in the base fork. The touchbar now presents different bars depending on the context:
*Welcome Page bar, which displays recent solutions from the Welcome Page allowing for easy access
*Text Editor bar, which is basically the main bar, it is intended to be user-customizable, but a bug means that functionality is currently disabled
*Debug bar, which presents the debug controls
*There are references to a Preferences bar, currently unimplemented, which would allow the user to scrub through tabs in the preferences window
Basically this is a first pass at figuring out how the touchbar features would work, both in terms of UI and structuring in code. This feature isn't done, there are definitely still a couple bugs, and I'd like to stress nobody should be afraid to improve upon what I've written here.