Annoucement: Customize UI is probably not going to work anymore

[knopp]

VSCode added a build step that mangles all typescript private fields so they can't be reasonably accessed by Customize UI. This greatly reduces hooks that customize-ui can intercept and methods it can call.

It might still be possible to change font size, but other layout changes are probably gone. Or at least made much more difficult.

[knopp]

This is the PR that broke Customize UI, possibly forever

https://github.com/microsoft/vscode/pull/166126

It was fun while it lasted.

[isidorn]

Hi VS Code PM here 👋

More details about this change and the motivation be found here https://github.com/microsoft/vscode-discussions/discussions/257 We would like to better understand if the Customize UI extension will no longer be able to work. If that is indeed the case (as I believe it is) - we are open to a UI discussion to see if we can make possible some of the most popular Custmoize UI features. We would love to learn more from this extension and identify the gaps and shortcomings in our extensibility story with the goal of making our actual API more rich.

Thanks Isidor

[knopp]

Hi @isidorn,

thank you for stopping by!

CustomizeUI is basically a pile of hacks that works by monkey-patching javascript in browser and main processes, which is something that regular extensions can not do, and probably for a good reason :)

Still, the problem the extension is solving is quite real and a lot of people seem to find it useful.

The primary reason why I wrote the extension was to be able to customize the user interface font and spacing. This is a feature that has been requested for a long time, the issue has over 2000 likes, and sadly it doesn't seem to be addressed any time soon.

Somewhat less important is to customize the rest of user interface. Right now the activity bar and titlebar are taking significant amount of space, especially on laptop screen, being able to do something like this (tabs in title bar and horizontal activity bar) is quite nice:

(sorry for the old screenshot)

And being able to modify the javascript directly allowed me to prototype user interface changes that would have very little chance to actually land in VSCode itself. Even crazy things, like status bar on top (it's actually surprisingly practical...)

[spacepluk]

especially on laptop screen, being able to do something like this (tabs in title bar and horizontal activity bar) is quite nice

FWIW this was the main reason I was using this extension. At least on macOS the default layout wastes a good amount of vertical space.

[isidorn]

@knopp thanks for providing more details and for explaining the use case. We would love to learn more from you about what you think were the most successful UI features your extension did? I personally like the option to show the activity bar as part of the viewlet and I think this is something we should maybe give a try in VS Code.

As for the customising Font Size in the workbench - we are aware of this highly upvoted request, however there are technical limitations that @bpasero explained in that issue. What I would like to understand better is what is the main thing your users gain with being able to configure fonts that "Zoom In" does not give them? In what part of the UI are they most impacted with not being able to configure the font size?

Pinging @daviddossett our lead designer to consider some of the learnings from your extension.

[j-f1]

For me, I largely used Customize UI to move the status bar to the top and inject custom CSS to make some personal preference tweaks to the sizing of items in the UI. I think adding support for custom CSS as a user preference would go a long way toward alleviating the pain of breaking this extension.

I also used monkey-patch (which this extension depends on, and which has also been broken by this update as far as I can tell) in one of my own extensions because custom icon themes are required to bundle any fonts that they depend on, which is not possible for San Francisco due to restrictions by Apple. (I also had to inject some custom CSS because certain icons including the dirty icon on tab titles do not seem to properly use the codicon class name system to pick up custom icon themes).

[knopp]

What I would like to understand better is what is the main thing your users gain with being able to configure fonts that "Zoom In" does not give them? In what part of the UI are they most impacted with not being able to configure the font size?

Back when I wrote customize-ui zoom-in resulted in really bad wobble effect during scrolling for both the sidebar and text editor. That seems to be improved now.

[robertpiosik]

My usage of the extension is about changing font family in the interface (SegoeUI to Google Sans). What led me to this issue is that I found my overwritten ff is no longer applied for the context menu.

[DeltaRazero]

The activity bar just takes up a lot of space and clutters the UX for me, Having it be at the top (or bottom as some people like that too) is much cleaner.

I'm also linking this issue here, where it's already being requested. https://github.com/microsoft/vscode/issues/118692

At least I know I don't have to update my VSCode anymore after the current version until either a workaround is found, or the extremely slim chance this gets implemented.

[robsontenorio]

@isidorn

"Inline titlebar on macOS" is the best feature!

[pje]

@isidorn

"Inline titlebar on macOS" is the best feature!

Agreed! There's a pretty popular issue for that request in the vscode repo: https://github.com/microsoft/vscode/issues/12377

[mfreeman-xtivia]

@isidorn sorry but Boooo Microsoft.

I'm a hard core dev and this extension makes VSCode usuable for me. A whole range of reasons, some already expressed here. Ability to move the activity bar to the top for extra real estate, ability to change the spacing in the sidebar, ability to the change the font of the overall UI, and on and on.

I, like others, will have to stay on 1.73 until I can't stand it any more but without the level of customization this extension provides I find VSCode personally not usable.

I guess will need to go look at what Fleet offers as an alternative.

[robsontenorio]

At this moment monkeyPatch/customize-ui is broken on VSCODE 1.74

[jipika]

What if you want to change the font of the context now

[hmijail]

FWIW, my reason to use MonkeyPatch is the Swipe-To-Navigate extension, which enables back/forward navigation methods like the 3-finger swipe in MacOS: https://github.com/seivan/swipe-to-navigate

[ekwoka]

Sad.

I used the settings from make vscode awesome to completely remove all UI elements except when I expressly wanted them. Now most of them are still hidden by other but I have this ugly gray title bar that isn't doing anything useful....

Before update:

After Update:

[huyz]

Like @hmijail I need monkey-patching to have 3-finger swipe on macOS

[IceSentry]

Personally, I used monkeypatch and customize-ui to fix both of those highly upvoted issues

Pin tab on a second row like full VS: https://github.com/microsoft/vscode/issues/98160

Make tabs vertically smaller because it's just a bunch of wasted space: https://github.com/microsoft/vscode/issues/42253

[kvndrsslr]

While I could live without most of these, it's a big downside to trade in for 5% of startup time (which might be noticable if you are still working on HDDs, but otherwise idk...)

However this one does it for me, staying on 1.73.1 until there's another alternative:

Putting some of these options into core would be very appreciated. There are power users with tiling WMs on every platform, people that choose to not want any frame can live with the implications of not being able to drag & drop windows.

[qyurila]

I cannot live anymore without a wider list row height (28px, which fits my font size -- I made every text 1px bigger). I'd stick with VSCode 1.73.1 for now.

[blackcater]

That's too sad. How about build a unofficial vscode version?

[rustemkk]

+1 to "Boooo Microsoft", you could do better!

The best thing about vscode - extensions and customization. Due to limited vscode UI customization for several years I've been using customize-ui to have the editor that I wanted. Top priority features that I use - font customization (size, font-family, lines spacing, letters spacing) in all parts of vscode (including menu) and ability to make vscode frameless (without title bar).

Sticking to 1.73.1 for now.

[kvndrsslr]

That's too sad. How about build a unofficial vscode version?

You mean https://vscodium.com ? It exists but has it's own challenges cause the VS Code you download from Microsoft is more than the FOSS part and some extensions are only licensed to work with the official version as distributed by Microsoft. If you can live with that you can certainly clone it and change a line in the build scripts to remove the mangling step.

[lehni]

Before customize-ui, there was vscode-titlebar-less-macos of which I am the author, and already then there were discussions with @bpasero to bring this into VSCode properly: https://github.com/lehni/vscode-titlebar-less-macos/issues/34

I still believe that this should be the default VSCode style on Mac, it makes sense on any kind of 16:9 / 16:10 format screen.

Happy to be of help if I can. Until then, I will be sticking to version 1.73.1.

[mattpilott]

@isidorn this is how i utilised this extension, inline title bar, activity bar at the bottom of the file tree

[owenfiscus]

@isidorn Figured I would drop how I used this extension to make my VSCode experience better as well. Would love to see this project live on at least in some form. Thanks for your hard work on a great IDE!

[Mjvolk3]

Expanding Command Palette Size

Some of my markdown notes I create using the Dendron extension have very long titles. With the current command palette I cannot see the difference between the file names.

By expanding the size of the command palette with Customize UI I can see the full title.

[nathanblair]

however there are technical limitations that @bpasero explained in that issue

Did they, though? I searched the whole thread and couldn't find anything. The closest thing to an explanation was (paraphrased from what I remember) "if we allow the font size to be anything then people can make the font too big and mess up the UX" which is frankly ridiculous. They could do that with any of the customizable font options.

What I would like to understand better is what is the main thing your users gain with being able to configure fonts that "Zoom In" does not give them?

I don't wish the entirety of the window to be enlarged. I just want a larger font in the workbench so my aging eyes can read file and folder names. It's a big accessibility issue. When "zoom" is used as a "workaround" it enlarges virtually all of the padding of the entire window. By the time the zoom is at a value that makes the workbench font easier to read, there is virtually no room for the actual editor view itself.

[philippgrimm]

Thank you for your work. Learned about your extension from here https://makevscodeawesome.com/. Used it to make VScode feel like home. Now everything looks like 💩 again 😢

This is what i did:

    "customizeUI.stylesheet": {
        ".monaco-workbench .titlebar": "background: rgb(38, 35, 53) !important;",
        ".monaco-workbench .titlebar > div.window-title": "display: none",
        // Hide top-right buttons
        ".editor .title .actions-container .action-item a": "display: none !important;",
        ".titlebar .window-controls-container": "display: none !important;",
        // Only show the scrollbar on hover.
        ".editor .scrollbar .slider": "visibility: hidden",
        ".editor .scrollbar:hover .slider": "visibility: initial",
        // Change cursor color.
        ".monaco-editor .cursor": "background: linear-gradient(to bottom, #7f00ff, #e100ff) !important; color: #292D3E !important",
        ".merge-accept-gutter-marker": "--vscode-checkbox-border: #3f4357"
    }

Are there any other ways to achieve some of this changes?

[morhekil]

adding my voice here for @isidorn to consider regarding font changes. I use monkey patching extensions to change the font (not just font size - font family as well) of the whole workbench UI, including explorer sidebar and tab titles, and to have the font I need applied consistently throughout the whole UI. This is what https://github.com/microsoft/vscode/issues/519 has been asking about for years, and it's very disappointing to see it being broken with no workarounds – all just in the name of minification and 1.8MB saved.

[archetyped]

@isidorn my primary use of Customize UI is to change the font used in the find/replace fields to a monospaced font, as the standard UI font makes evaluating long regexes quite cumbersome and error-prone.

As many have already noted, support for such functionality (it's not just about font size) within VS Code itself has been a strangely ignored request for a long time (microsoft/vscode#519).

microsoft/vscode#152518 is an open ticket specifically for the find/replace fields.

Unfortunately, I too will have to remain at v1.73 until compatibility is restored or this functionality is added to VS Code directly 😔

[wiidede]

@isidorn It's sad that I cannot change UI font anymore. And the activity bar really take too much space☹️The secondary side bar's style is much better.

[jahirfiquitiva]

Just wanted to share a comparison of Visual Studio Code without and with Customize UI + Monkey Patch

Without Customize UI 😭🥱

With Customize UI 🤩😁

@isidorn I hope the VS Code team brings back whatever is needed for this extension to work. 🙏

[giovanicascaes]

Man, really sad news here =( I'm a heavy Customize UI user. VSCode UI is really ugly in my opinion, so I did a ton of modifications using this extension, making it look like this:

I'll stick to v1.73 as long as I can and will try to switch to CodeEdit when it is released.

Thanks for creating and maintaining this extension for so long.

[fk1blow]

@isidorn really hope vscode team views this as an accessibility problem rather than just a bunch of entitled devs complaining about font sizes, colors and such.

i m too (used to b/c i just upgraded and too lazy to go back to 1.73) using this extension to increase font sizes of very specific areas in vscode, highlight other (increase font size, font weight, etc) specific areas, hide certain ones like the titlebar or segments of the status bar, and the list might go on.

tl;dr it's an accessibility issue that this extension helps rather than estetics

[huyz]

The 1.8MB size savings is definitely not worth all this pain.

[ekwoka]

I mean, it could be, if it was like 2mb.

but vscode is already slow and big.

This change doesn't really kick it into feeling so fast and lightweight. It's still slow and large. Might as well just lean into that and make it ultimately customizable so we don't even need these extensions.

[robertjpayne]

Ughh this is SO lame, I use this extension to provide proper alt + drag column selection to match the likes of Sublime Text and other macOS editors rather than alt+shift+drag.

[mitsukuri]

Hi VS Code PM here 👋

More details about this change and the motivation be found here microsoft/vscode-discussions#257 We would like to better understand if the Customize UI extension will no longer be able to work. If that is indeed the case (as I believe it is) - we are open to a UI discussion to see if we can make possible some of the most popular Custmoize UI features. We would love to learn more from this extension and identify the gaps and shortcomings in our extensibility story with the goal of making our actual API more rich.

Thanks Isidor

Ahaha, nice one, Microsoft! People had been asking for native UI customization options for ages, like, since 2015, gathering thousands of upvotes on those feature requests, but alas!

Instead you've killed the only extension that worked around the lack of customization...

[gee-forr]

I'm pretty bleak about this change. Atom was simply a more visually attractive editor compared to VSCode. VSCode won out due to its superior extension ecosystem among other things. Customize UI allowed me to get VSCode looking a little better and little closer to Atom's aesthetic.

I will unfortunately be joining the majority here and staying on the October release. CustomizeUI is that important to me.

Here's what my VSCode looks like courtesy of CustomizeUI. Beauty is subjective, but I would be hard pressed to find someone who thinks factory-default VSCode is more attractive compared to this

[fk1blow]

@gee-forr as you mentioned, beauty is (very) subjective. Besides aesthetic, this extension allows us to customize the ui to be usable(better contrast between elements, bigger font size where it actually matters, removing title bar, and many more), which is far more important than aesthetics will ever be!

[gee-forr]

@fk1blow For real, I agree that this extension makes things more usable.

However, I don't want to downplay the fact that people are getting value from the extension by making things more visually pleasing, which can be seen as less important than being usable.

Both usability and aesthetics are important, and this extension addresses both these shortcomings in VSCode in a pretty effective manner.

[fk1blow]

@gee-forr in case of an editor, usability will always be more important than aesthetics. What i m trying to say is that, if we keep on pointing to aestethics and not usability/accessibility, vscode team won't listen to our case. In fact, i m using this extension for both accesibility and "beauty", but weighted differently, so not arguing which is more important to you.

[rminami]

This is terrible news. Inline title bar + activity bar at the bottom of the sidebar makes much better use of screen space on macOS, and has made me much more productive when I have to code on the go on my laptop.

I hope this isn't the end but if it is, thank you @knopp for all the hard work you've put into this!

[mitsukuri]

@gee-forr in case of an editor, usability will always be more important than aesthetics. What i m trying to say is that, if we keep on pointing to aestethics and not usability/accessibility, vscode team won't listen to our case. In fact, i m using this extension for both accesibility and "beauty", but weighted differently, so not arguing which is more important to you.

Why will it? Who decided on that?

Me personally, I need to customize my UI because my cat can't stand the default looks and just won't let me code, growling, scratching and biting my screen. Does MS have any moral right to ignore that of a poor animal to purr in peace by my side?

I don't think we could force MS to stop turning a blind eye to the issue, which it has been since 2015, simply by pretending that every upvoter of that feature request had only accessibility in mind. The fact is that people need it regardless of their motivation.

[fk1blow]

@mitsukuri nobody is forcing you to agree with me and no one has pretended that you need to take accessibility as a priority, so your tone is unwarranted. My point was that instead of bashing MS or the vscode team by coming up with "my cat can't stand the default looks and just won't let me code"(which is a silly and childish argument, btw) or other arguments that they might not consider, we could provide a better and more powerful argument, like accessibility.

I don't need to add "IMHO" each and every time i state my opinion, so "Why will it? Who decided on that?" is... anyway, i think we should provide actual reasons for using this extension and not start an argument based on preferences.

[mitsukuri]

... no one has pretended that you need to take accessibility as a priority

Had you not, really?

bunch of entitled devs complaining about font sizes, colors and such

it's an accessibility issue that this extension helps rather than estetics

beauty is (very) subjective

which is far more important than aesthetics will ever be!

in case of an editor, usability will always be more important than aesthetics

I read it as if everyone wanting to please their eye with a custom font, color and such, were but a bunch of entitled devs, and all your subsequent stresses on accessibility trumping everything else only reinforced that connotation.

You also failed a humor comprehension test by thinking that the cat argument was addressed at vscode team.

P.S. Yes I do realize that the context of all those quotes of yours was that the team could see things that way, or that you wished they saw it that way, but why should people pretend that they need this feature in the name of Y when in fact they need in the name of X? What's the use of being dishonest? The team is perfectly capable to reckon the variety of forces that drove this request on their own.

[dcd-arnold]

Switched to vscodium, now a happy customize-ui user again.

[robsontenorio]

@dcd-arnold why does it supposed to work with vscodium?

[michaelklopf]

Maybe the MS devs should read https://makevscodeawesome.com to know why these changes were great.