Ah nice, you two definitely deserve these. And @rfindley if you ever make WKStats as a widget for the WK dashboard, you’ll get a keg
ありがとうございました
Version 1.17.0 is available - Please download it at the link in the top post.
Stroke count information for Wanikani radicals is now implemented. Use of stroke count in popups and filters now use this data on top of the existing stroke count data for kanji and traditional radicals.
I don’t think it’s a new version issue. Switching “Temporary Filters” seems to be working randomly, that is sometimes the change is applied, but sometimes just nothing happens. I didn’t yet find any patterns there, seems random. I’m using Tampermonkey on Firefox.
Temporary filters works every time for me.
I will need more data so I can try replicate the problem, otherwise I can’t solve it.
- What configuration do you use?
- Which filter is used?
- Most importantly, do you get messages at the console when it happens? Press F12 immediately when the problem happens and post a screenshot of the Console tab.
Neither a particular table nor temporary filter seems to matter here. I get this also with build in tables/filters, like “Leeches” and “Min. Current Streak >= 2”/“Min. Current Streak <= 1”.
And, unfortunately, no console messages.
I have tested this with built-in tables and filters including those you mention. I have tested Chrome/Tampermonkey on Windows. and Firefox/Tampermokey on Kubuntu Linux. I get flawless behavior at both places.
Random problems like this are the worst. Without a way to reproduce it I am powerless.
Seems like I found the issue. In the eventHandlers()
there’s:
$select.click(function(){
var $this = $(this);
if ($this.hasClass('open')) {
selectTemporaryFilter();
$this.removeClass('open');
}else {
$this.addClass('open');
};
})
Click handler doesn’t get called when I open the list input, only when I select the item. So when I select the item there’s not open
class yet and the first if
statement gets executed (adding the class), not else
, where the selectTemporaryFilter()
gets invoked.
But then blur
happens and removes the class.
The click()
event is set for the <select>
, just doesn’t get invoked most of the times (strangely, it it got called few times; no idea why).
Ok, it gets pretty weird here… It depends on the scroll and the opened list position. If Firefox opens the list this (selected item away from the <select>
):
The
clik
fires. But if it’s like this (selected item on top of the <select>
):It doesn’t.
I disagree. The first click opens the dropdown. The second click selects the filter. You need two clicks to get the job done. This code works correctly.
Blurs is for when you click outside of the dropdown instead of selecting an option. It returns the dropdown to its normal closed state and the class has to follow.
This code lets you select the same filter twice in row in a dropdown. For example when you need to use Global search twice in succession because you have two searches to perform. Using a change handler instead of two clicks won’t detect a change when you pick the same option twice in a row.
Well, this is how it behaves in my browser. I’m not pushing towards using the change
event.
Please see my updated answer.
I have tested two versions of Firefox, one on Windows and one on Kubuntu Linux.
- None of them show a tick mark besides No Temporary Filters
- Both never display the dropdown list on top of the selector.
It looks like your version has some peculiarity mine don’t have. If it bothers you you may try replacing the click handling routine with this line of code
$('#WkitFilterSelector').change(selectTemporaryFilter);
I have not tested it but it should work. You will lose the ability to pick the same filter twice in a row but you dropdown may become more predictable.
Temporarily I can just scroll up and down the get the handler called
Anyway, there’s no problem with your script itself. Thanks for looking into this!
I am curious. Which version of Firefox do you use? The problem does not occur with current versions on both Windows and Kubuntu. Could this be something that could be resolved by upgrading your version to the latest?
Yeah, tried it on both Windows and Linux and couldn’t replicate this. Seems to be the case only on Mac (using the newest Firefox).
I noticed that the problem doesn’t occur when using the mousedown
event. Maybe upon clicking Firefox registers the mousedown
event on the <select>
, but then the option list pops up and the mouseup
event is registered on the list, not making it a full click on the <select>
element?
Anyway, could you consider changing the event to mousedown
? I don’t see any downsides of doing that.
This diagnosis makes sense. I will test the mousedown event workaround. It will take a while. There is a new version coming up and if I go forward with this I will put it in this version.
It works fine in Firefox but it doesn’t work on Chrome. I can’t use this workaround, sorry.
Version 1.18.0 is out - Please download it at the link in the top post.
There are a few bug fixes. The most significant one has plagued @adr-p . Users of Firefox on MacOs suffer from an intermittent Temporary Filters dropdown. Other OS are not affected.
The solution is a workaround that seems to work only on Firefox. I have verified that it doesn’t work on Chrome. Therefore this workaround must be enabled by a setting. If you use Firefox on MacOS go to the Settings page and scroll down to the bottom to enable the workaround. You will need to refresh your browser for the setting to take effect. If you don’t use Firefox on MacOS don’t use this workaround unless you have verified that you suffer from this bug too.
There is also a new filter: the Kanji Picker. It is now available in the Temporary Filters defaults filters. This filter lets you pick the radicals from their Japanese characters and the kanji that use the radicals are selected. There is some duplication between this filter and the Related Items Filters.
- Related items also lets you search kanji by radicals if you choose the “Components of Matched Items” option. The other options are not duplicative with Kanji Picker.
- Related Items require that you type in the characters or English meaning of the radicals.
- Kanji Picker requires that you click on the radicals icons based on your ability to recognize visually the characters.
- If you give more than one search term to Related Items kanji matching any of the search terms are returned.
- If you pick more than one radical in Kanji Picker kanji matching all picked radicals are returned.
- You have the choice between Wanikani or Traditional radicals.
- They are classified by stroke count.
- A darker background for the count icon indicates which count is in used.
- The thick border indicates which count has radicals selected in them.
- Selected radicals also have a thick border.
- Kanji corresponding to your picks are automatically displayed.
- If the kanji list is empty it means no kanji are matching your picks.
When you move your mouse over a radical or a kanji some information popups up. In the example below the mouse was moved over the Bow radical.
Wow, thanks! Flawless!
Version 1.19.0 is out - Download it at the link in the top post.
This version implements changes in filters.
The filter called “JLPT level with vocab
” is renamed to “'JLPT with voc (by kan lvl)
” to distinguish with a new filter called “JLPT kanji and vocab.
”.
The old filter treated JLPT data for vocab by looking at the JLPT levels of the constituants kanji and reported about that. But @NicoleIsEnough pointed out this is not how JLPT works. They assign a level to the vocabs most commonly used at a given level regardless of constituents kanji. Jonathan Waller has collected the data on which vocab items belongs to which level. The new filter uses this data… In short
-
JLPT with voc (by kan lvl)
identifies the JLPT level of the constituents kanji. -
JLPT kanji and vocab.
identifies the correct JLPT level for vocabs.
Also there is a new version of the Joyo, JLPT, Frequency
optional filters which also implements the filter changes mentioned above. If you use these optional filters you should clear the cache with the “Empty Item Inspector Cache” button in the Settings tab of the settings. This will force Item Inspector to reload a current copy of all its files, including the optional filters. If you don’t click this button there is no big deal. The cache will clear itself eventually. It takes anywhere between 0 minutes and 60 days for this to happen depending on when was the last time the cache cleared itself.
Finally the JLPT data displayed in popups is modified to factor the issue of JLPT level mentioned above. You can have JLPT data for vocabulary either inferred from the constituent kanji or according to their true JLPT levels.
This script is incredible and infinitely useful when paired with Self Study Quiz. Thank you for all your work on this!