Feature Request -- Optional exact reading/meaning @ Kanji widget filters

[am2del]

Please don't missinrepet it as "it's bad the way it is", because it's deffinitly not. Sure got it's uses, however - as described below - part of it would be preferred as optional instead of enforced.

@ Filter: Reading --> Search for "か" gives same as regex "か", which should be optional as it makes it hard to narrow down single-kana readings. ----> E.g. desired results have the exact reading "か" (火, 花, 家, 歌 etc.), but currently - a lot of others are mixed in. Proposal: Add an enable/disable-button for this behaviour, like "+?" in Word- & Kanji-groups widgets. Optionally allow regex characters like "." and "" for this behaviour.

@ Filter: Meaning --> Search for "I" gives same as regex "i|I", which should be optional as it makes it hard to find certain specific kanji. ----> E.g. desired results of "i" should be possible to limit to 私, 僕, 儂 etc, instead of any kanji having a meaning containing the letter "i". Proposal: Add enable/disable-buttons for this behaviour, like "?+" & "+?" in Word- & Kanji-groups widgets. Optionally allow regex characters like "." and "*" for this behaviour. Disclaimer: Case-sensitivity is not a needed, this is probably preferred to be insensitive.

[z1dev]

After successfully narrowing the kanji search widget, I don't think it's a good idea to add buttons on it. Currently apart from the SKIP filter, the readings filter takes up the most space horizontally. Adding buttons to it will once again make the widget wider.

Considering some kind of simple regex might be a solution, but I still would like the current behavior to be the default. By this I mean the result should be the same as +? searches, since this is the most common use. There could be maybe a setting to turn on/off the regex altogether, and when turned off, revert to the current behavior?

[am2del]

Global toggle for regex I think is a bad idea.

How about maybe removing the button for Okurigana and the combo box for on/kun/both - and/or add a single button which pops up a window with checkboxes and labels? Parhaps visible next to "All" or "Reset" when Reading or Meaning is visible?

Popup content example:

ITEM       @Meaning   @Reading
+?             X          X
?+             X          -
KUN           N/A         X
ON            N/A         X
Okurigana     N/A         X

(X: Checked per default; -: Unchecked per default; N/A: Not Available) Or a tree-structure similar to the custom-filters -> ADD-window in the other widgets. (That window will close if attempting to move it btw, maybe not a good idea as it covers the names of present custom filters.)

Either of these types would allow expansion later for triggering user-defined regex etc. or other rarely used features.

Either way, I would favour this to stay local within the widget itself - easily accessable. Not going global or into settings.

[z1dev]

Popping up a window or even a tree-view sounds a bit complicated to me. This is what the right-click context-menu is for. It's not less in functionality and more standard. Where zkanji uses a nonstandard solution it's because the problem it solves is far from standard, but here it would work. Not to mention making a popup window and positioning/sizing it right is a lot of work.

If the custom filters window closes when moved, that's unintended and is a bug. I will look into it.

[am2del]

How about adding "Show/Hide Advanced Controls" to the context menu? When enabled will show "?+"/"+?"-controls for meaning, and "+?"/"KUN/ON"/"Oku."-controls for reading, when disabled they are hidden. This way it would stay slim, yet easily accessable when user needs to adjust these for individual filters.

[z1dev]

I'll need more time to think of this. I prefer the interface not to have "hidden" options, though it might be unavoidable. How about a single button after the fields, which itself just shows the context menu where you check/uncheck options? This way there would be a button for the menu, so people could easily discover it, and it'd stay slim.

[am2del]

That may be a good idea, placing an OPTION-button after the "All"-button? Otherwise I would place it in-before the filters and not after. Parhaps logical making it a cog-icon or a X of tools? Will allow slim-yet-user-friendly. That context-menu allows for easy tweaking/expansion with options if needed.

[z1dev]

I didn't mean exactly this way. I meant a button after the meaning text edit and same for reading, and just list the options in the context menu with checkboxes.

Do you have any feature requests that might need expanding the kanji filters? It was never the center of the program, and even the current request seems to be one that partially can be satisfied with the dictionary. If you search for "I" there, you will end up seeing many one or two-kanji words, and I'm sure most of the kanji would come up with the specific searches there. The reading is trickier I guess, so it might need the extra options.

It's difficulty to make a user friendly user interface that also provides all the needed features, because the author ends up adding more and more features that are hardly needed, or only in some rare cases. I see this in so many programs. I would like to only expand on anything if it really is useful.

[am2del]

I meant a button after the meaning text edit and same for reading, and just list the options in the context menu with checkboxes.

This sounds good.

Do you have any feature requests that might need expanding the kanji filters? ... I would like to only expand on anything if it really is useful.

Aside from those enable/disable "?+"/"+?", and possibly moving ON/KUN/Oku-buttons to such a context-meny - not that I can think of. I too prefer to not expand current views with things which are rare, as the regex- & example sentences browser-features I mentioned in early posts at #10 (maybe should be called "Advanced Search View" or something? and be dockable) would solve most of the "rare" needs at user-end. I still scetch on it, need to check what pieces of the source I can re-use and what I cannot, and discuss thoroughly with you before actually starting coding it. Probably writing a custom regex module limited to the needs. It will be kept "slim" as well, not many buttons nor menues. However - this is currently last on my TODO-list, don't expect no draft in the near future. Anyhow, it will have one major difference from the other views and search-modes though - it will NOT have instant lookup, but a traditional "Search"-button. Why? Due the the amount of data and complexity of regex, the search will chew performance if kept instant - very bad for low-spec machines, and/or battery life for portable machines. (Not like everyone got a 18-core i9 or Threadripper...) Sorry for straying a bit.

[z1dev]

[...] similar to the custom-filters -> ADD-window [...] (That window will close if attempting to move it btw, maybe not a good idea as it covers the names of present custom filters.)

I checked this on my virtual Linux, trying to reproduce the problem but it doesn't do it for me. Can you please check if the custom-filters listing window disappears too when moved, or just the new filter one?

[am2del]

It's only the final window which appears after clicking the ADD-button. I confirmed it dissapears on MOVE and CLICK OUTSIDE of widget. Want me to move this to a dedicated BUG-thread?

[z1dev]

It's only the final window which appears after clicking the ADD-button. I confirmed it dissapears on MOVE and CLICK OUTSIDE of widget. Want me to move this to a dedicated BUG-thread?

I changed how this works, so the last window copies the same method as the middle window. Can you check with that please? Although I did it not long before you wrote here, so you might have seen it still being bugged.

I tried several ways to add buttons on the kanji search widget, but I don't like either of the solutions yet. I'm still working on this, but I'm currently stuck. The meanings search is fine, but the reading search is giving me a headache. I tried a button with context menu, but it felt cumbersome. I also tried just a button that shows/hides the controls and no context menu, and while this works, the extra buttons make it impossible to keep the widget at the same width that I'm used to. To begin with, the on/kun combo-box takes up a lot of space that I didn't like before either. Now I'm thinking of adding an extra row just for the controls when the search widget is not wide enough to show everything, but this would make this one filter look different from the others.

I will continue experimenting, but this takes up a lot of time and doesn't feel very productive at the moment.

[z1dev]

I have decided on a design for the searches. Both reading and meaning will only have +? buttons both for speedy search and for interface size. I replaced the on/kun combo box with the [≠] button which is also used on the dictionary widget. If it's pressed, entering hiragana will search for kun and katakana will search for on readings. This way every button can be visible at all times. The kanji search widget was meant to be a fast and compact way to search. If we need something more complex, it'll have to be its own window.

[am2del]

Build (UTC): 2018-01-29 @ 15:26

I have decided on a design for the searches.

It looks better than before I'd say, good job! Users require an actual input-method (such as iBus) to enter KATAKANA into the field as the built-in only converts to HIRAGANA, but this should be USER-END and not built-in. If they study Japanese and don't bother installing support for typing, they got themselves to blaim I say.

The kanji search widget was meant to be a fast and compact way to search. If we need something more complex, it'll have to be its own window.

Can't agree more. Current widgets should be kept this way - complex things could all go into the optional "Advanced Search"-widget when I get started with it. Side note, kinda related - kinda not. Thank you for the status bar, it shows just the right info. Just one minor detail, if not too much work - to keep the slim/compact interface, would it be possible to move it down to same row as the "View"- & "Dictionary"-buttons?

I changed how this works, so the last window copies the same method as the middle window. Can you check with that please?

The MIDDLE window is copying the LAST window's behaviour you mean? Anyhow, it's an improvement - parhaps this is a good solution as it works and behaviour is consistant. POSITIVE: The ADD-window doesn't cover the FILTER-window. NEGATIVE: Now NEITHER can be MOVED and BOTH will dissapear on CLICKOUTSIDE. (NOTE: CLICK on WINDOW_FRAME = CLICKOUTSIDE behaviour.)

Close this thread, unless you wish to change the FILTER- & ADD-windows again. Maybe preferred this way as they are popups, only issue I can see is if someone wish to copy a name and paste into the ADD-window - and forgot to to the COPY in-before opening it.

[z1dev]

You can type katakana in any Japanese input field in zkanji using capital letters with caps lock or shift key.

[...] the status bar, [...] would it be possible to move it down to same row as the "View"- & "Dictionary"-buttons?

Those are unrelated widgets so it needs a little planning but nothing is impossible.

The MIDDLE window is copying the LAST window's behaviour you mean?

I haven't touched that one, so maybe it was always broken too but you never had to move it. I couldn't find the reason why this might happen, so we will be stuck with it for now. It might be a Qt bug or incompatibilities with Gnome or what else you are using.

[am2del]

@ Request to move the status-bar: I got a screenshot from my acquaintice today, the one who intitially brought this to my attention. Using an older 14" laptop @ 1280x800 with KDE 5.42.0 / Plasma 5.11.5 (Dark Breeze theme with blue font) - the screenshot is taken in super-fullscreen mode, a borderless full screen mode which allows application to use the entire screen. If you didn't know, activate @ System Settings -> Shortcuts -> Global Shortcuts -> KWin -> Make Window Fullscreen. A single shortcut will toggle any window in/out of this mode. Anyhow, similar resolution is quite common on laptops today - @ 16:9 ratio instead, especially cheaper ones. As seen, the status bar eats space for small screens / low resolution... maybe overkill using all views at once, but - easy to tell there was enough space for it in-before the status bar was added.

@ Dissapearance on MOVE/CLICK_OUTSIDE: My acquaintice confirmed this is NOT an issue in pure KDE/Plasma, at least not using Build (UTC): 2018-02-01 @ 20:31. (The screenshot above is from this build.) Hence I made some experimenting, with Build (UTC): 2018-02-02 18:22 Disabling the GTK2-wrapper (e.g. using pure QT instead of fusing with DE) doesn't change a thing for me, so it's not related to theming. Seems to me this is a WM issue, as I tried...: (tried all with and without the wrapper) --> Compiz 0.8-series (0.8.14-5) with Emerald 0.8-series (0.8.14-1), --> KWin (5.11.5-1, X11-version), and --> XFWM4 (4.12.4-1) ...under XFCE 4.12 and turns out only KWin work the way you intended. So shouldn't be the DE causing it. Compiz is a stand-alone WM for X11, but doesn't natively include frames/decorations in order to allow maximum user freedom. Emerald was made as companion for Compiz. Probably the most "complete" and customizable WM ever made, extrodinarily popular. (NOTE: Compiz 0.9 is NOT an update of Compiz 0.8 as 0.9 is a re-written version limited to the needs of Ubuntu's DE called "Unity", which was announced abandonned as of Sept 2017.) KWin is bundled with KDE/Plasma, but can be used as stand-alone. (NOTE: I have not tested KWin under Wayland - only X11.) XFWM is bundled with XFCE, but can be used as stand-alone, very light-weight. XFCE altogather is optimized for speed on low-spec machines, while on high-spec its responsiveness is ridiculus. Either way, I have not experienced these kind of issues with any other application built with QT-libraries - so I am guessing there should be a way to solve it. It's not a big deal, but functionallity shouldn't be bound to choice of WM. Oh, btw - X-server (and utils) version: 1.19.6

PROPOSAL: Convert these windows into same type as the "Kanji Information Dialog". This will solve the issues. This could work for "Handwriting recognition window"-thingy too.

Handwriting: I noted there is an option for the "Handwriting recognition window" which I never payed much attention to: Display position Handwriting-widget, even in pure KDE/Plasma, cannot be moved or resized - doesn't even have a frame and disapears on CLICK_OUTSIDE. What is this option for really? Not yet connected? Depricated? Bringing it up here as I got a request from my acquaintice which really made sense regarding this widget - add it as a FILTER-option @ the "Kanji Search"-widget and allow the suggestions to pop-up in the large area there. This may require some work I guess, but it sounded like a logical request - hence I forward it to you.

[z1dev]

I do agree about the status bar and that was planned all along to move it next to the buttons. It's not a big issue.

The other issues seem to be mainly a problem because there is no real standard on Linux, how the WM should handle some situations. It looks very chaotic to be honest. I design the UI with usability in mind, and because of that, sometimes I have to step outside the boundaries of what Qt was designed for. It has HUGE limitations on what you can do with it, and now I kinda understand why. If I were to only use the standard controls and for example not replace the WM provided borders on some windows, zkanji would be clunky to use and would block the desktop space more. The reason why other Qt applications don't have the problems that zkanji does is because they provide much simpler functionality and can go with the standard ways to achieve them.

I'm still hoping all features can be implemented satisfactorily, but I'm just a single person, who can't test on every kind of systems. I hope programmers used to Linux will eventually join to debug the issues and suggest solutions there.

By the way, do you know if there's a standard method on Linux to programmatically ask the WM about its capabilities and how it does things? My guess is "no" but it doesn't hurt to ask. Even if it's possible, it might not answer all issues.

Convert these windows into same type as the "Kanji Information Dialog". This will solve the issues. This could work for "Handwriting recognition window"-thingy too.

I don't understand what you mean here by same type. Both the kanji info window and the handwriting one are custom borderless windows. I handle the mouse clicks on them. The dictionary filter windows are rather standard, with the only difference is that I check if they lose the active status and then hide them. If they disappear, the window manager might say they are not active when their window border is active instead, which seems nonsense to me, but I can imagine that's what's happening. They could be turned into standard dialog windows, that block the window below them, since that's the same functionality, but then you have to hide them specifically.

Handwriting-widget, even in pure KDE/Plasma, cannot be moved or resized

It works for me, but you have to grab it on the right side toolbar. It's more suspicious if the resize doesn't work for you. Does it at least change the appearance of the mouse cursor when you move it close to the edges?

[z1dev]

The dictionary filter windows disappearing should be solved for now. I rewrote the whole thing, getting rid of the edit window, and integrating the controls next to the filters list. The window won't disappear now unless you press ESC while it's active or close it manually. I would have preferred if it does when it loses focus, but it's not that important and I don't want to waste any more time on this. There might still be issues when editing/adding new filters, but that should be much easier to solve.

[am2del]

I'm still hoping all features can be implemented satisfactorily, but I'm just a single person, who can't test on every kind of systems.

You're doing a great job - hats off for you! (See post: #13)

@ Resolution/positioning/WM I will open a new thread and reference to this thread.

Both the kanji info window and the handwriting one are custom borderless windows. [...] The dictionary filter windows are rather standard, with the only difference is that I check if they lose the active status and then hide them. [...] They could be turned into standard dialog windows, that block the window below them, since that's the same functionality, but then you have to hide them specifically.

Something along these lines would probably be preferred in other words, also disregards WM-issues. This could be applied to "Kanji Information Dialog" too, having a uniform base-widget where the content, size and position changes based on which function it's used for? Just to clarify a bit, and please get me right here, the AUTOHIDE IS a NICE touch - but not always desired.

What I ment was to perhaps turn these "rather standard" FILTER- & ADD-windows into "standard dialog" of some sort, and possibly deactivate the AUTOHIDE on losing focus. Especially the AUTOHIDE for handwriting can be a little bit annoying, especially as it resets content upon hiding.

EXAMPLE: Say zKanji covers the entire screen (as user got limited resolution at hand, like in that screenshot) and the kanji/word which is to be looked up is in an image, or picture - and the user need to switch between zKanji and the image/picture. But with each switch the handwriting close and reset, it can be quite annoying - right?

A solution could be a simple TOGGLE-button, like the PIN-feature in any Linux WM, which allows _(de-)activating the AUTOHIDE on windows on-the-fly. (Refer to the KDE/Plasma tray pop-ups for inspiration on PIN.)_

It works for me, but you have to grab it on the right side toolbar. It's more suspicious if the resize doesn't work for you. Does it at least change the appearance of the mouse cursor when you move it close to the edges?

I need to check on this, and have my acquaintance with the KDE/Plasma laptop take a look as well in-before making any statement. I'll get back to you on this.

[z1dev]

Please try the latest sources for the dictionary filter window. I changed it to not be hidden automatically. I might change it again back to auto hide, but only when another widget is activated within the program. The bug with the auto hiding was due to the WM or Qt misbehaving when you clicked on the window title bar or border. At least Qt thought this window lost the focused / activated state. The difference would be that I don't check when the window loses focus, but instead when other widgets gain focus. There are several difficulties with this though, so I might just keep everything as is right now.

This could be applied to "Kanji Information Dialog" too, having a uniform base-widget where the content, size and position changes based on which function it's used for?

If it worked that way, you couldn't open several kanji information windows. You can do that right now if you lock them with the lock button. It also sounds error prone. The logic behind such feature could be difficult to implement.

the AUTOHIDE for handwriting can be a little bit annoying, especially as it resets content upon hiding.

That's a bug on my side. The Windows only versions didn't do that because of the same reason. I still prefer that window to auto hide, but it will retain the existing writing on it.

[z1dev]

I will close this issue because the problem mentioned in the title is solved for a while now. If anything else discussed is still broken, please open a new issue for them.