[Userscript] The GanbarOmeter

WaniKani API And Third-Party Apps
#201

Hmm. Very odd. It’s scaling the heights correctly, which means it’s calculating the max correctly, but the label isn’t getting set correctly for some reason (works fine for me).

Can you right-click on the Reviews widget and find the table element in the HTML? It should have a style attached to it that sets the --max-label css variable (set to 216 on my screen here):

Screen Shot 2022-01-04 at 2.19.33 PM
Screen Shot 2022-01-04 at 2.19.33 PM1920×1000 132 KB

If it’s actually set to 0 it’s one problem, if it’s unparsable it’s another…

EDIT:

The only thing I can even hypothesize is that max isn’t written as an integer to the CSS. I’ve added an explicit toFixed() in the dev version I just uploaded (https://raw.githubusercontent.com/wrex/ganbarometer-svelte/main/published/dev/bundle.js).

That shouldn’t be necessary, but …

LMK if the new version displays the max correctly now (it should 132 based in your case as the expected daily number is the largest).

#202

There’s, um, no CSS in that version. The label is being set to 132, though…

This is what the inspect looks like with the previous version. Notice that --max-label in the CSS is not defined, but that might be unrelated

image

#203

Aha! I guessed right. Notice on the table element in your image style="--max-label:131.812;"

CSS counters only work on integers, so a toFixed() is necessary. Unsure why I’m not having the same problem, but the fix is easy regardless.

I’ll post a 4.0.2 production update that fixes both bugs you found shortly (out-of-order and old reviews, plus the integer label thing). It will also display questions/minute instead of seconds/question, and total apprentice accounts as described).

I fat-fingered the 4.0.1dev version causing that problem, but I noticed and fixed it in the 4.0.2dev version right away. You may have pulled an old cached value. Make sure you see this header:

// ==UserScript==
// @name        ganbarometer-svelte -> dev
// @description The GanbarOmeter (Wanikani dashboard widgets)
// @namespace   https://github.com/wrex/
// @version     4.0.2

Regardless, the production 4.0.2 (without -> dev in the name) will include the CSS if it kills me! :wink:

1 Like
#204

That version doesn’t have any css thinking

#205

Nevermind. Silly mistake on my end. I Must not have replaced the file: URLs when I published it:

To fix it immediately, edit line 9 in the header to read:

// @resource    css https://raw.githubusercontent.com/wrex/ganbarometer-svelte/main/published/dev/bundle.js

Alternately, wait a few more minutes and I’ll push the production 4.0.2 version.

1 Like
#206

Production version v.4.0.2 is now available. Tampermonkey should do the right thing if you already have it installed and use the Utilities → Check for Userscript Updates doohickey. If not, the install URL is still https://raw.githubusercontent.com/wrex/ganbarometer-svelte/main/published/v4/bundle.js .

Changes

  • [Bug] Fixed a bug for folks performing reviews “offline” (the script expected all reviews to be in chronological order)

  • [Bug] Fixed a CSS (display) bug for bar chart labels (converting a CSS variable from a float to an integer)

  • [Feature] Speed is now displayed with units of Questions-per-minute so that the dial rotates to the right as you go faster. (Displaying seconds-per-question on the gauge was counter-intuitive.)

  • [Feature] the Data view for the Ganbarometer now displays the total number of apprentice items

  • [Infrastructure] All tests should be passing (or skipped) now. I made several design changes recently that broke most of my test mocks and hadn’t gotten around to fixing things. I still need to write more tests and fix the ones that are skipped (as well as write new unit tests for the bugfixes).

As always, just let me know if you find any other bugs or desire any new feaping creatures.

1 Like
#207

Works as expected :+1:

2 Likes
#208

Is the dotted line supposed to be more visible in dark mode?

image

Also the interval doesn’t seem to be visible in light mode

image

#209

It uses the TextColor in the settings. I’m not sure it really adds much since the desired range is always centered vertically. I might eliminate it in the future.

That is REALLY weird (okay in dark mode but not light). If you go to Settings → Appearance then click Defaults, Save, and refresh your screen does the problem persist? It looks like your track color and hlTrack color are the same. Re-saving/refreshing should ensure whats in localstorage is up to date.

It’s working fine for me. What happens if you adjust the Track and hlTrack color widgets in the Settings->Appearance dialog?

EDIT:

I think it may very well be related to what was in localstorage. Re-saving your preferences should fix it. I just tried it in both FireFox and Chrome and the colors seem normal. Firefox was running a VERY old version, though, so when I first installed the new one it picked up the old preferences and displayed incorrectly.

I really need to start storing and checking a version string with the persisted data.

EDIT 2: @Sinyaven is making me nervous with the typing … :wink:

#210

Maybe it would be good to rename bundle.js to bundle.user.js so that Tampermonkey can recognize the raw file as a userscript and immediately offer to install it? Then you could just share the link and avoid the awkward installation procedure using “Install from URL” in the Tampermonkey “Utilities” tab.

Also, your script doesn’t seem to like that I did not do any reviews in the last 7 days:

image
image944×245 15.2 KB

image
image946×246 17.6 KB

Not really a big problem, but I wanted to mention it anyway.

At first, the gauge was completely invisible for me and I had already written a longer bug report, but then I tried to delete IndexedDB and localstorage which fixed it. Surprisingly, just changing the settings was not sufficient, which I had tried beforehand.

3 Likes
#211

Cool. I didn’t even know that Tampermonkey looked for that name. Will do that going forward (I worry about confusing people with too many changes at once).

Well there’s a test case I should have considered! (laugh) I can’t imagine going that long without a review myself, but I haven’t been here as long as many.

I’ll make it behave better for that specific case in a future version (though the defaults will still target typical users doing their reviews daily like good little durtles).

(Just kidding about the typing. :wink: )

I’ve stored several separate objects in localstorage now, and have made numerous incompatible changes. The only stuff I have in IndexedDB is via wkof. I can’t think of anything offhand that WOULDN’T be reset by saving user settings and refreshing the page, but it’s possible I’ve forgotten something.

Anyway, I’ll ignore the problem for now since you were able to fix it on the client side. But permit me to remain a little worried … <laugh>

1 Like
#212

I just noticed that the settings dialog is now supposed to go away after clicking “Save” – that definitely did not happen when I tried to reset my settings. Actually, my mouse cursor disappeared whenever I hovered the “Save” button! I just assumed that the save would go through anyway if I click while the cursor is at the correct location.

That was a really strange bug – I’m wondering how something like this can even happen.

#213

That exact behavior did exist in a development version for a short while. Did you install one or more of the betas? It sounds like something just didn’t get cleared out.

(For the record cursor: none; is not how you clear cursor: pointer; in CSS!)

To be clear the Save button is disabled if there are any validation errors. I can definitely improve the styling, but if it’s disabled in the current production version there should be no pointer cursor (little hand) and the background of the button should turn gray.

1 Like
#214

Yes, I had a beta version installed.

1 Like
#215

It looks like switching from dark mode to light mode changes the track color to the green. Also it’s not letting me save the settings anymore??? Not even if I just open it and click save. I keep having to delete the localstorage entry

#216

Aha! I can reproduce that (and see the bug). v4.0.3 here we come. (sigh)

Hmm. Let me take a look. You’re on Firefox, right? (Will check both FF and Chrome)

1 Like
#217

I’m on Brave these days. I don’t know how to replicate it yet, I might look into it later unless you find something (no time now)

1 Like
#218

This was trivial to fix, but it isn’t worth pushing a new version for. I’ll include the fix in the next patch release.

The bug was in the function that the “Set Light Theme” button calls (a typo set both the track and hlTrack colors to the same value). Since the defaults use the light theme, one workaround is to click the “default” button. If you have other settings you don’t want to lose, just click on the track color input and change it to whatever you like. The default value is #e0e0e0.

I’m not sure what could possibly cause that. Doubtless its another bug, but I’m unable to reproduce it, so I’ll wait and see if the problem persists on your end.

Thanks for finding my bugs! :disappointed:

And … just like that, I think I may have found it. The save button is disabled if any of the range sliders are set to invalid values (min > max or whatever). The button turns gray when disabled (I need to make this MUCH more visible). Worse, if you close the dialog and re-open it, the invalid state isn’t reset (the sliders LIE!). Validation logic is tricky to get right. I’ll work on it tomorrow.

In the meantime, if this is the problem you should be able to click “Default” (setting known-valid values) you’ll have to slide all of the min/max/target sliders to valid values (min < target < max) then start saving again. If any validations fail, you SHOULD see red validation messages that must be cleared before you can save, BUT you can close the dialog and the validation messages disappear when you reopen the settings dialog. Just refreshing the page should also clear the problem since at least it doesn’t let you actually save invalid values.

1 Like
#219

FYI this is not at all visible with the Breeze Dark theme (although that’s not really your issue)

#220

Yeah, theming is HARD. Breeze Dark (and, I suspect, other themes) have to throw !important tags over all over the place so that the desired changes persist everywhere. Unfortunately, that means they also overwrite many of my style selectors.

I noticed the same sort of problem with the self-study quiz: I couldn’t tell whether I answered correctly or incorrectly while using Breeze Dark until I finished the quiz!

Regardless, I want to be compatible with Breeze Dark specifically, so I’ll spend try to fix as many issues as I can find, but visual stuff like this is nearly impossible to test, so it’s kinda whackamole with the CSS.

In this specific case, the disabled state MUST be much more visible regardless of light/dark theme or specific color changes. It’s a usability thing that I need to research a bit to find the standard patterns.

EDIT

Note to self: https://stories.justinewin.com/disabled-buttons-dont-have-to-suck-10da0bb6d37e

EDIT 2:

It occurs to me that the current Appearance settings dialog doesn’t make it clear that the individual color inputs are INPUTS. It would be easy to overlook that you can change individual colors as well as picking a theme to set all the colors at once. I need to revisit the layout of the Appearance settings dialog.

EDIT 3:

Holy cats! I really screwed up the input validation. It’s always that one last thing you add before releasing. Anyway – I’m still working on fixing the validation logic. New version will be published today or tomorrow.

1 Like