Change:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --The resize steps when using the / commands / shortcuts are pretty heavy. Being a keyboard driven navigator through the editor I would love to have an option to determine the step size for those commands, because I think this way no users would need to compromise. If it's needed, I would put my bit of work into that if you would like to have such an option. Even if there shall not be an option, it would be marvelous of you to reduce the current default step size by just 1 percent. This keeps it still fairly big if someone prefers those step sizes but already allows more precise resizing with the keyboard so the view / splits can fit one's needs. Basically: to Imho even smaller step sizes would be better
seems like a fair request
After thinking about this, I decided to move away from using view percentage increments. Instead, we now use css px units so that the resize increments are consistent. The newly chosen increment size is ~equivalent to 5.5% of a 1080px width monitor.
Great to read. Thank you!
I run vscode on a 27" 1440p monitor in vertical orientation, and after a recent vs code upgrade now my command is increasing the terminal height by only 1 line, instead of ~10 lines like before. Is that expected from this change? The size increase now feels very small, and I'm retraining my fingers to expand the terminal directly to full-screen (Ctrl+Shift+Q) instead of expanding the terminal 4 or 5 times (Ctrl+Cmd+Up). Now, to use (Ctrl+Cmd+Up) I'd have to press ~40 to ~50 times (or hold) to get it to a mostly-expanded size.
I'm not a vscode maintainer but what I can tell: To meet your needs with the current implementation, you could map the keybinding you used to use to a multi-command or macro. Using the corresponding vscode extension / .That way you could control the exact resize step amount. that make it sounds like a tough thing to do ‍. As far as I could tell until now a human brain should be able to do it in a few minutes or a handful of repetitions .

Discussion:
abstract class BaseResizeViewAction extends Action2 { <del> protected static readonly RESIZE_INCREMENT = 6.5; // This is a media-size percentage </del> <ins> protected static readonly RESIZE_INCREMENT = 60; // This is a css pixel size </ins> protected resizePart(widthChange: number, heightChange: number, layoutService: IWorkbenchLayoutService, partToResize?: Parts): void {

import { Disposable, DisposableStore } from 'vs/base/common/lifecycle'; import { Event, Emitter } from 'vs/base/common/event'; <del> import { EventType, addDisposableListener, getClientArea, Dimension, position, size, IDimension, isAncestorUsingFlowTo } from 'vs/base/browser/dom'; </del> <ins> import { EventType, addDisposableListener, getClientArea, Dimension, position, size, IDimension, isAncestorUsingFlowTo, computeScreenAwareSize } from 'vs/base/browser/dom'; </ins> import { onDidChangeFullscreen, isFullscreen } from 'vs/base/browser/browser'; import { IWorkingCopyBackupService } from 'vs/workbench/services/workingCopy/common/workingCopyBackup'; import { isWindows, isLinux, isMacintosh, isWeb, isNative, isIOS } from 'vs/base/common/platform';

} resizePart(part: Parts, sizeChangeWidth: number, sizeChangeHeight: number): void { <del> const sizeChangePxWidth = this.workbenchGrid.width * sizeChangeWidth / 100; const sizeChangePxHeight = this.workbenchGrid.height * sizeChangeHeight / 100; </del> <ins> const sizeChangePxWidth = Math.sign(sizeChangeWidth) * computeScreenAwareSize(Math.abs(sizeChangeWidth)); const sizeChangePxHeight = Math.sign(sizeChangeHeight) * computeScreenAwareSize(Math.abs(sizeChangeHeight)); </ins> let viewSize: IViewSize;