Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Make mu (even more) friendly for dyslexic users #633
Mu actually does a really great job of this already, there are loads of aspects of the design that make it good for people with dyslexia. I had a few thoughts about what else could be done though.
Which achieves the desired result (see fig 4). I just chose the same colour as is used for the borders below. It feels like a bit of a hack, but I don’t think such a bad one as to be completely avoided. What do you think?
Sorry btw if this seems really really pernickety, I've just noticed that in day theme my cursor seems to know where to go, since there are clear sections, but in other themes I seem to have to search along the whole block to find the desired button.
This was referenced
Sep 10, 2018
added a commit
Sep 11, 2018
So having done a bit of reading on the issue of colours and readability, all the literature is in agreement that pure white, and pure black is the worst combination for reading, so I have made a pull request to adjust that. The general consensus though, is that to significantly help most people suffering with visual stress/Irlens Syndrome they need to select specific colours.
I agree the styling would need some refactoring before we tried to do something like that. As I see it, the main issues are (I hope this is not read in the wrong way, I say this with the absolute greatest respect, and have learned lots from just reading the mu code-base) :
I propose as an alternative, we store all theme-specific style information in the classes defined in
Most situations could then be dealt with by adding a property to of the each classes inheriting Theme.
For example instead of (in panes.PlotterPane)
We could simply have:
This would mean all the theme information was in one place, would simplify the code everywhere else, and wouldn’t introduce any new dependencies.
As well as being simpler, and more maintainable. This would also pave the way to allow custom settings for users who wanted them. We could simply have a fourth class
(This would also separate the logic of switching themes and the actual colors used from the rest of the UI Layer, and would make things easier for porting to different UI library.)
A few things such as
Sounds great, some notes:
But in theory regexing a base theme would make a lot of things easier
I would prefer it if
Persistence wise we could store the colours in a
added a commit
Sep 29, 2018
I’ve also had a WIP branch which has sat dormant for a while. I’ve uploaded it, and the link is here. At the moment what I’ve done is refactored so that everywhere there is a
Feel free to use/chage/ignore any of what I’ve done. I’d love to collaborate on this if possible, although I’m not sure how that is best done.
(Sorry, that the branch also seems to have some commits from ages ago, which I made from my master branch, I’ll fix this at some point soon. It’s just the final commit that is relevant.)
Only other thoughts are:
Folks, it is great to see this work moving forward!
A quick note: Mu's code base is relatively simple, and I'd like to keep it that way. Please try to do the simplest thing first (i.e. obvious names, obvious code in the obvious place). If there's a problem widget (e.g. the JupyterREPL) then it's far better for upstream to fix the problem with out help (I know the maintainer of JupyterREPL), than for us to create a "hacky" sticking plaster because everybody gets the benefit of an upstream change.
Hope this makes sense.