Annoucement: Customize UI is probably not going to work anymore
knopp opened this issue · 199 comments
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.
This is the PR that broke Customize UI, possibly forever
It was fun while it lasted.
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
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...)
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.
@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.
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).
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.
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.
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. microsoft/vscode#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.
"Inline titlebar on macOS" is the best feature!
"Inline titlebar on macOS" is the best feature!
Agreed! There's a pretty popular issue for that request in the vscode repo: microsoft/vscode#12377
@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.
At this moment monkeyPatch/customize-ui is broken on VSCODE 1.74
What if you want to change the font of the context now
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
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:
Personally, I used monkeypatch and customize-ui to fix both of those highly upvoted issues
Pin tab on a second row like full VS:
microsoft/vscode#98160
Make tabs vertically smaller because it's just a bunch of wasted space:
microsoft/vscode#42253
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.
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.
That's too sad. How about build a unofficial vscode version?
+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.
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.
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: lehni/vscode-titlebar-less-macos#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.
@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!
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.
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.
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?
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 microsoft/vscode#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.
@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 😔
@isidorn It's sad that I cannot change UI font anymore. And the activity bar really take too much space
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. 🙏
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.
@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
The 1.8MB size savings is definitely not worth all this pain.
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.
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.
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...
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
@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!
@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.
@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.
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!
@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.
@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.
... 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.
Switched to vscodium, now a happy customize-ui user again.
@dcd-arnold why does it supposed to work with vscodium?
Maybe the MS devs should read https://makevscodeawesome.com to know why these changes were great.
This is really sad, this plugin was the entire reason I used VS Code over Atom.
I have been using this hack for several years now, in order to make the file tree use a slightly larger and monospaced font (because a proportional font for filenames doesn't make any sense), as well as making folders use a slightly brighter and bold font for readability (otherwise I find the file explorer drastically harder to use).
I do not want to "zoom in/out" which was a suggested alternative, I want to be able to fully customize the fonts in use in the sidebar.
I will also be staying on 1.73 until I can achieve the same in a newer version (I've tried upgrading, and reapplying the Monkey Patch extension necessary for Customize UI resulted in a broken setup that won't start - so I had to downgrade).
...we are open to a UI discussion...
Your actions so far do not demonstrate you are open to this, as the issue microsoft/vscode#519 has been open for 7 years. Note that this is issue number 519, whereas the issue numbers are currently around 168000. It is also the second most popular (by any measure) issue on that repo.
So many people have been asking for this feature, yet you prioritize an inconsequential performance improvement which disables the only workaround we had for such personal UI fixes. Your users are mostly developers, and developers want to be able to tweak their tools as it affects their productivity. If you are for whatever reason unable to prioritize implementing popular requests, the least you can do is avoid making changes that reduce the hackability of VS Code.
Hi @isidorn, my main reason for using Customize UI has been the ability to change the font of the UI. I think it's obvious fonts impact the user's experience of a product like VS Code, a tool they spend hours looking at each day.
The fact fonts are customizable in the editor demonstrates Microsoft knows that this is an important feature. Why the feature has been limited to the editor boggles the mind. As @knopp mentions above, this is a feature (requested in 2015) has over 2,000 likes so some movement on this would be appreciated.
I used the extension only to remove the titlebar on macOS.
It seems some are saying above that this works in VSCodium. Is this true? What are the benefits and drawbacks of switching to Codium?
After looking into it a little bit, I guess the idea is that one could simply patch the build script for Codium so that the mangling doesn't happen. Then customize-ui should still work.
I am curious what @knopp thinks of this idea. I see that @kvndrsslr is saying above
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.
Would be good to know which extensions we are talking about as well.
This is sad news. Make VsCode awesome and Customize UI + Monkey patch is the reason I switch from sublime text to VsCode. thanks, @knopp for this extension and the hard work you put into it.
The ability to change the font family of the UI that customize-ui provided is very important for me.
It seems some are saying above that this works in VSCodium. Is this true? What are the benefits and drawbacks of switching to Codium?
@battaglia01 Hey! I have tried VSCodium but VSCodium doesn't have support for WSL. Better idea would be to use 1.73.1 version and turn off auto-updates - https://code.visualstudio.com/updates/v1_73
For me, the best feature is moving the activity bar at the bottom of the sidebar. It take us so much less space and is far neater than the default and I personally couldn't use VS Code without it. I can't migrate to another code editor easily because the remote WSL2 extension isn't open-source so I either have to lose Customize UI or stick with an older version of VS Code.
Thanks, @0xMukesh for providing the link to the downgraded version.
It seems some are saying above that this works in VSCodium. Is this true?
It's not true, I just checked and it doesn't work in VSCodium 1.74, it breaks in exactly same way. I just reverted to VSC 1.73.1 but I guess it is time to search for alternative of VSC.
@isidorn I use it to change the font family in other places in addition to the editor (side bar, status bar, etc) and also to apply custom styles (CSS) to change some items in the UI. There's a lot of elements that takes up too much space like the title bar, this extensions allows us to have it inline which is awesome.
Its weird why such a small gain in perfomance (~5% faster startup) had to cause this huge breaking change. The trade off does not seems worth it.
I'm also going to stick with the 1.73 for now then.
@robsontenorio I got an older version, since I could not get an older version of VSCode in my hands that quickly.
see microsoft/vscode#168671
Maybe there is an opportunity for official support?
Another thought for @knopp and others: isn't it possible to simply create a map, automatically, from the original names back to the mangled names?
All of this mangling is done totally transparently in source, right? There is some part of the build script that mangles stuff. So it seems as though it would be a trivial exercise to figure out what the mangled names are and then have the plugin go on as usual.
Thoughts?
@battaglia01 pretty sure the mandling is non-deterministic.
Like maybe in an update it would always mangle in the same way, but if an update adds one more property somewhere, then the mangling could provide totally different results.
Correct, but in theory, if one had some kind of database of original names to mangled names, one for each version number, the plugin could still work. Right?
Switched to vscodium, now a happy customize-ui user again.
Fair to say you were using the version before they merged upstream changes? Because it's broken my Codium install. Otherwise how did you get Codium working please?
Fair to say you were using the version before they merged upstream changes? Because it's broken my Codium install. Otherwise how did you get Codium working please?
@binaryben exactly. I did not check version numbers. It was an older version.
This is the last version of VScodium that works: https://github.com/VSCodium/vscodium/releases/tag/1.73.1.22314
Switched to vscodium, now a happy customize-ui user again.
Fair to say you were using the version before they merged upstream changes? Because it's broken my Codium install. Otherwise how did you get Codium working please?
You can patch the changes out of the build. It's pretty straightforward, but it is a bit of work.
@hammypants I just did this, and got it working! First, my PR at iocave/monkey-patch#58 needs to fix monkey-patch,
then my vscodium patch at VSCodium/vscodium@master...forivall:vscodium:monkey-patch
vscodium: patches/user/disable-mangling.patch
diff --git a/build/lib/mangleTypeScript.ts b/build/lib/mangleTypeScript.ts
index 214deec0aef..f8302ddd610 100644
--- a/build/lib/mangleTypeScript.ts
+++ b/build/lib/mangleTypeScript.ts
@@ -138,9 +138,7 @@ class ClassData {
}
static _shouldMangle(type: FieldType): boolean {
- return type === FieldType.Private
- || type === FieldType.Protected
- ;
+ return false; // no mangling
}
static makeImplicitPublicActuallyPublic(data: ClassData, reportViolation: (what: string, why: string) => void): void {
@@ -179,6 +177,8 @@ class ClassData {
data.replacements = new Map();
+ return; // skip mangling completely
+
const identPool = new ShortIdent(name => {
// locally taken
@@ -432,6 +432,7 @@ export class Mangler {
};
for (const data of this.allClassDataByKey.values()) {
+ continue; // skip mangling
if (hasModifier(data.node, ts.SyntaxKind.DeclareKeyword)) {
continue;
I'm not sure if all of the disabling lines are needed; I added them as i wrote the patch before i fixed the issue at iocave/monkey-patch#58
then my vscodium patch at VSCodium/vscodium@master...forivall:vscodium:monkey-patch
I wonder if this could be feature-flagged and submitted to VSCodium?
@isidorn Thanks for stepping by and showing your interest in actual use cases. I am using Customize UI to move the editor action buttons from the tab bar to the breadcrumb bar:
Having the buttons in the tab bar makes tabs jump around, as reported in this open issue.
From a semantic perspective, the actions belong to the currently shown file. The tab bar contains a collection of files, though, so it is confusing to have the action buttons share the space with the open tabs anyway.
Like so many, my use case is to modify the UI font / sizes.
Sad day to see this disappear.
It was fun while it lasted.
Thanks for the good times, @knopp!
@isidorn Personally, I used this extension to widen the command palette. My project files tend to have similarly named files with long relative path names, so I used this feature to help me distinguish one file from another, at a glance.
As silly as it is, this is a large enough inconvenience for me that I'll be reverting to 1.73.1 for the time being.
There's an open issue for this feature to be added to VSCode, here:
microsoft/vscode#85374
The feature request above was added to the backlog almost 3 years ago, yet hasn't been addressed since. I'm not pointing this out just to complain - I appreciate the work that's done to actively support VSCode and attempt to improve it, release after release.
I'm just saying that I have very little confidence, if any, that all the minor-yet-huge-to-me inconveniences that've pushed devs to use this extension will be fixed in the base editor anytime soon.
Please consider adding a patch that would at least allow devs to opt-out of the property mangling that breaks this extension. If all the mangling does is save me a few MB of memory like microsoft/vscode#166126 seems to suggest, then I'd rather not have it.
@knopp Thanks a ton for this awesome extension. Please consider updating the extension page with an explicit warning to anyone using this extension with v1.74 or later.
I actually use this extension to inject a noticeable amount of css that removes all the small annoyances I have with vscode's ui, like not being able to remove the awful blue outlines from everywhere not being able to avoid the stupid notifications from bothering me every time I open the editor, or not being able to have the command palette in the center, where my sight already is
although the biggest annoyance by far is the title bar, which it's a shame that after so much time it's still not being addressed 😔
custom css I'm currently injecting
".editor .scrollbar .slider": "visibility: hidden; border-radius: 100vw; width: 50% !important; margin: 25% !important;",
".editor .scrollbar:hover .slider": "visibility: initial",
".editor .decorationsOverviewRuler": "display: none !important",
".notifications-toasts.visible": "display: none !important",
// ".part.sidebar > .composite.title > .title-label": "overflow: hidden",
// ".part.sidebar > .composite.title > .title-label h2": "margin-left: -4.5rem",
".monaco-workbench.noeditorarea .part.panel.bottom .composite.title": "margin-left: 4rem",
// remove stupid blue outline
".monaco-workbench [tabindex=\"0\"]:focus, .monaco-workbench [tabindex=\"-1\"]:focus, .monaco-workbench .synthetic-focus, .monaco-workbench select:focus, .monaco-workbench .monaco-list:not(.element-focused):focus:before, .monaco-workbench input[type=\"button\"]:focus, .monaco-workbench button:focus, .monaco-list-row.focused": "outline: 0px !important",
// make debug toolbar not suck
".monaco-workbench .debug-toolbar": "height: 1.5rem !important; top: .35rem !important; border-radius: .3rem !important; box-shadow: none !important",
// make find widget prettier
".monaco-workbench .editor-widget.find-widget": "border-radius: .3rem !important; right: 0 !important; margin: .5rem !important; background: var(--vscode-input-background) !important;",
".monaco-workbench .editor-widget.find-widget .monaco-sash.vertical": "display: none !important",
".monaco-workbench .editor-widget.find-widget .toggle.left": "opacity: .5 !important",
".monaco-workbench .editor-widget.find-widget .find-part .controls": "opacity: .5 !important",
".monaco-workbench .editor-widget.find-widget .find-actions .matchesCount": "padding: 0 !important",
".monaco-workbench .editor-widget.find-widget:not(.visible)": "transform: translateY(calc(-100% - 25px)) !important",
// make command palette prettier
".monaco-workbench .quick-input-widget": "background: var(--vscode-input-background) !important; top: 15vh !important; overflow: hidden !important; border-radius: .3rem !important; box-shadow: 0 0 8px 2px rgb(0 0 0 / 16%) !important; border-radius: .3rem !important; padding: 0 !important;",
".monaco-workbench .quick-input-widget .quick-input-list .monaco-list-rows": "background: var(--vscode-input-background) !important;",
".monaco-workbench .quick-input-widget .quick-input-list .monaco-list-row.focused": "background: var(--vscode-button-background) !important;",
".monaco-workbench .quick-input-widget .quick-input-list .shadow.top": "height: 2rem !important; opacity: .5 !important;",
".monaco-workbench .quick-input-widget .quick-input-list .monaco-progress-container.quick-input-progress.done": "display: none !important;",
".invisible.scrollbar": "display: none !important",
// make suggestions widget a bit better
".editor-widget.suggest-widget.visible": "border-radius: 0 0 .3rem .3rem !important; overflow: hidden !important",
// give test icons some breathing room
".monaco-workbench .codicon.codicon-testing-passed-icon": "font-size: 14px !important; height: 14px !important; width: 14px !important; left: 4px !important; width: 14px !important; height: 14px; !important;",
".monaco-workbench .codicon.codicon-testing-failed-icon": "font-size: 14px !important; height: 14px !important; width: 14px !important; left: 4px !important; width: 14px !important; height: 14px; !important;",
".monaco-workbench .codicon.codicon-testing-queued-icon": "font-size: 14px !important; height: 14px !important; width: 14px !important; left: 4px !important; width: 14px !important; height: 14px; !important;",
".monaco-workbench .codicon.codicon-testing-skipped-icon": "font-size: 14px !important; height: 14px !important; width: 14px !important; left: 4px !important; width: 14px !important; height: 14px; !important;",
".monaco-workbench .codicon-notebook-state-executing": "font-size: 14px !important; height: 14px !important; width: 14px !important; left: 4px !important; width: 14px !important; height: 14px; !important;",
".monaco-editor .codicon.codicon-testing-run-icon": "font-size: 14px !important; height: 14px !important; width: 14px !important; left: 4px !important; width: 14px !important; height: 14px; !important;",
".monaco-editor .codicon.codicon-testing-run-all-icon": "font-size: 14px !important; height: 14px !important; width: 14px !important; left: 4px !important; width: 14px !important; height: 14px; !important;"I want the editor to get out of my way, and allow me to focus on the specific things I want to focus; I don't need hundreds of buttons visible at all times, nor annoying popup notifications, nor a permanent titlebar that either shows me useless info like the project name or file name, or it takes a big chunk of space just sitting there, as I'll never click on it as I already have keyboard shortcuts for all the important stuff
will downgrade to 1.73 for now and hopefully this decision will be reconsidered on microsoft's side
huge thanks to matej for working on this extension and for giving us the opportunity to tweak the editor's ui to our liking 🎉
OK, looking at this, and maybe building on what @forivall has above. Here is the script that mangles names:
There doesn't seem to be any nondeterminism at all. Names are assigned using a greedy algorithm. The first name to be mangled gets assigned the short name "a", then "b", and so on. I think this means that two users (at least using the same version) will have the same mangled names.
If this basic picture is correct, this would make it possible to restore CustomizeUI functionality in VSCode. All that is needed is a list of which long names map to which short names, for each particular version number. This could trivially be computed using some kind of script that just runs MS's own mangler on whatever version number and outputs (longname, shortname) pairs. I would not be surprised at all if the resulting pattern is something simple - I would guess it'll be something like, if you sort the members of a class in alphabetical order, the first one maps to the name "a", the second to "b", and so on. However it works, though, the point is that in theory, this should be something that can be precomputed only once for every single user running the same version.
I am not sure if @knopp is interested in this, but if one wanted this plugin to keep going, the basic idea would be this. There would be a bunch of JSON files, one for each version of VSCode, which have a dictionary of long -> short name pairs. One could easily write a script to just look at MS's VSCode repository and compute a new dictionary of mangled names automatically every time another major release is made. These would then have to be stored somewhere, on some server, I guess, so that when CustomizeUI is loaded, it pulls the correct JSON file for your version and reverses the mangling. I guess you could also just distribute these JSON files with CustomizeUI, if you want, but then you'd have to keep updating CustomizeUI every time you update VSCode.
I am not sure how much sense this makes to do, but it should theoretically work.
Other than that, until something like that is implemented, it seems that @forivall's method is probably the best way forward, which just patches Codium so that the mangling is totally taken out.
This is so sad. I use VS Code, partially because it is good, and partially because it is a standard tool at my workplace.
Now, coming from Neovim, VS Code seems to waste a tremendous amount of space in its UI. This extension allowed me to get some of that space back, until it worked of course.
@ddnomad Could you share how your compact UI looked like?
@ddnomad Could you share how your compact UI looked like?
https://github.com/ddnomad/dotfiles/blob/main/.chezmoitemplates/vscode_settings.json#L50-L60
This is the best I can do atm, reverting to previous version of VS Code in a middle of a work day will be ... untimely.
Basically, that configuration looked very similar to a screenshot in @knopp's comment, in addition to some reduced spacing here and there.
That configuration and an absolute abomination of custom shortcuts makes VS Code usable almost fully with a keyboard alone, even on a relatively small screen.
https://marketplace.visualstudio.com/items?itemName=be5invis.vscode-custom-css
This extension works great with v1.74
I am very curious if there are any drawbacks to just using Codium for everything.
I used it to force vscode to have the fonts I wanted everywhere
"customizeUI.activityBar": "regular",
"customizeUI.font.monospace": "CozetteVector",
"customizeUI.font.regular": "CozetteVector",
"customizeUI.fontSizeMap": {
"10px": "12px",
"11px": "12px",
"12px": "12px",
"13px": "12px",
"14px": "12px",
"15px": "12px",
"16px": "12px",
"9px": "12px",
"menu": "12px",
"monospace": "12px",
"tab-title": "12px",
"window-title": "12px"
},
"customizeUI.titleBar": "frameless",
@ddnomad Could you share how your compact UI looked like?
I can also show my compact ui (which I want to eventually publish as a plugin) using my vscodium hack.
@ddnomad Could you share how your compact UI looked like?
I can also show my compact ui (which I want to eventually publish as a plugin) using my vscodium hack.
Please do, I'm curious as well, I had my own setup too but it is always inspiring to see what others did.
So, workarounds I've seen so far
- patched vscodium: iocave/monkey-patch#58
- vscode-custom-css
- downgrade workaround, should work at least for any ubuntu based distro:
sudo apt install code=1.73.1-1667967334
sudo apt-mark hold codeThis will prevent updates to vscode. You can unhold whenever you want.
I am very curious if there are any drawbacks to just using Codium for everything.
Some extensions are exclusively licensed to the Microsoft distribution and / or only available in the Microsoft extension marketplace.
Some built-in extensions particularly don't work on Codium - e.g. Settings Sync (although there's a plugin that does similar things apparently - haven't tested yet)
https://marketplace.visualstudio.com/items?itemName=be5invis.vscode-custom-css This extension works great with v1.74
@knameya Would you please provide any links about how to customize the style? Thanks a lot!
Has anyone using the VSCode Custom CSS workaround managed to replicate the activity bar bottom?
Reverted to 1.73.1 until this is resolved...
Posting my setup here, hopefully, it will be considered for implementation in VS Code:
@isidorn @daviddossett Atom was great because I could customize the UI to my own preferences. I wish vscode would have the same level of customization out of the box. I understand the need for a coherent UI design, but please allow those of us who want to change it the ability to do so!
I have the following customizations that make vscode much more palatable. Notice the "customizeUI.stylesheet" that narrows the explorer viewlet font, changes the border, etc etc. I also prefer the activity bar at the bottom of the view.
"editor.tokenColorCustomizations": {
"textMateRules": [
{
"scope": "comment",
"settings": {
"fontStyle": "italic"
}
}
]
},
"customizeUI.stylesheet": {
".explorer-viewlet .mac": "font-family: 'mplus Nerd Font'; overflow: auto; font-size: 1.15em !important; font-weight: 100; border: thin solid #2d2f33 !important; border-top-style: none!important; border-left-style: none!important; border-bottom-style: none!important;"
},
"customizeUI.activityBar": "bottom",
"terminal.integrated.fontFamily": "mplus Nerd Font",
"terminal.integrated.fontWeight": "100",
"workbench.colorCustomizations": {
"tab.activeBackground": "#0d1117",
"activityBar.background": "#0d1117",
"sideBar.background": "#0d1117",
"tab.activeBorder": "#d19a66",
"editor.background": "#0d1117",
"tab.inactiveBackground": "#0d1117",
"terminal.background": "#0d1117",
"sideBarSectionHeader.background": "#0d1117",
"sideBar.border": "#333333"
},
"window.zoomLevel": -2,I was also affected by this issue and have successfully migrated to be5invis.vscode-custom-css.
We would love to learn more from this extension and identify the gaps and shortcomings in our extensibility story
In my case, I was centering the status bar icons to align with the UI of my OS.
But if anything, this issue shows that everyone has their own needs, so if VS Code is missing something, it's custom CSS and not the specific modifications we are doing with CSS. I'd rather use custom CSS to solve my problem in 5 minutes, than wait for VS Code to support that specific feature natively, so having custom CSS (microsoft/vscode/issues#168856) is a must. And yes, I am fully aware that class names can change, that is a risk (and maintenance burden) I am willing to take when writing user stylesheets, both for the browser and VS Code.
@stefanhamburger Wholeheartedly agree.
marketplace.visualstudio.com/items?itemName=be5invis.vscode-custom-css This extension works great with v1.74
I wonder what this one does differently. My guess is that injecting CSS is a more simple process than what customize-ui’s underlying engine monkey-patch does.
My guess is that injecting CSS is a more simple process than what customize-ui’s underlying engine monkey-patch does.
Seems like it.
Would greatly appreciate if somebody figures out how to do a compact titlebar (customize-ui inline) with vscode-custom-css extension, I failed to do it in 5 minutes
Why hasn't this vscode-custom-css extension been broken by the same update? It even lets you do custom javascript.
Like I mentioned, i have extensive css to make the ui more compact. Looks like I'll switch over to vscode-custom-css for the forseeable future, as the benefits of mainline vscode are preferable for me over using vscodium.
Screenshot comparison
Compact:
Vanilla:
@battaglia01 the other extension works because it does the patching in a different way. customize-ui patches into the vscode internal classes to load css and make other ui changes in the internal vscode scope, injecting requirejs modules, where custom-css simply updates the static css and javascript, without trying to hook into the requirejs loader. This allows the changes to be done beyond css, as vscode does plenty of layouting in javascript itself. If you look closely at my screenshots of my compacted ui, there's some weird gaps that i would need to fix by patching into the javascript layout logic itself, and changing some constants.
Interesting. Can it do basically everything that CustomizeUI can do? I hope they don't break this one next...
No, CustomizeUI is a bit more powerful. For example, CustomizeUI can move the activity bar around, and allows other internal hacks, like this one I never got around to submitting a pr, which let me animate the go-to-definition hover (although I guess i'll try to submit that change into mainstream now). Custom-CSS cant do that, as injecting into the requirejs modules requires a specific hack that only monkey-patch provides. I'll personally be able to get away with just the CSS for now, especially as i move the activity bar buttons to the status bar with the activitus bar extension, but I'm otherwise just as disappointed as the rest of you.