Skip to content
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

Merged
merged 17 commits into from Dec 14, 2020

Conversation

telamonian
Copy link
Member

@telamonian telamonian commented Aug 30, 2019

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 in themePlugins.ts

User-facing changes

Adds font family picker menus for each of the fonts defined by a theme:

image

Backwards-incompatible changes

@jupyterlab-dev-mode
Copy link

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link: Binder

@tgeorgeux tgeorgeux self-requested a review September 12, 2019 21:53
@telamonian
Copy link
Member Author

From a gitter chat:

The remaining technical hurdle is detecting available fonts client side in the user's browser. I figured out a reasonably robust way to do it, but it works by running through a static list of fonts and checking each one. So there maybe needs to be a survey of the community or something where we collect the lists of fonts that a bunch of devs/users have installed on their systems (matplotlib installs some tools that make this easy to automate).

@telamonian
Copy link
Member Author

I just rebased and tested the PR. It should be good to go for others to test now, if they want

@telamonian
Copy link
Member Author

From @jasongrout on gitter:

I think eventually we want to probably move those options (if we have them) to a settings editor and out of the menu, and keep the menu for things that change often. But given we don't have a settings editor now, I guess menu it is for things like that. I don't have an opinion about whether it's a good idea to let them be customized, but I tend to err on the side of letting them have capability to do what they want

@telamonian
Copy link
Member Author

@tgeorgeux Thoughts? Feelings? Sudden sensations of queasiness at the sight of dingbats:

image

?

@paulo989
Copy link

paulo989 commented Jan 6, 2020

Hi
I hope to post in the right place. Sorry if this is not the case but you have touched on a subject that interests me.
I am working on a JupyterLab Notebook (not Jupyter Notebook) under Python 3 and I would like to hide / modify / delete the classic code prompt In [].

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? 👍
from:
In [1]
at :
=> [1]
or only:
=>
or this :

and ideally be able to change the colors of the prompts as requested in the post cited above?

@jasongrout
Copy link
Contributor

I hope to post in the right place.

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).

@paulo989
Copy link

paulo989 commented Jan 6, 2020

Hi jasongrout
I can open a new number if necessary for the change of font.
Initially, this is the text that I wanted to modify as indicated above.
I wanted to have => or >>> instead of Out [i].

There was a code that we could put in the file 'ipython_config.py' of 'Jupyter Notebook' and which is this:
from IPython.terminal.prompts import Prompts
from pygments.token import Token
class MyPrompt(Prompts):
def in_prompt_tokens(self, cli=None):
return [(Token.Prompt, ">>> ")]
c.TerminalInteractiveShell.prompts_class = MyPrompt
But now I'm looking for the solution for JupyterLab.
Obviously it is another file which must be modified but I do not know which one and how.

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
@telamonian
Copy link
Member Author

telamonian commented Dec 6, 2020

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

image

VS new

image

This PR languished for a while, so it would be nice to get it in quickly

@telamonian
Copy link
Member Author

@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?

@goanpeca
Copy link
Member

goanpeca commented Dec 6, 2020

Hi @telamonian, thanks for bringing this up.

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?

It is fine to change them, just make sure the new ones are using the trans.__ ...

Before the final rc is released we will do a final scrape of the strings in their final state.

Cheers!

@telamonian
Copy link
Member Author

It is fine to change them, just make sure the new ones are using the trans.__ ...

@goanpeca Great. I just double checked, fixed a couple of strings where I had missed the trans.__. Could you please also take a second to double check the trans.__ related changes in this PR? All the relevant changes are in one file, themeplugins.ts

});

const incrLabel = trans.__('+ Size');
const decrLabel = trans.__('- Size');
Copy link
Member

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My sense is that

image

is more concise and understandable at a quick glance than

image

so I, at least, prefer it. We can ask everyone's opinion at the meeting

}
type: 'submenu',
submenu: fontMenu(
trans.__('UI Font'),
Copy link
Member

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?

Copy link
Member Author

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' },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same idea from above.

Copy link
Member

@goanpeca goanpeca left a 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 :)

@telamonian telamonian modified the milestones: Future, 3.0 Dec 9, 2020
@telamonian
Copy link
Member Author

telamonian commented Dec 14, 2020

@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 ThemeManager as part of this PR, but the ThemeManager constructor requires ISettingRegistry. So I'd need some flavor of SettingRegistryMock. Do we currently have any such thing in the codebase? The closest thing I was able to find is the code here in @jupyterlab/testutils, but it doesn't really seem to be what I'd need

Copy link
Member

@blink1073 blink1073 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@blink1073 blink1073 merged commit 05778d1 into jupyterlab:master Dec 14, 2020
@github-actions github-actions bot added the status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. label Jun 13, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
5 participants