[Possible Bug] Skip dictionary over on button tap not working
- Thread starter Cameroon
- Start date
That's odd - which one? Is it a Pleco-supplied dictionary or a user one? Is this happening in the regular search screen or the document reader or somewhere else?
I made a clean experiment on MOEdict, but that was after I'd found this bug (?) on several Pleco internal dicts as well as a pair of user ones.
I'll also try to reproduce it on a virtual Android installation a bit later, as right now it's busy compiling another dictionary...
It's happening on popup window when browsing through entry's contents, have to try it on reader as well.
Updated: checked in clip reader, the same situation (MOE enabled in reader, skip over on button tap and don't show in menu checked):
but only the menu no-show works:
while skip on tap option has no effect:
There's also another question, though closely related: is it possible to have some dictionary in popup but not in the 'View in Dictionary' window?
I have the same set of dicts in both modes whatever settings I try (they are controlled by 'Show in Reader' option).
Only managed to have different set in the 'Search' view (after tap on the selected entry and opening available definitions it shows contents from all the dicts installed AND activated in 'Show in Dictionary'). But as this view is two taps further (compared to 'View in Dictionary') so I use it way less than the 'View in Dictionary' which is only single tap away.
To make it clear, the aim is to have (1) a narrow set of dicts in the tap cycle (in popup), (2) a bit wider one to select from when you tap on dictionary icon (on popup) and finally (3) have all the dicts' definitions in the 'View in Dictionary' view (plus from the latter I want to exclude two duplicate dictionaries with compact layout which are only intended for condensed view lookup in the popups (1); these duplicates have their full copies in expanded layout to view in full-window mode).
I'll also try to reproduce it on a virtual Android installation a bit later, as right now it's busy compiling another dictionary...
It's happening on popup window when browsing through entry's contents, have to try it on reader as well.
Updated: checked in clip reader, the same situation (MOE enabled in reader, skip over on button tap and don't show in menu checked):
but only the menu no-show works:
while skip on tap option has no effect:
There's also another question, though closely related: is it possible to have some dictionary in popup but not in the 'View in Dictionary' window?
I have the same set of dicts in both modes whatever settings I try (they are controlled by 'Show in Reader' option).
Only managed to have different set in the 'Search' view (after tap on the selected entry and opening available definitions it shows contents from all the dicts installed AND activated in 'Show in Dictionary'). But as this view is two taps further (compared to 'View in Dictionary') so I use it way less than the 'View in Dictionary' which is only single tap away.
To make it clear, the aim is to have (1) a narrow set of dicts in the tap cycle (in popup), (2) a bit wider one to select from when you tap on dictionary icon (on popup) and finally (3) have all the dicts' definitions in the 'View in Dictionary' view (plus from the latter I want to exclude two duplicate dictionaries with compact layout which are only intended for condensed view lookup in the popups (1); these duplicates have their full copies in expanded layout to view in full-window mode).
Last edited:
I see, thanks for the info.
I discovered this option to be 'not working' long time ago but didn't understand then all the power it could bring ))
Now it's 'working but not as (I) expected', rather.
Still, can this 'skip' option be also added to the 'bubble popups' set of dictionaries (the 'use in reader' ones)? That promises to be quite handy.
Also where is this button in the search screen, on tap of which the dicts can be skipped? I only see such button (with the dict name abbr.) in 'bubble popups' but not anywhere in the search screen...
I discovered this option to be 'not working' long time ago but didn't understand then all the power it could bring ))
Now it's 'working but not as (I) expected', rather.
Still, can this 'skip' option be also added to the 'bubble popups' set of dictionaries (the 'use in reader' ones)? That promises to be quite handy.
Also where is this button in the search screen, on tap of which the dicts can be skipped? I only see such button (with the dict name abbr.) in 'bubble popups' but not anywhere in the search screen...
Last edited:
It's the button to the right of the search bar, for switching between dictionaries (or dictionary groups). "Skip on button tap" is enabled on every dictionary by default, so that you're only switching between groups, but if you turn it off you'll be able to search individual dictionaries on that screen too.
oh, now I got it as it is (not the way I dreamt it was)
Anyway maybe you'll use it someday in future updates, if not in 3 then perhaps in 4th version.
Under 'this feature' I mean different sets of dictionaries for different scenarios, mainly (1) popup in reader etc and (2) full screen view as in 'View in dictionary' + ability to skip on tap in popup for some dicts given that customizing the dictionaries' menu on long tap is already implemented.
Anyway maybe you'll use it someday in future updates, if not in 3 then perhaps in 4th version.
Under 'this feature' I mean different sets of dictionaries for different scenarios, mainly (1) popup in reader etc and (2) full screen view as in 'View in dictionary' + ability to skip on tap in popup for some dicts given that customizing the dictionaries' menu on long tap is already implemented.
We've added more customization about which dictionaries show up in specific views, but at the moment we actually aren't even planning to offer an option to separately configure which dictionaries are reachable on a button tap versus which ones only show up in the menu at all anymore. It only works in the search screen in 3.0, and the default search screen design in 4.0 no longer has a button at all - it has a segmented control for Chinese / English, with English consolidating E-C and full-text C-E entries in a single list of results, and then when the search box is closed and empty there's a list of dictionaries that takes you to what are basically browse-screens-with-search-boxes for each dictionary.
Is there a particular reason you're looking to have dictionaries in the menu but not on button tap? Would it be sufficient if the menu displayed *all* dictionaries and the customization only applied to tap cycles? Having a second set of visibility settings for the menu is a lot of extra checkboxes for something I'm skeptical many people would use.
Is there a particular reason you're looking to have dictionaries in the menu but not on button tap? Would it be sufficient if the menu displayed *all* dictionaries and the customization only applied to tap cycles? Having a second set of visibility settings for the menu is a lot of extra checkboxes for something I'm skeptical many people would use.
Seems that 4th version would be more than just a major update, can't wait to try
First let me name all the instances we might use in the possible upcoming dialogue ))
My 'would-be-consept' is actually inspired by these dictionary filtering options in Pleco's settings, which seemed very natural:
(1) 'Tap-cycle' group (selected by 'Use in reader' option minus those with ticked 'Skip on tap', but as we found out later, this 'Skip' option is for another use and wasn't intended to work here - so it doesn't).
Used for quick lookup in most general, comprehensive dictionaries (like Pleco, ABC, Cedict etc).
The advantage of narrowing this group is in not having to tiresomely cycle-tap through multiple dictionaries but only thru the chosen ones.
It's essential however to switch to other (successful) dictionaries if no matches are found in this basic group. Otherwise we won't be able to find the word absent in this group (though available in other dicts) through bubble popup, which is unacceptable.
(2) 'Long-tap menu' group (selected by 'Use in reader' option minus those with ticked 'Don't show in menu' - in fact dictionaries from 'Use in dictionary' are used here as basic group instead! - maybe it's a contradictory error here, one of consequences is that you can tap the dict that exists in the menu but not in the 'Use in reader' group - and so this tap would result in nothing).
Extended group for additional dictionaries which would make the 'Tap-cycling' too long and hence not added there.
Takes a few moments longer to get to it (1 long tap + 1 short tap compared to single short taps in 'Tap-cycle' group). Takes longer => but gives more options, sounds logical to me ))
(3) 'View in reader' group. Is formed from dictionaries with 'Use in reader' tick-box active. Opens on tapping appropriate button. Now in fact is equal to the (1) 'Tap-cycle' group. Could be used to include all dictionaries, including the most rare and exotic ones. I guess shall be used as basic for the (3) 'Long-tap menu' group but it isn't, instead the (4) group is used now (in detail below).
(4) 'Search' group. Is formed from dictionaries with 'Use in dictionary' tick-box active. Opens on tapping appropriate button. Can be used as another custom set of dictionaries (already implemented and works). Is mistakenly (?) used now instead of the (3) 'View in reader' group as a base group for the (2) 'Long-tap menu' group.
The short answer is 'yes'.
The long one: cycle through the pre-select dicts but lookup in all available not to miss a word and if found a better match, then force show results even from the dicts not in the 'Tap-cycle' group (further cycling in this case won't be possible, tapping shows only successful dict(s) like Pleco behaves in similar cases). Otherwise best match won't be captured, we'll have a 'worse match' instead (from the 'Tap-cycle' group dicts), and lookup this 'worse match' via long-tap menu in a dictionary, which might have the best match but, as it didn't participate in capturing - so it didn't provide this 'best' result.
But it would also be very convenient to keep untouched the existing 'Don't show in menu' option since some dictionaries are not needed in the bubble popup but are highly welcome in the 'View in dictionary'. Plus it's already implemented and working (except for the wrong basic 'Use in dictionary' group but that could and should be easily corrected I hope).
Pleco has so many options, details and choices but I've never seen a single not-needed one. Without any little and seemingly not-so-important (but in fact - the 'last mile') features Pleco won't be itself and that's one of the reasons I as well as many users around the world render Pleco as the best piece of software not only in the Chinese learning area.
Just recently I re-proved this to myself after having sorted out all the features Pleco has for flashcards, that was a real discovery )) Wouldn't have managed with all this until I had tried and understood every little option (each in its place, can't be removed or substituted) in the Flashcards section.
Last edited:
The code is totally different, so we would in fact have to re-implement it.
How about this: one set of 'primary dictionaries' that you'd cycle between with the button, plus a second set of 'fallback dictionaries' that would show up in the menu (in a separate group, below the primary ones) and still be eligible to come up automatically if none of the primary dictionaries had a result?
Sure - thanks! - but it doesn't mean that options can't be reorganized to be more logical. With the current distinction between button tap + menu dictionaries it's not really obvious what that means for those dictionaries in other situations, for example the fallback one I just mentioned. And just in general this single dictionary order with a bunch of checkboxes seems a lot less intuitive than customizing the order for dictionaries in a specific place.
That sounds just terrific!
And seems even better than I initially imagined.
Will in that case a tap on the 'View in dictionary' icon (now regulated by 'Use in reader' checkbox) bring up a separate, independent (different from these two primary and fallback groups) set of dictionaries?
This combination would be extremely convenient.
One of these other situations is flashcards which use the same behavior as popups as I understand, but seemingly the new algorithm you described ought to be fine with flashcards, too.
By default no, but at least in the current design you could redirect that button to pull up a custom definition screen + have it show you a custom list of entries based on your selected word. (the default behavior shows you precisely the same entries that came up in the reader)
How do we perform such remapping? Thought I explored all the settings Pleco has but seem to have missed out some important spot.
Are you evaluating this as a potential new feature for 4th version or is it even possible already in current version of Pleco?
Sorry, "current design" meaning the current internal builds of 4.0.
It's not possible now, I'm thinking about it as a way to replace this functionality in 4.0. There are a couple of other places in Pleco where a readily-accessible primary set of X and a menu-only secondary set of X also makes sense (and indeed a couple of other places we already use that approach).
That's fine, another reason to wait for version 4 now.
But does this mean 3rd version is already closed for all updates and no critical updates or bugfixes will be available either?
As to the abovementioned functionality, I guess the thing with 'long-tap' menu dictionaries is not about new feature's or enhancement introduction but the correction of an inconsistency in algorithm functioning, can this be granted a patch?
(the bug is that 'long-tap' menu dicts (in reader) are taken from those with 'Use in dictionary' active while it should be built from ones with 'Use in reader' ticked - as the logic was initially meant I suspect).
But does this mean 3rd version is already closed for all updates and no critical updates or bugfixes will be available either?
As to the abovementioned functionality, I guess the thing with 'long-tap' menu dictionaries is not about new feature's or enhancement introduction but the correction of an inconsistency in algorithm functioning, can this be granted a patch?
(the bug is that 'long-tap' menu dicts (in reader) are taken from those with 'Use in dictionary' active while it should be built from ones with 'Use in reader' ticked - as the logic was initially meant I suspect).
Last edited:
No, it's just that the threshold for "critical update" is pretty high. Bug fixes certainly, but what you're describing would not rise to the left of something we would fix in a minor update.