You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add support for icons for TouchBar submenus (and maybe other customizations) #1105
According to the code, :menu doesn't support setting an icon for touchbar submenus.
For example in the hypothetical nested menu TouchBar.Example.Thing, TouchBar.Example can only be plain a plain text (or emoji) button, but TouchBar.Example.Thing could have an icon declared in the :menu command that defined it.
The (semi) original touchbar implementation (#715) suggests using the macmenu command to support extra customization options.
Yes that's correct. Thinking more about it I think just fixing Vim's :menu variants to be able to set icon on TouchBar subfolders may be better and more consistent for users instead of having to learn a new thing.
I haven't quite decided on them, but yes, maybe. The macmenu command is always a little odd and I would like to keep things as consistent as possible. So if you define icons through the normal :menu commands for toolbar and non-subfolder Touch Bar items, then ideally that's the way we define icons for Touch Bar subfolders too, just to reduce the cognitive load. I haven't looked at the code yet though, so I don't have a sense how big a refactor from upstream that is. It's likely that it's a simple check that we just need to fix.
Some other special items like the emoji picker is specified by special menu item names, like amenu TouchBar.-characterpicker- <Nop> or -flexspace-. Those probably won't fly for color and priority though. I think priority is relatively low in usefulness because you can always choose to enable/disable menu items, but if we have a generic way to hook it up, why not.
Maybe not entirely on topic but is it possible to update touchbar names dynamicaly during one session? Like when I i press button name1 it changes to name2?
@DesantBucie You need to debug your script more and make sure it works before even trying out the fancier Touch Bar label functionality. I don't think your script currently works at all.
You can't put spaces after "=" in set tabstop = 2(it should be throwing errors at you). You have to do set tabstop=2.
You are not invoking the tmenu command inside the function so it's not going to magically update the label for you after you call TabSpaces().
Your menu is calling :TabSpaces which assumes TabSpaces is a command, but it is a function instead. You need to be doing :call TabSpaces()<CR> instead.
Try to use nnoremenu instead of nmenu because it's more foolproof. If you don't mind it showing up in other modes (insert, command, etc), you could consider using anoremenu.
I fixed 1,2,3, put both tmenus to function, got "default" one on vimrc and it works like magic. And no I wanted it to be available only on normal mode so it's fine. Thanks awfully for your time.
Sorry to just hop in here, this could possibly be a separate issue, but is related to icons. In the toolbar and Touch Bar would it be possible to add SF Symbols support? So you could do something like:
@destructobeam, #1329 will add the ability to use SF Symbols for tool bar and Touch Bar icons! This includes the ability to customize the symbol to use palette color etc.
As for the original request, @jabrouwer82 , submenu icons isn't supported yet. I may eventually add this but there are a lot of other things on my plate that are higher priority MacVim-wise. One compromise is that SF Symbols can be used in raw text form. You can actually copy the symbol out and paste it in as text (easiest way to do so is by using the SF Symbols app that you can download from Apple). For example, you can do this to make a submenu with the SF Symbol "gearshape.2.fill" as the icon for it: an icon=arrowshape.backward TouchBar..Back <Nop> (you may need to copy the string out to a text edit program to see this as web browser doesn't show it correctly). It doesn't work as well as specifying a symbol using icon=, because the OS treats the symbol as text rather than an icon so it looks a little smaller, but it works. You also cannot customize the style of the symbol (e.g. palette, multicolor, etc) unlike using the icon= syntax as introduced in #1329. So it's not a slam dunk.
With the release of the M3 14" MacBook Pro, Apple has officially stopped making any new hardware that has a Touch Bar, with the M2 13" MacBook Pro being the last product that had it. Because of that, there will be no more effort put in for new Touch Bar features, sorry.
Meanwhile, 🪦🫗 Touch Bar. I personally liked it despite it being a little polarizing and seemed to never really catch on with other third-party apps (or even first-party Apple ones).
@ychin Late reply, but just a thanks for your work on this. I too liked the touch bar, a lot, and I will miss it. I feel like the disdain for it from a few popular commentators/podcasters killed this very useful feature.
Activity
ychin commentedon Oct 7, 2020
Yes that's correct. Thinking more about it I think just fixing Vim's
:menuvariants to be able to set icon on TouchBar subfolders may be better and more consistent for users instead of having to learn a new thing.jabrouwer82 commentedon Oct 8, 2020
But other options like color, priority, etc, would probably need to be something special, right?
ychin commentedon Oct 8, 2020
I haven't quite decided on them, but yes, maybe. The
macmenucommand is always a little odd and I would like to keep things as consistent as possible. So if you define icons through the normal:menucommands for toolbar and non-subfolder Touch Bar items, then ideally that's the way we define icons for Touch Bar subfolders too, just to reduce the cognitive load. I haven't looked at the code yet though, so I don't have a sense how big a refactor from upstream that is. It's likely that it's a simple check that we just need to fix.Some other special items like the emoji picker is specified by special menu item names, like
amenu TouchBar.-characterpicker- <Nop>or-flexspace-. Those probably won't fly for color and priority though. I think priority is relatively low in usefulness because you can always choose to enable/disable menu items, but if we have a generic way to hook it up, why not.DesantBucie commentedon Oct 15, 2020
Maybe not entirely on topic but is it possible to update touchbar names dynamicaly during one session? Like when I i press button name1 it changes to name2?
ychin commentedon Oct 15, 2020
Use
:tmenuDesantBucie commentedon Oct 18, 2020
Yea I tried, but it does not seem to update in the same session. Anyway thanks :)
ychin commentedon Oct 19, 2020
@DesantBucie that should not be the case. Do you have the exact sequence of commands you used?
DesantBucie commentedon Oct 19, 2020
Well I tried something like this
ychin commentedon Oct 19, 2020
@DesantBucie You need to debug your script more and make sure it works before even trying out the fancier Touch Bar label functionality. I don't think your script currently works at all.
set tabstop = 2(it should be throwing errors at you). You have to doset tabstop=2.tmenucommand inside the function so it's not going to magically update the label for you after you callTabSpaces().:TabSpaceswhich assumesTabSpacesis a command, but it is a function instead. You need to be doing:call TabSpaces()<CR>instead.nnoremenuinstead ofnmenubecause it's more foolproof. If you don't mind it showing up in other modes (insert, command, etc), you could consider usinganoremenu.DesantBucie commentedon Oct 19, 2020
I fixed 1,2,3, put both tmenus to function, got "default" one on vimrc and it works like magic. And no I wanted it to be available only on normal mode so it's fine. Thanks awfully for your time.
destructobeam commentedon Feb 6, 2021
Sorry to just hop in here, this could possibly be a separate issue, but is related to icons. In the toolbar and Touch Bar would it be possible to add SF Symbols support? So you could do something like:
ychin commentedon Feb 8, 2021
Yeah it's something on my mind. I will likely touch these after the next release. It will also make the toolbars look better and fit macOS 11 better.
Add SF Symbol support for tool bar, Touch Bar, menu icons
ychin commentedon Oct 30, 2022
@destructobeam, #1329 will add the ability to use SF Symbols for tool bar and Touch Bar icons! This includes the ability to customize the symbol to use palette color etc.
As for the original request, @jabrouwer82 , submenu icons isn't supported yet. I may eventually add this but there are a lot of other things on my plate that are higher priority MacVim-wise. One compromise is that SF Symbols can be used in raw text form. You can actually copy the symbol out and paste it in as text (easiest way to do so is by using the SF Symbols app that you can download from Apple). For example, you can do this to make a submenu with the SF Symbol "gearshape.2.fill" as the icon for it:
an icon=arrowshape.backward TouchBar..Back <Nop>(you may need to copy the string out to a text edit program to see this as web browser doesn't show it correctly). It doesn't work as well as specifying a symbol usingicon=, because the OS treats the symbol as text rather than an icon so it looks a little smaller, but it works. You also cannot customize the style of the symbol (e.g. palette, multicolor, etc) unlike using theicon=syntax as introduced in #1329. So it's not a slam dunk.ychin commentedon Oct 31, 2023
With the release of the M3 14" MacBook Pro, Apple has officially stopped making any new hardware that has a Touch Bar, with the M2 13" MacBook Pro being the last product that had it. Because of that, there will be no more effort put in for new Touch Bar features, sorry.
Meanwhile, 🪦🫗 Touch Bar. I personally liked it despite it being a little polarizing and seemed to never really catch on with other third-party apps (or even first-party Apple ones).
destructobeam commentedon Feb 28, 2024
@ychin Late reply, but just a thanks for your work on this. I too liked the touch bar, a lot, and I will miss it. I feel like the disdain for it from a few popular commentators/podcasters killed this very useful feature.