New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User overrides for CSS font-family
of theme fonts
#7130
User overrides for CSS font-family
of theme fonts
#7130
Conversation
Thanks for making a pull request to JupyterLab! To try out this branch on binder, follow this link: |
From a gitter chat:
|
6dedfca
to
9fd5d76
Compare
I just rebased and tested the PR. It should be good to go for others to test now, if they want |
From @jasongrout on gitter:
|
@tgeorgeux Thoughts? Feelings? Sudden sensations of queasiness at the sight of dingbats: ? |
Hi First of all, I still haven't found which file to modify. Is it a .json .css .py ? Anyone know how we could go about transforming the prompt Jupyter? 👍 and ideally be able to change the colors of the prompts as requested in the post cited above? |
Can you open a new issue for this discussion? It's significantly different from what is proposed in this PR (where you want to change the actual text, not just the font). |
Hi jasongrout There was a code that we could put in the file 'ipython_config.py' of 'Jupyter Notebook' and which is this: |
previously, `font.ts` was in @jupyterlab/coreutils, and added a dependency on `@phosphor/widgets` -> `@phosphor/domutils`. `domutils` initializes some static vars using the `navigator` object, which is browser only, and will break code running in a `node` environment. `examples/node` in `@jupyterlab/services` runs in node and imports `services`, so that example was broken. This commit restores `node` compatibility to `services` by moving `font.ts` to `@jupyterlab/ui-components`, which already has a `@phosphor/widgets` dependency
I had completely forgotten about this PR, until some renewed interest in it over at #9430. @jasongrout @tgeorgeux If the font-picker menus still seem controversial, I'm willing to disable them for now. But honestly I think adding them in is a worthwhile experiment that we should attempt. Everything else in the PR should be unobjectionable, including the support for the font-family overrides in the theme settings requested in #9430. Overall I think that this PR delivers a straight improvement over our current "Settings -> JupyterLab Theme" menu (in terms of being well organized and easy to read at a glance): old VS new This PR languished for a while, so it would be nice to get it in quickly |
@goanpeca As part of rebasing this PR, I ended up having to make changes to the item labels of the "Theme" menu, which I guess are now under the control of the localization system. What's our policy on making changes to localized strings? Is it okay to make edits to those label strings, or should I revert the related changes? |
Hi @telamonian, thanks for bringing this up.
It is fine to change them, just make sure the new ones are using the Before the final rc is released we will do a final scrape of the strings in their final state. Cheers! |
@goanpeca Great. I just double checked, fixed a couple of strings where I had missed the |
}); | ||
|
||
const incrLabel = trans.__('+ Size'); | ||
const decrLabel = trans.__('- Size'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wondering if using Increase size
is prefered over + Size
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
} | ||
type: 'submenu', | ||
submenu: fontMenu( | ||
trans.__('UI Font'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure about the use of UI, is this consistently use on other places?
Maybe Interface Font
is another option that does not rely on shorthands?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though I agree that the term UI might be opaque for some, Interface Font
is too generic and vague. For now, let's just keep things simple and continue to refer to this font the same way we do throughout the codebase and the css, as UI font
label: trans.__('Decrease UI Font Size'), | ||
key: 'ui-font-size1' | ||
}, | ||
args: { label: trans.__('UI Font'), key: 'ui-font-size1' }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same idea from above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made some small comments, otherwise looks good :)
@jasongrout This should be ready to go in now. As per the meeting discussion, all of the UI changes have been reverted, and all of the UI specific code has been stripped out. I've thoroughly tested everything else, so it should be good to go. @blink1073 I wanted to add some unittests for |
8b92dad
to
6fdd4f6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
References
fixes #4013
fixes #4608
fixes #5673
fixes #9430
followup to #6926
Code changes
Adds some font handling stuff to
coreutils
, makes use of said stuff inthemePlugins.ts
User-facing changes
Adds font family picker menus for each of the fonts defined by a theme:
Backwards-incompatible changes