The font size of the UI can't easily be scaled up or down

[emerajid]

Have you checked for existing feature requests?

• Completed

Summary

Tab to the right, half of the text is frustratingly small. There must be a way to make the font size larger. Search through settings yields nothing at all.

What benefits does this feature provide?

Accessibility. You only got two eyes and glasses are expensive.

Any alternatives?

Not that I know of.

Other examples:

Not really, IIRC Visual Studio Code allows this, but I never used it personally and am not going to.

[savetheclocktower]

You can increase the tab font size via your user stylesheet.

Here's one way of increasing the tab text size:

.tab .title {
  font-size: 14px;
}

Change the 14 to whatever value you like. The updated styles should take effect as soon as you save.

[confused-Techie]

@savetheclocktower Is totally right on a solution here, but I do wonder why the github package doesn't follow the Font Size in the settings.

Which @emerajid for many cases adjusting the editor.fontSize setting should change the font size in most places.

But testing this myself changing my font size in settings does adjust it for many places, yet in the GitHub pane only one or two places abide by my change.

I picked out the text Staged Changes to test with, which has a font-size of 12px. Which is strange, since as far as I can tell it's value is set via @font-size in @ui-variables. Which I'd assume follows the users font-size selection.

I know adjusting font-sizes to far can make UI's break, but I feel like it'd make a ton of sense for us to ensure that font's scale with whatever the user selected, everywhere.

I mean there is already --editor-font-size as a variable within the page, and is updated with our setting. So I wonder how much of a challenge it'd be to make it dynamic

[savetheclocktower]

Whoops, I misread this entirely. I saw “tab” and assumed you must mean the tab text. Apologies. Let me dig into this.

[savetheclocktower]

Luckily, it does seem to get scaled proportionally; you should be able to do

.github-Git {
  font-size: 20px;
}

or whatever value you like. Setting the font-size in that one place appears to scale everything upwards.

@confused-Techie, if you're thinking of the editor.fontSize config option, that only controls text in TextEditors. I don't think there's an equivalent config setting for the UI in general.

[emerajid]

After some more hours, I notice tiny fonts in quite many places. Please, if possible, provide instructions on how to tweak user stylesheet to fix a tiny font in an arbitrary place.
@savetheclocktower uses .github-Git selector. It is not obvious how to find it, at least for somebody who has never cared much for webdev.

Also, we possibly need change issue title to a more generic one, but I won't edit it myself without feedback.

[savetheclocktower]

@emerajid, the instructions are on the page I linked above. But I agree that that's an advanced technique and we shouldn't make users do that for common tasks (like changing the size of all text in the editor).

There's a legit bug here: the GitHub extension sets its own font size instead of inheriting the font size defined on body. If it didn't, then all the text in the Git panel would be roughly the same size as the other text in your screenshot. A better workaround might be to put this in your user stylesheet…

.github-Git {
  font-size: unset;
}

…so that it inherits the font-size from body. And that would make it easier to define something like

body { font-size: 20px; }

in your user stylesheet and have it apply to almost everything on screen at once.

You mention that you've noticed other places where font sizes are too small. Please let us know what they are; if they're in Pulsar's core packages, we can certainly do something about it. Sometimes the answer will be a user override, but I grant that most users shouldn't have to go digging into the developer tools in situations like these.

[savetheclocktower]

I changed the ticket name to cover what I think is the real issue. It's not hygienic for a package to hard-code a font-size. In general, packages shouldn't define their own font-size at all, but if they need smaller text, they should still define it in relative terms with em units — or by doing math on a Less variable:

@import "ui-variables";
.SomeContainer {
  font-size: @font-size * 0.75;
}

We can't magically fix community packages that do this, but we can certainly clean up our own house. Right now, the GitHub package is the only one I'm aware of, but we can expand this ticket to cover other core packages if other instances are found.

[savetheclocktower]

@emerajid, I should also point out — I completely forgot about it — that the one-dark package allows you to customize font size via its settings:

Yet when I change the font size via the settings, it doesn't apply to the Git tab — but it should! The github package is reading from the same variable as everything else, yet the font size stays small as everything else gets bigger. This is getting weirder the more I look into it.

EDIT: Nope, I understand why. In this case, the setting doesn't actually change the value of @font-size; it just applies a style override on the html element. This is lazy and won't have any effect on things that hook into @font-size itself. I'm a bit surprised at this.

The user stylesheet gives users a chance to apply override styles, but my understanding is that it's evaluated after everything else (so that it can act later and win out in case of ties). The best fix here would be to redefine @font-size itself in the user stylesheet, but that doesn't seem to work, and it's probably because all it does is redefine the variable after all the other stylesheets have consumed it. If we could fix that somehow and get the best of both worlds, that'd be the ideal outcome.

[emerajid]

@savetheclocktower
The same Git package, commit view, diff. The code itself is normal font, but the diff file name and lines which differ are all printed in a very small font for no good reason. Provided stylesheets do not solve the issue. Cannot do further testing, because can not open developer tools. Not sure why exactly, but probably because I do not make use of developer mode.

[savetheclocktower]

@emerajid Since you're on Linux, you might have to launch Pulsar from the command line with --no-sandbox at least once. Some people say they've been able to open the dev tools after doing that.

@confused-Techie, is that still accurate, or am I just spreading old advice? If there's newer guidance, I'll add it to this page.

[confused-Techie]

@savetheclocktower That advice for Linux users is still totally accurate.
I'd only hope for change once we bump Electron. But otherwise the mechanisms that resolve it for a single launch are still unknown. (In other news, that is still part of the advice for getting DevTools and such working on some Linux distros)

But on the topic of this thread, I realize you said the font-size setting only effects the editor components, but I mean how hard do you think it'd be to fix that? At least in core packages, since personally I'd love if we did something in packages were the font-size of an element was related to the users font-size. So that text can scale as a package needs, but it's always based on whatever the user has chosen.

At least in core packages, couldn't we do:

.some-class {
  font-size: (@font-size * 2); // Or whatever?
}

It seems like basic accessibility we would want to implement. And if a workable solution I'd be happy to go around adding it where needed, but I realize this does nothing for community packages.

[savetheclocktower]

But on the topic of this thread, I realize you said the font-size setting only effects the editor components, but I mean how hard do you think it'd be to fix that?

My evolving understanding of the issue means that practically every single comment I've made on this issue is inaccurate or incomplete. Let me try again.

The github package largely does the right thing. When it sets a font size, it does font-size: @font-size; so that the size dictated by the UI theme is respected. In this case, it would be better if it inherited the ambient font size and didn't set one explicitly, but using @font-size is the next best thing.

The problem is that @font-size is hard-coded by every individual UI theme! The default one-dark-ui theme hard-codes it to 12px. And there isn't really a mechanism by which it can be redefined after the fact, at least not one that I'm aware of.

The setting I mentioned above doesn't regenerate the stylesheet when the user changes the font size; it just applies the corresponding size as an inline style on the html element. This supersedes the 12px value for anything that is just inheriting the ambient font-size, but not for anything that explicitly sets font-size: @font-size;, since any style that targets a specific element will supersede one that is inherited from an ancestor.

So I imagine that lots of packages actually do handle this correctly and hook into @font-size. The challenge is how to make that variable a bit more dynamic.

One thing would definitely fix @emerajid’s issue, but it's ridiculous: someone could fork one-dark-ui, change only the @font-size definition, and publish it as one-dark-ui-only-bigger. It'd be a one-byte change! — and yet I can't think of an easy way to do it otherwise.

I'll read the Less docs to see if I'm missing anything. But I suspect that the fix would involve a package setting that actually regenerates the stylesheets (or some subset, at least) whenever the user changes the setting. I forget where I first saw this done, but I borrowed the technique for calculator-light-ui.

There's another idea that I have that I spent about 30 minutes on earlier — I think it's far more promising, but might be a bit disruptive. Ever since we upgraded Less last year, we've had the ability to define functions that can be imported into Less stylesheets and act as values. The example from the Less docs involves a function that returns a constant numeric value, but we could just as easily define that function in such a way that it looked up configuration values. Imagine if ui-variables.less had an excerpt like this:

@font-size: config('one-dark-ui.fontSize', 'px');

This is pretty easy, believe it or not. You've got to be careful to validate the values you get from config (so that you don't try to create a pixel value out of a string setting, etc.) but that can be managed.

The harder part is regenerating the styles — both knowing when to do it and actually doing it. When you're developing a theme in dev mode, the dev-live-reload builtin package will ensure your styles are reloaded and reapplied whenever you save — but even that doesn't penetrate some packages. The Git sidebar will eventually inherit a change to @font-size in that situation, but only after you reload the window. I'm not sure yet why that's true for the Git sidebar but not for, say, tree-view (which gets changes to @font-size immediately).

Ultimately, even if we get a version of this that doesn't take effect until the window reloads, it's still an improvement. Then we could have that one-dark-ui.fontSize setting actually change @font-size.

[savetheclocktower]

@emerajid I just thought of a different workaround that might work better for you until we can figure out a proper fix:

• Open your user stylesheet.
• Remove any previous overrides of font sizes.
• Try this instead:

@zoom: 1.2;

body {
  zoom: @zoom;
}

atom-text-editor {
  zoom: calc(1 / @zoom);
}

What does this do?

• It applies a uniform scale factor to the entire contents of the window.
• Sadly, this causes a problem inside of text editors; it makes Pulsar's math wrong when it tries to figure out where a click happened in a document. This affects cursor placement and text selection. So…
• We undo the zoom for atom-text-editor elements by applying an inverse zoom level.

This has the effect of scaling up all non-text-editor text without screwing up code editing. (The font size of the editor itself can be changed in settings.)

You can change the value of @zoom as needed. 1 is the baseline; 2 means twice as big; etc.

I wouldn't be surprised if this had some other weird side effect, but play around with it for a while and see if it works for you.

[emerajid]

@savetheclocktower reset one-dark-ui to default values (i.e. 12pt font size), do

@zoom: 1.7;

body {
  zoom: @zoom;
}

atom-text-editor {
  zoom: calc(1 / @zoom);
}

and try to prevent the github package pane (or is called tab, or panel, or whatever? Correct me please. Screenshot for clarity) from taking half your screen.

It behaves a bit like it's crazy. I click on its side to start resizing, the side of the panel immediately jumps far right, making the whole pane very thin, then I can move my mouse to try and resize it, doesn't always work. It gets better if I make UI font larger and scale factor smaller, but the problem is still present. Probably it doesn't parse mouse clicks correctly. Then, at some point increasing UI font size to decrease scale factor stops making sense, since github package fonts become too small.

All in all it can be used as the solution, but it would be a much smoother experience if a workaround could be found around such glitches.

If I find out anything else I'll report it. This is more or less just a first glance at your response.

[savetheclocktower]

Probably it doesn't parse mouse clicks correctly.

Yeah, I tested this approach with a bunch of things… but not with pane resizing. It, too, interprets clicks and drags differently because the zoom interferes with its estimations of where the cursor is and how wide the pane should be.

Sorry for wasting some of your time. Back to the drawing board!

If I get some time, I'll build a quick one-off version of one-dark-ui with a configurable font size; that'd solve it pretty definitively in the short term. I have another approach that is promising in the long term, but would probably have to wait until after we can upgrade to a newer version of Electron.

[emerajid]

@savetheclocktower
Ping me when your theme is ready. And a brief instruction on getting it installed is welcome as well. So far I mostly use git from a terminal, because branch switching is more convenient and a lot of testing is done in command line anyway. But would be super if I could put at least half the load on pulsar. And especially super if when looking at git logs the font for diff was larger that 10pt. The above workarounds feel more or leas acceptable so far, but not perfect.