z1dev / zkanji Goto Github PK

Any chance of OSX build?
With OSX Cataline Wine won't work anymore, meaning I can't run old zkanji binaries 😢

Zkanji V 0.0.0.3 portable
win7x64

it's possible that I don't understand this function correctly
don't shoot when I'm wrong
I'm just trying to be a friendly domesticated fox

Menu > Dictonary > Manage Dictionary > Create new > Enter name > click ok
works fine
select new dic
works fine
Menu > Dictionary search > New word to dictionary > bla bla bla > save
works fine
Restart Zkanji
New dictionary is gone
editing the states.xml directly [who knows] does not do the trick

tried al lot
looks like the program got a short term memory lost
it will not save the new dic
or it doesn't know how yet

[EDIT: some info]

Who :

User

What :

Allows user to see the example sentences in word group.

Why :

Currently use is able to see example sentences in "Dictionary Search" view. However, when same word is added in "Word Group" he cant see example sentences.
Not sure if there is any setting to enable it, which i couldn't find. Please consider and decide the priority.
This allows users effort during revision.

Open zkanji v0.1.0 eacaa02. Double click on any kanji in the list which is shown by default. Press on the play button.

Backtrace:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff1b84700 (LWP 31180)]
[New Thread 0x7fffeb8db700 (LWP 31181)]
[New Thread 0x7fffeb0da700 (LWP 31182)]
[New Thread 0x7fffea44e700 (LWP 31188)]

Thread 1 "zkanji" received signal SIGSEGV, Segmentation fault.
0x00005555556e08ae in KanjiElementList::strokeCount(int, int) const ()
(gdb) bt
#0  0x00005555556e08ae in KanjiElementList::strokeCount(int, int) const ()
#1  0x00005555558480af in ZKanjiDiagram::play() ()
#2  0x00005555558f8101 in KanjiInfoForm::qt_metacall(QMetaObject::Call, int, void**) ()
#3  0x00007ffff5d734f7 in void doActivate<false>(QObject*, int, void**) () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Core.so.5
#4  0x00007ffff7395192 in QAbstractButton::clicked(bool) () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Widgets.so.5
#5  0x00007ffff7395394 in QAbstractButtonPrivate::emitClicked() () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Widgets.so.5
#6  0x00007ffff7396f2f in QAbstractButtonPrivate::click() () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Widgets.so.5
#7  0x00007ffff7397095 in QAbstractButton::mouseReleaseEvent(QMouseEvent*) () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Widgets.so.5
#8  0x00007ffff747844a in QToolButton::mouseReleaseEvent(QMouseEvent*) () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Widgets.so.5
#9  0x00007ffff72e8728 in QWidget::event(QEvent*) () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Widgets.so.5
#10 0x00007ffff7478519 in QToolButton::event(QEvent*) () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Widgets.so.5
#11 0x00007ffff72a9a7c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Widgets.so.5
#12 0x00007ffff72b1208 in QApplication::notify(QObject*, QEvent*) () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Widgets.so.5
#13 0x00005555558cf8cd in ZApplication::notify(QObject*, QEvent*) ()
#14 0x00007ffff5d3cae8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Core.so.5
#15 0x00007ffff72b01fa in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool, bool)
    () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Widgets.so.5
#16 0x00007ffff7301e41 in QWidgetWindow::handleMouseEvent(QMouseEvent*) () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Widgets.so.5
#17 0x00007ffff7304a8b in QWidgetWindow::event(QEvent*) () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Widgets.so.5
#18 0x00007ffff72a9a7c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Widgets.so.5
#19 0x00007ffff72b0cb0 in QApplication::notify(QObject*, QEvent*) () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Widgets.so.5
#20 0x00005555558cf8cd in ZApplication::notify(QObject*, QEvent*) ()
#21 0x00007ffff5d3cae8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Core.so.5
#22 0x00007ffff6797ad8 in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) ()
    at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Gui.so.5
#23 0x00007ffff6798fb5 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) ()
    at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Gui.so.5
#24 0x00007ffff6775bdb in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
    at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Gui.so.5
#25 0x00007ffff22f1e7a in xcbSourceDispatch(_GSource*, int (*)(void*), void*) () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5XcbQpa.so.5
#26 0x00007ffff30fd8bd in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x00007ffff30fdb40 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#28 0x00007ffff30fdbe3 in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#29 0x00007ffff5d9555c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
    at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Core.so.5
#30 0x00007ffff5d3b502 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Core.so.5
#31 0x00007ffff5d44430 in QCoreApplication::exec() () at /opt/Qt5.14.0/5.14.0/gcc_64/lib/libQt5Core.so.5
#32 0x00005555555feba0 in main ()

It looks like KanjiElementList::strokeCount is given -1 for some reason and list.size() == 0 and you are using that externally given index to access an internal vector without any checks resulting in this segfault.

I'm being a bother again, but this isn't urgent at all - just would be nice if concidered someday later on. Quite easy implementing I think, as it already exist for old user data.

Easing up setup & manual update of dictionary files when flags such as -i, -e or -ie are triggered WITHOUT a specified PATH. A simple GUI_BROWSE which is triggered upon cases like this, and preferably allow to specify multiple PATH - in case user keep files at various locations for some reason.

Why? To simplify the process of adding a starter-option in the DESKTOP-file to perform this without needing to open a terminal or use of third-party tools. It will make things more user-friendly for users who aren't used to compiling nor manual install. Though, only *NIX-family systems use DESKTOP-file(s) which support additional CONTEXT_MENU-/starter-options. It should be possible to attach similar option to the Windows-version as well - just straight on the EXEC_CONTEXT_MENU. (How to add those is beyond me, but I know it should be possible.)

When I write the improved INSTALL-script, it will include generating a DESKTOP-file - it will give more of a professional impression having such ease-of-access options. Getting started with that as soon as the SVG's are finished (hopefully before February ends), unless - of course - you got something you wish for me to prioritize.

In the DESKTOP-file it'd be something like:

##Define Actions
Actions=Update-Setup-Dictionary-Example;A;

[Desktop Action Update-Setup-Dictionary-Example]
Name=Update or set-up dictionary & example files
Exec=zkanji -ie

[Desktop Action A]
Name=Just because
Exec=zkanji --Flag-for-random-example
##End of actions menu

On Linux, in an application menu, instead of regular click - try MENU_CLICK on a starter for something like Mozilla Firefox, LibreOffice etc and you'll see a sample of quick-options of this sort.
And yes, I call it MENU_CLICK as it's the most accurate - as this world doesn't consist exclusively of right-handed people using traditional PC-style mouse. I wish to cease discrimination of all lefties (20~25% of the world?) as well as all them using stylus, touch-screen, single-button mouse etc.

--

An option, or addition, to above would be to allow zKanji to start without the dictionary files already set up, having an option @ Dictionary -> Manage dictionaries where user can select and add/update thus allow on-the-fly adding/updating while using zKanji. On-the-fly would be nice especially for people who got low-spec and don't want to do nothing during the 15~30min it could take them to set up dictionary files. (When finished, saving to disk as .new, and on next start either rename old to .old - or simply replace the old ones.)

NOTE: This could be a good way to ease up adding support for additional languages later on, as the source used do support more languages in same structure.

...or that was the original intent, but some serious problems have arisen.

I've decided to try with qmake first, gcc 5.4.

That means C++11 by default (and qmake explicitly adds '-std=gnu++11').

Well, the start wasn't all that bad (correcting to 'QtWidgets/QStyle' in zflowlayout.h and to 'smartvector.h' in zkanjigridmodel.h), but after that I've got a flood of errors.

I can't say yet if it's a c+11 problem or if gcc simply hates your templating style, but a couple of examples:

../smartvector.h:90:32: error: ‘operator+’ in ‘smartvector_iterator<T, Alloc>::self_type’ does not name a template type
     friend self_type ::operator+<>(int n, const self_type &);

../smartvector.h:103:46: error: expected nested-name-specifier before ‘basetype’
     smartvector_move_iterator(const typename basetype &base) : base(base) {}
                                              ^
../smartvector.h:103:55: error: expected ‘,’ or ‘...’ before ‘&’ token
     smartvector_move_iterator(const typename basetype &base) : base(base) {}
                                                       ^
../smartvector.h: In constructor ‘smartvector_move_iterator<T, Alloc>::smartvector_move_iterator(int)’:
../smartvector.h:103:73: error: expected primary-expression before ‘)’ token
     smartvector_move_iterator(const typename basetype &base) : base(base) {}

./smartvector.h: In member function ‘smartvector_move_iterator<T, Alloc>::self_type smartvector_move_iterator<T, Alloc>::operator+(int) const’:
../smartvector.h:110:63: error: there are no arguments to ‘_base’ that depend on a template parameter, so a declaration of ‘_base’ must be available [-fpermissive]
     self_type operator+(int n) const { return self_type(_base() + n); }

../smartvector.h:237:39: error: redeclaration of ‘typedef typename smartvector<T, Alloc>::base::size_type smartvector<T, Alloc>::size_type’
     typedef typename base::size_type  size_type;
                                       ^
../smartvector.h:225:38: note: previous declaration ‘typedef typename smartvector<T, Alloc>::base::size_type smartvector<T, Alloc>::size_type’
     typedef typename base::size_type size_type;

../qcharstring.h: In instantiation of ‘bool operator==(const STR&, const QCharString&) [with STR = QStringRef]’:
../qcharstring.h:305:79:   required from here
../qcharstring.h:305:79: error: explicit instantiation of ‘bool operator==(const STR&, const QCharString&) [with STR = QStringRef]’ but no definition available [-fpermissive]
 emplate bool operator==<QStringRef>(const QStringRef &a, const QCharString &b);

That's not the complete output for collectwordsform.cpp, but should give you the general idea.

When building just ~5min ago (see time of post), I get error and abort so until fixed I cannot verify the things requested. (Don't got the time to trouble-shoot, sorry...)

QT5 version: 5.10.1-1~5
QT Creator: 4.5.2-1 <-- Same error.
Build string: qmake "zkanji.pro" -spec linux-g++ -Wall CONFIG+=debug CONFIG+=qml_debug && make
Log:

[...]
settings.cpp: In function ‘void Settings::loadIniFile()’:
settings.cpp:1047:37: error: cannot bind non-const lvalue reference of type ‘std::vector<char>&’ to an rvalue of type ‘std::vector<char>’
             kanji.showref.swap(std::vector<char>(kanjirefcnt, (const char)1));
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/c++/7.3.0/vector:64:0,
                 from /usr/include/qt/QtCore/qmetatype.h:53,
                 from /usr/include/qt/QtCore/qobject.h:54,
                 from /usr/include/qt/QtCore/qiodevice.h:45,
                 from /usr/include/qt/QtCore/qxmlstream.h:43,
                 from /usr/include/qt/QtCore/QXmlStreamWriter:1,
                 from settings.cpp:7:
/usr/include/c++/7.3.0/bits/stl_vector.h:1229:7: note:   initializing argument 1 of ‘void std::vector<_Tp, _Alloc>::swap(std::vector<_Tp, _Alloc>&) [with _Tp = char; _Alloc = std::allocator<char>]’
       swap(vector& __x) _GLIBCXX_NOEXCEPT
       ^~~~
settings.cpp: In function ‘void Settings::loadSettingsFromFile()’:
settings.cpp:1302:20: warning: enumeration value ‘NoError’ not handled in switch [-Wswitch]
             switch (reader.error())
                    ^
settings.cpp: In function ‘QFont Settings::kanjiFont(bool)’:
settings.cpp:1334:26: warning: unused parameter ‘scaled’ [-Wunused-parameter]
     QFont kanjiFont(bool scaled)
                          ^~~~~~
make: *** [Makefile:3332: settings.o] Error 1
  [ERROR]  Error during build using 'make'! Exiting!

Hopefully I get an hour or two tomorrow to check the things which you wanted verified.

Sorry. Too busy with work lately and probably until the end of this month.

Unless I'm missing something, the reasonable way would be that the radical filter is an AND filter (kanji contains ALL of the radicals/parts). But - unless I'm missing something, it's currently an OR filter (kanji contains ANY of the radicals/parts).

...???

As requested: https://zkanji.wordpress.com/2018/03/02/zkanji-test-4/

Like title says, someday in the future parhaps?
Please do concider this (if it's not already planned) as I believe many will appriciate this type of feature, especially if connected to 常用-grades, JLPT-levels and user-defined Kanji-groups.

If card-printing is to be available, please do collect additional oppinions on what should be present - as well as in regards to layout.

Eventually, if so desired, I may lend a hand in this feature if you want - as it can be plenty useful for users... just need to find the time to finish the SVG's and that Radical Browser first. Odd ISO-weeks I won't have much time for anything for a while to come.

A few questions: (As reference, see ASCII & Description below.)
--> Will/Should this feature include printing double-sided cards? (Also concider some doesn't have duplex, may need to print with time for manual flip.)
--> Will/Should the structure be dynamic/customizable? (Customizable by user.)
--> Will/Should it include preset to print a full 常用-grade or JLPT-level? E.g. not just user-defined groups. (Also see NOTE(s): 1 & 2)
--> Is it reasonable to include similar printing radicals? Maybe also a preset option to include an additioal print with radicals used in the kanji?
--> Does the page HEADER or FOOTER include something like "Printed with zKanji, for CREDITS and LICENCE see URL: https://github.com/z1dev/zkanji"? (Just to be on the safe side with things.)

I suppose it's possible to fit 10~21 cards per page - depending on margins, 2- or 3-column style and font-size/scaling... 3-column should work well in the world (ISO 216). Just need causion with the oddball North America (and associates) who, of-course like with anything else, must have their own standard. It's slightly "wider" - and either "shorter" or "longer" depending on case. (The "longer" is called LEGAL and its LENGTH ranges anywhere from 13.0" to 14.0" depending on region, hence - better count on LETTER-format.)
Standard paper sizes:

-->  World:               A4  (210x297mm/8.3x11.7" - approx. ratio: 1:1.4142)
-->  North America:   Letter  (216x279mm/8.5x11.0" - approx. ratio: 1:1.2941)

I would suggest making the best of both worlds, needing no concideration for these issues - setting the template output to maximum of 210x279mm/8.3x11.0", printed as centred with no-stretch. Allowing for single template regardless of local differences.
On a side note: The UK FOOLSCAP - former standard size in the UK - is very rare these days, therefore no need to take it into concideration.

What I state below is the result of brainstorming and discussing this topic with some acquaintances who currently do self-studies of Japanes - currently at "beginner"-levels.

Card-description, illustrative ASCII-art: (Could fit 10-21 cards per page depending on margins, 2- or 3-column style and font-size/scale?)

Side A, alt. 1: (Preferred)

 ________________________
|     |  2.         | 6. |
|  1. |  3.         |    |
|_____|_____________|____|
| 5.           | 4.      |
| ...          | ...     |
|______________|_________|

Side A, alt. 2: (Difference: "4." has moved up below "3." as a horizontal list instead and "6." has moved to bottom, not as space-efficient.)

 ________________________
|     |  2.              |
|  1. |  3.              |
|_____|__4._________ ____|
| 5.                | 6. |
| ...               |    |
|___________________|____|

Side A, slim: (See *-mark below description.)

 ____________________
|     |  2.          |
|  1. |  3.          |
|_____|______________|
| 5.           |(4.) |
| ...          | ... |
|______________|_____|

Side B, alt. 1: (Preferred)

 ________________________
|  1.  |  6.        | 5. |
| 2. 3.|            |    |
|__4.__|____________|____|
|                        |
| 7.                     |
| ...                    |
|________________________|

Side B, slim: (See *-mark below description.)

 ____________________
|  1.  |  6.         |
| 2. 3.|             |
|__4.__|_(5.)________|
|                    |
| 7.                 |
| ...                |
|____________________|

Description: _(Sorry for all NOTE(s) and cross-referensing.)
Side A:
--> 1. The CHARACTER, with choice(?): With or without STROKE NUMBERING.
--> 2. KUN reading(s), with choice: Include OKURIGANA or not. (See NOTE(s): 7)
--> 3. ON reading(s). (See NOTE(s): 7)
--> 4.* IRREGULAR* reading(s) (e.g.: 一日・ついたち、…), with choice(s): Include IRREGULAR or not. Select from wordgroup or AUTOMATIC-selection. Limit to X word(s). (See NOTE(s): 1, 2, 3, 4 & 8)
--> 5. Example WORD(s) (e.g.: 漢字・かんじ、…), see "Side B --> 7.", with choice: Select from wordgroup or AUTOMATIC-selection. Limit to X word(s). (See NOTE(s): 1, 2, 4 & 5)
--> 6.* Dictionary RADICAL category (e.g. for 意, 音 goes here and maybe the traditional number above or below: 1-214), with choice: Which to include - 常用, JLPT, Radical Number and/or Radical.
Side B:
--> 1. Numeric hint* for NUMBER of ON reading(s), with choice: NUMBER as Arabic/Latin or Kanji
--> 2. Numeric hint* for NUMBER of KUN reading(s) (without counting OKURIGANA), with choice: NUMBER as Arabic/Latin or Kanji (See NOTE(s): 7)
--> 3. Numeric hint* for NUMBER of KUN reading(s) in total (with OKURIGANA), with choice: NUMBER as Arabic/Latin or Kanji (See NOTE(s): 7)
--> 4. Numeric hint* for NUMBER of IRREGULAR reading(s), listed as: FrequentCount/TotalCount (Based on dictionary content at the time.) (See NOTE(s): 8)
--> 5.* Numeric hint* for NUMBER of STROKE(s) at the back-side of the CHARACTER, with choice: NUMBER as Arabic/Latin or Kanji
--> 6. The CHARACTER meaning(s).
--> 7. Example WORD(s) meaning(s), see "Side A --> 5.", with choice: Select meanings or AUTOMATIC-selection. Depending on X @ Side A, 5. (See NOTE(s): 6)
* Should be possible exclude all-togather, if so desired to achive "slimmer" cards. "Side A, 4." and "Side B, 5." could possibly, but not neccessarily, still be included if moved. (See "slim"-versions)

NOTE, 1: May be user-restricted to a certain rage or maximum 常用-grade and/or JLPT-level.
NOTE, 2: Automatically picks word from each possible reading based on commonness, priority to JLPT-marked words within limit X. (Ref. NOTE(s): 1 & 4)
NOTE, 3: Irregular are for reading samples, not glossary.
NOTE, 4: Limited to X word(s), sorted with priority to JLPT-level irregular(s) then commonness. Factor X determines card HEIGHT.
NOTE, 5: Prioritize selection of mixed reading(s), especially in AUTOMATIC-mode. So no card ends up with words from a single reading, unless ofcourse - there's only ONE reading like 意, but then at least TRY to include at least one irregular. (In such case(s), ref. NOTE(s): 1 & 2)
NOTE, 6: Only including what fits a single line.
NOTE, 7: Filter unique reading(s).
--> Example, 1: 決《ケツ、き.まる、き.める、ぎ.め、さ.く》 (count: 1 ON, 3 KUN & 4 KUN TOTAL), when printing without OKU would be 《ケツ、き、ぎ、さ》 - but as さ has no entries in the dictionary data it chould either be filtered OR marked somehow.
--> Example, 2: 画《ガ、カク、エ、カイ、えが.く、かぎ.る、かく.する、はか.る、はかりごと》 (count: 4 ON, 5 KUN, 5 KUN TOTAL) has かく and カク, could be limited to one of these when OKURIGANA is excluded - and 《はか.る、はかりごと》 has no words in the dictionary data, therefore could be filtered OR marked somehow.
NOTE, 8: Translations the IRREGULAR-column was deemed reasonable to drop due to lack of space (if neccessary one can look them up in the dictionary), however - the IRREGULAR word(s) and their reading(s) was deemed good for example and serve well as a reminder that there are IRREGULAR(s) for this specific KANJI. The counter also serves a purpose, informing the user of how common IRREGULAR reading(s) for the specific KANJI is.

Attaching sample PNG's with data, in the format marked as "Preferred" - which was the final vote among those I discussed it with.
The RED text should be OPTIONAL - not present in above ASCII-art nor description - and if possible, also make the numbers in translations OPTIONAL? There was also the oppinion to have a separate option to exclude/include the pointers "cnt", "pref" & "suf" as these can be plenty useful.

Zkanji V 0.0.0.3 portable
win7x64

Menu > File > Settings > Appearance > Interface scaling > Restart
Menu > File > Settings > Appearance > Interface scaling > Restart
Menu > File > Settings > Appearance ....

the setting is back to default after restart

The default colors (mostly for different texts) were selected with a light theme in mind, but they don't look nice when the theme is dark. I have committed code that will allow a separate default color palette on a dark theme.

The defaults can be found in colorsettings.h in the ColorSettings structure. Defaults for the light theme are stored in const variables with names ending in ldef. The defaults for the dark theme end in ddef. I will get to this in time, but if anyone is willing, you can help finding a nice looking theme. The colors are in almost the same order as they can be found in the settings dialog window. Defaults for the base text colors and backgrounds are not stored in the code, since I get them entirely from the system via QApplication::palette().

Importing the dictionaries works OK except that 13 words from the JLPTN data file were not found in the imported dictionary and it asks me how to match them. But then, when importing examples, it just hangs after a very short while, no error window, no crash it, the window is still responsible and text can still be selected but the progress bar won't move.

Adding some debug output I could find out that it hangs on:

line 979 B: 真昼~ の 太陽 が テニスコート(#1080030) を 目(め) も 眩む~ 程{ほど} に 照らす{照らし} 上げる{あげた}

To be more exact it hangs after TextSearchTreeBase::findContainer throws an exception because the given length is 0 maybe because it couldn't find any romaji? In particular this parent call hangs: findKanjiKanaWord( "テニスコート" , "#1080030" , (nullptr) , 6 , 8 , -1 ).
I didn't look further what happens to this thrown exception and why no error dialog pops up. In the first place, it shouldn't throw. There must be some other underlying problem with the examples file. I think it happens because the #1080030 reference isn't ignored. In another run it hang on line 324 B: 此処{ここ} の ソース(#1075270)[01] は 舐める[02]{舐めて}~ 見る{みる} と 一寸(ちょっと){ちょっと} 塩っぱい, which is the first line containing such a hashtag number, so it might be that. I guess it it's sometimes this line and at others because it is multi-threaded?

I don't really know what I'm doing here but removing the hashtag number with sed makes it importable in ZKanji:

sed -i -r 's|\(#[0-9]+\)||g' examples.utf

P.S.: IMHO, you should avoid != expressions in for loops and instead almost always opt for > or <. Those != expressions are all just infinite loop bugs waiting to happen. Also, your code base is littered with trailing whitespaces, which my editor automatically removes and therefore leads to large diffs in git. I don't know if you'd accept merge requests but a kind of simple style check or uncrustify might be helpful for other contributors.

Initiated here after being mentioned: HERE
Regarding "study"-mode, invisible/non-existant input for answer - and proposals for potential changes to be concidered.

Just throwing my train of thought out here, some ideas comments may be pointless - others may require a redesign to incorprate properly. Concider time-effort-result delta. Raw draft and swift patchwork for some ideas and due to lack of time, didn't double check if any proposal is existant in current version - nor thouroghly checked on anything yet - ...and noted some screenshots got spoiled by WM-effects. Please bear with it.

NOTE: Through-out this screenshot-run I didn't enter a single answer at all. If some event was to occour upon this or at "wrong answer", then as you will see - none occoured.

For ease of reprodocution:
Starting the test for single kanji (亜), single reading and it's meaning - then screenshots commence right after the "Study now" and selecting "3" at the range.

Comments on screenshots in sequence order:

(Screenshots attached in archives below.)
--> 01 First box, Query @ ...16-45-00: Assuming there should be an input for answer in-between "Enter the answer:"-label and "Show hint..."-button? However, as for "Kanji"-answers - would it be reasonable to use a free-draw box for answer - which gets "disabled"/"non-editable" after hitting "Show answer"-button? Even if not connected to a look-up function, it may be good for practice and to ease up for users to compare their answer with the correct one? Mark "Status" (in this case "New", in colour scale matching various status?)
--> 01 First box, Answer @ ...16-45-18: The size of the kanji here, would it be reasonable to match the size with the Kanji Search Widget? Placing the previously mentioned free-draw box disabled at roughly same scale by its side? Plausably with stroke diagrams, or connected to the Kanji Information Dialog for review (automaticly pausing timer)? Mark "Status" (in this case "New", in colour scale matching various status?)
--> 02 Second box, Query? @ ...16-45-57: Here's an input box... and "Reveal"-botton. Everything is listed about it... what are these for? If to enter the reading, at least hide the "Kana"-column?
--> 02 Second box, Answer @ ...16-46-07: Force "Incorrect" red? Or define a "Wrong/Correct answer"-colours at Settings -> Colour?
--> 03 Third box, Query @ ...16-46-42: If this was a "large"-scale test, a single reading in kana is deffinitely insufficient - would suggest to prefer kanji over kana when available as it would be more real-life-like.
--> 03 Third box, Answer @ ...16-46-50: See first question comment on "First box, Answer".
--> 04 Fourth box, Query @ ...16-47-02: Yet again, no input available. Use a free-draw box like above suggested for Kanji for user to compare side-by-side with answer? Concidering using input-methods - such as i.e. iBus-Anthy or the built-in romaji-to-kana - being a form of cheat.
--> 04 Fourth box, Answer @ ...16-47-13: See all comments at "First box, Answer". Just "Kana" instead of "Kanji".

Screenshots, raw:
Screenshot_2018-01-09_Raw.zip

Screenshots, with markdown:
Screenshot_2018-01-09_MarkDown.zip

Proposal draft:
Proposal_2018-01-09_Draft.zip

Disclaimer: Please excuse the sloppy patchwork made in a haste. They are named per referense to above comments.

Feature Request #1
I believe the handwriting tool is one of the most beautiful features in Zkanji.
Now, when you select "practice by writing" and open the "Long-term studying list..." and click on "study now", the handwriting tool is always closed by default.

My suggestions would be:

1. either having an option to have the handwriting tool always opened for Kanji study
2. or alternatively / on top of that, remember the last status of the handwriting tool. If it was opened for the last kanji, than it should be automatically opened also for the current one.

The second solution would probably be the most natural.

Feature Request #2
On top of that:
3) the handwriting tool closes itself as soon as you change application. I find it slightly inconvenient as that it is not what you would want most of the time. This would be especially true in the dictionary, when you are looking for a word, and maybe handwriting a kanji that is inside an image / PDF in another application. See down.

Feature Request #3
4) The handwriting tool in the Dictionary search is available only when "Translating from Japanese to English", but not when "Browsing the dictionary": I think that such an option if added would be convenient.

Thank you again for the wonderful programming!
Warmest Regards, Jhack

When taking at look at Kanji search -> Filters, no. 3 is missing and there are TWO of no. 5 - thus making keys 3 and 5 disfunctional when using shortcuts to show/hide filters at the "Kanji Search"-widget.

As a result, key no. 4 leads to "Meaning" (which is no. 3 if clicking filter-buttons).

"Reading" as well as "Jyouyou" cannot be triggerd by shortcut at all.

Of-course, there are currently buttons for this, hence no high priority - rather later on for user convinience:

Would you mind concider the ability to MENU_CLICK on a group to get a CONTEXT_MENU offering to DELETE_SELECTED (should include a pop-up warning if SELECTED has child) and on EMPTY_SPACE offering to ADD GROUP or GROUP_CONTAINER.

Currently the FLOAT is popping up instead.

Thank you for the wonderful work creating Zkanji.
I was a huge fan of Zkanji since the very start, and it helped me greatly in becoming the Japanese interpreter that I am now.

I'd like to signal a bug with the "kanji boxes" in the handwriting tool and kanji search in the v0.1.0 beta. See the pictures attached to understand the problem. Basically the kanji are too big to fit in their boxes and are hard to read.

I apology in advance if the problem was already solved in the commits after the build.
Warmest Regards, Jhack

A strange bug in the study statistics of the long-term study list causes negative numbers to come up for the "learned" (and possibly other) area when removing(?) learned items. It hopefully only affects the statistics.

Hello! I don't know if you're still working on this amazing project or that it was the end a few years ago, but if you still need feedback or issue report, I'll list them here.

Compared to the older version of zkanji, the Kanji Grids are all clamped together and oversized. The minimum size in the setting wa 32 and even so, it was still to big. I would've perered it if the kanjis fit in the grids so that it's alot appealing to the eyes as well as easy to read.

Another issue I have is with the Dictionary. It's kind of annoying that I have to scroll to the right to look at the whole text and then scroll all the way back to the left when I minimize the software.

And then here, the examples are great, but the translations on the bottom and the area itself is to small to be readable.

I also like how the quizzes are, but I liked it more if there was more then just type in the answers and flashcards quizzes/study methods. Like maybe incooperate some multiple choices in there?

Request:
This is probably planned since it was in the old release, but I mention it just for safety:
after a new word search, the horizontal scroll bar should go back to the extreme left on it's own :)

First see #10 as reference.

The data is going through final check, lots of changes has been done since the 0.0.1-alpha-version. And, in-difference from the sample of the updated file I send, the column RADICAL_REFERENCE has been split into 4 columns as it got a bit complicated otherwise. Depending on what is decided on, those 4 may be subject for being moved to a supplementary file later.
Two supplimentary files are in-progress as well, NOTES and HINTS.

SVG-files are on-going too... only made a few as of yet. Anyhow, these will be named by the FIRST UNICODE they belong to, e.g. need to internally handle reference from SECONDARY UNICODE(s) as I cannot use symlinks due to cross-platform compability issues.

Started to sketch on the scope of the Radical Browser as well.

First, thanks for your work! I used ZKanji a long time on Windows and even a while using wine under Linux but after the last Linux reinstall and because I'm now also a Qt developer, I wanted to give building this Qt version from source a try. I especially like and frequently use the freehand drawing kanji lookup and that it comes with a built-in Japanese IME for the dictionary lookup.

I followed the build instruction like this:

git clone https://github.com/z1dev/zkanji.git
cd zkanji
mkdir build
cd build
qmake ../zkanji.pro
make

mkdir importfolder
cd importfolder
wget http://ftp.monash.edu/pub/nihongo/JMdict.gz
wget http://www.edrdg.org/kanjidic/kanjidic.gz
wget http://www.edrdg.org/kanjidic/kanjd212.gz
wget ftp://ftp.monash.edu/pub/nihongo/radkfile.gz
wget ftp://ftp.monash.edu/pub/nihongo/examples.utf.gz
for file in *gz; do
    gzip -d -k "$file"
done
cp ../dataimports/* .

# mkdir data # I forgot this and triggered the misleading error message
./zkanji -ie importfolder

No matter whether I choose portable or normal mode in the popup and no matter what permissions I set for the folder where zkanji resides in, I would always get this message:

File permissions do not allow creating and writing data files in the program's data folder.

Looking at the source code I found out that it checks whether the data folder is writable. But it never tries to check for its existence in the first place nor does it try to create it if it does not exist. Maybe I overlooked some of the instructions, but I think it would be easy to check and try to create the folder as fallback and do the permission check on the parent folder.

Allow user to select a RESTORE_FROM_TRAY shortcut.
Partially for the lazy, but also for the multi-monitor user who has the screen with tray switched off.

Also, in order to ensure shortcuts doesn't interfere with other DE/WM shortcuts - user should be able to set a "free" key combination - like those already existing for pop-up dictionaries.

EDIT: ignore this first message, I first thought this was a bug but then understood it is not, so I've changed the title of the topic to a Feature Request - detailed on the second reply to this topic :)

This seems very odd - if I search for う (90k entries) on "Browse Dictionary" it will bring up the results in a matter of milliseconds, if I do the same on "Translate From Japanese" the program will hang for about 1 second, which doesn't seems much but is very noticeable.
Giving that (I would assume) they are both doing the same thing and bringing up the same amount of results, there must be something wrong with the "Translate From Japanese" search.
I made a video in which I type and delete う in both as fast as I can, to better show the difference in responsiveness between the two:

A very basic script which helps those who are unfamiliar with Linux, or just lazy, to install and run zkanji, I'll attach it.
Install_zKanji.txt
UPDATE @: HERE

It's been tested in up-to-date ArchLinux, as of 2017-12-07. (Too lazy listing all versions.)
...and NO! The script is NOT fool-proof in terms of handling user input errors etc, however - when used as intended, did build successfully on two machines for v 0.0.3-alpha. The current GIT cannot be built due to missing object "charts". (Error occours using QT-Creator as well.)

I also included a 'Dark Theme' icons option in the script, as I noted during first install how some icons where impossible see when using a dark system theme. Also noted, in colour settings, the name of colours cannot be controlled by system theme - hence cannot be read.
I made a variation of icons included in the source, which parhaps you could add to your base as optional icons - or just alter colours of to suit the project.
Resources-for-DarkTheme.zip

This is a continuation of things mentioned in other posts previously, see issues: #13 & #14

The other issues seem to be mainly a problem because there is no real standard on Linux, how the WM should handle some situations. [...]

As I generally do CLI, it's not my field of expertise. But there IS A STANDARD, see EWMH-link below. Compiz and others should follow the standard - Compiz 0.8 was declared "completed" about 10 years ago and is in maintenance mode for kernel/X-updates and such.
Anyhow, for what I know of the inner works, X-server is supposed to pass signals to the WM and applications seldom send the signals straight to the WM. There is a tool-set called "xdotool" which can be a great source for learning about passing signals to the WM's through X the "Linux way". I believe Wayland-server use same approach for WM's, handling the task of passing signals - but I hardly used Wayland personally as it doesn't offer as good driver-support for hardware yet.
Project site: http://www.semicomplete.com/projects/xdotool
Source: http://github.com/jordansissel/xdotool
EWMH specification: http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html

@ Multi-monitor setups:
When you save positions, close application/windows - then disconnect/disable a monitor so it's no longer part of the full resolution - when you re-open the application (or window) with saved position it's out-of-bounds. Some form of cross-check resolution <--> position would be required to mend this. Esp. affected are laptop users who got a dock at home or office - but also flip-screen users as applications which save positions can be out-of-bounds as soon as the flip is performed (as flip causes changes in resolution, e.g. 1920x1200 <--> 1200x1920).
Users who got multiple flippable monitors, or multiple monitors which are statically fixed in a mix of some horizontal and some vertical, can suffer from some parts of the full resolution being out-of-bounds.

Example: 1 vertical monitor (1920x1200) & 1 horizontal monitor (1200x1920) gives a total resolution of 3120x1920 where 720x1200 cannot be accessed. Those 720x1200 can be distributed across 1 or 2 rectangles of ?x1200 depending on alignment.
Example above, if flippable, allow for any of following total resolutions: 3840x1200, 3120x1920, 2400x1920, 1920x2400, 1920x3120, 1200x3840
Also refer to the ASCII-example below.

Dual-/Tripple-monitor are the most common. Quad or more is rare as only more expensive, and CAD, GPU's support it - and in-expensive cards which are only for simple use like information displays like at some stores.

There can be further dis-alignment, causing additional rectangles which are out-of-bounds - but usually display-settings (regardless of OS) will attempt to minimize this in order for the cursor and applications to flow without unnecessary gaps. Ofcourse monitors can be overlapping, mirrored or used as duplicates... but those will still stay within bounds of above mentioned in this section.
Personally I've used multi-monitor setup since late 90's... it has so many benefits I've grown to despise single-monitor setups. Remember I had Windows 98SE and an ATI Rage dual-head card with amazing 2MB dedicated VRAM. Gosh, these days it's an enthusiast card I guess?

To be honest, most offices I've seen in this country has multi-monitor setups for their employees due to the benefits. While rare for Mac/OSX (though mainly design offices uses Mac, thus I don't have much contact with those and may be mistaken), Windows and Linux workstations and laptop/dock-setups are very common with multi-monitor. Flip-capabilities is more or less standard on smaller laptops and full-system tablet/laptop-fusions. (Those which usually come pre-installed with either Ubuntu/GNOME3 or Windows 10. Andriod/iOS/Chromium/etc. are to be counted as limited systems.)

zKanji's primary target group is probably NOT at office, but well - some people use same laptop in private life as well or got their office at home and so on, hence mentioned.

If you use a VM like Oracle's VirtualBox, you can test out fake multi-monitor - although, depending on virtual OS you may have to shutdown the VM to change available "monitors" and KDE/Plasma require restart of SDDM to fully recognize all changes in monitor setup for some stupid reason (other DE's does not have this requirement). It's a matter of available RAM and VRAM too if you can do this or not. Maybe some some hardware may not support it, I believe..?

You probably guessed or already know - but here's an ASCII representation of gaps for illustrative purpose, based on two 90-degree flippable monitors where resolution X != Y:

              X
 ____________________________
|     W1xH1     |  |    V    |
| ------------- |  |    E    |
|               |W2|    R    |
|               |x |    T    |
|   HORIZONTAL  |Y |    I    |  Y
|               |  |    C    |
| ------------- |  |    A    |
|____ W1xH2_____|__|____L____|

X = The total combined X resolution.
Y = The total combined Y resolution.
W1 = Horizontal Screen X
H1 & H2 can have values down to 0, but sum of H1+H2 comply to:
H1+H2 = Vertical Screen Y - Horizontal Screen Y
W2 = Fake EMPTY space in-between monitors, this can have values down to 0 and up to the GPU's maximum allowed total resolution minus X.

Above ASCII only represents dual monitors located as LEFT & RIGHT while user may have TOP & BOTTOM or other settings with even more monitors. If all monitors are at same individual resolution and aligned in a row, there won't be no invisible space(s) like W1xH1.
But regardless, the X and Y will still - even for a single monitor setup - represent the COMBINED RESOLUTION which should be available for disposal thus a basic guideline should be to enforce keeping application within these bounds.
Would surprise me a lot if there's no available feature for requesting system resolution information.

Area W1xH1, W1xH2 and W2xY can be a pain identifying, so I say - don't bother. Let the WM handle those and if the WM can't then too bad, replace a WM which can or live with it. As for the W2xY, usually the DISPLAY MANAGER will try to keep such gaps non-existent - but they can occur on user request.

What's important is, at application START - and possibly RESTORE - make an addition like: (illustrative)

FUNCTION OUT_OF_BOUNDS(*) {
    IF (WINDOW_POSITION_X > X || WINDOW_POSITION_Y > Y) {
        WINDOW_POSITION_X=NONE ;
        WINDOW_POSITION_Y=NONE ;
    }
}
WINDOW_POSITION = EVAL OUT_OF_BOUNDS(WINDOW_POSITION) ;
SET WINDOW_POSITION ;

...in order to relocate window or set NONExNONE as WINDOW_POSITION. Most applications do something like this on STARTUP, some on RESTORE too.

I believe Compiz 0.8 is the one and only WM - counting Windows and other systems too - which actually is designed to help users counter these issues, but it can only handle like... TRUE STANDARD TYPE(s) of windows, e.g. not dialogs such as "Kanji Information Dialog"-widget etc. INVISIBLE space can actually be visually accessed too if desired, but space which is OUT_OF_BOUNDS cannot. (Using the custom script feature it's probably possible to extend to, theoretically, cover anything - but requires deeper user knowledge.)

To get ACTIVE_MONITOR, I believe you need to request POINTER_POSITION - or request ACTIVE_OUTPUT from WM. Normally, I believe, WM will handle this better per default if you do NOT send WINDOW_POSITION information. For sub-windows sending RELATIVE_POSITION.

Build (UTC): 2018-01-13 @ 12:12

Filter bug 1: Filter #3 (Meaning)

Reproduction steps:
--> Hide all filters.
--> Show #3 (Meaning).
--> Fill in something.
--> No filtering is performed until both of filter #1 & #2 are visible as well.
NOTE: This seems to be affecting, at least, filter #3 (Meaning) and #4 (Reading), but - due to insufficient testing performed, this MAY affect any bug.

Filter bug 2: Filter #4 (Reading)

Reproduction steps:
--> Hide all filters.
--> Show #4 (Reading).
--> Fill in a single Kana character.
--> No filtering is performed due to bug mentioned above.
--> Show filters #1, #2 & #3. (This due to bug mentioned above.)
--> Filter #4 will now affect the search and show any Kanji which has a reading which starts with Kana.
----> Example: か --> will show か*, e.g.: 下（カ）、上（かみ）、川（かわ）、日（カ）...

More thorough testing is required! More filters may be affected and I haven't personally tested filters #5~#8 yet.

Proposal:
Make a loop for filters which goes along the lines of:

for f in FILTERS
    if f is VISIBLE do
        apply FILTER f
        NEXT
    else do
        treat f as DISABLED    # DISABLED:  E.g. VALUE=NULL
        NEXT
done

This will ensure only visible filters is taken into account, even without resetting them.

Hidden filters should be treated as DISABLED as the user may forget to take them into account when browsing the result. (E.g. forgotten to press "Reset" or simply wants to keep the filter set to go back to previous search etc.)

This is a feature from the old zkanji: lets say there is a word like 小言 (just came up in a game) for which I know the kanjis but not the word itself, the way I would go about looking it up was this:
assuming I couldn't guess the reading, I would write a word containing the fist kanji, like 小説, right click the first kanji, copy it, then look up 言う and append the kanji.
My clipboard would contain 小言, so I would paste it into the search.

With the newer zkanji, I look up 小説, I right click on 小 and choose "Copy Kanji", rather than copying only 小 it copy both kanjis, then I do the same step for 言う by choosing "Append Kanji", and the う get left out since it is not a kanji, but if I had used a word like 言語, then the second kanji would have been picked as well.
So now my clipboard contains 小説言, so I paste it and then need to delete 説 - so this makes the lookup of unknown words more clunky compared to the old zkanji

Would be possible to modify the "Copy Kanji" and "Append Kanji" functions so that they correctly do what they say, by copying and appending a single kanji rather than copy/append all the kanjis in the word? ^_^'

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.

A brief overview - INDEX:

--> Issue/Bug #1 - Crash when opening Kanji-info boxes.
--> Issue/Bug #2 - Crash when hitting "cancel" upon browsing for importing user data.
--> Issue/Bug #3 - Minimize to tray, no icon and impossible to restore.

-- Issue/Bug #1 --

When trying to open the Kanji dialog info box on build v. 0.0.2, v. 0.0.3 and GIT, zKanji will inevidibly crash.
The popup boxes on hover with info works fine though, it's the dialog one which stays on-top and contains the stroke diagrams which refuses to open.

This has been confirmed problematic on multiple Linux-systems:
--> ArchLinux, XFCE/GNOME2-based (Up to date as of 2017-12-28)
--> ArchLinux, KDE/Plasma5-based (Up to date as of 2017-12-28)
--> Kubuntu, KDE/Plasma5-based (16.04LTS up to date as of 2017-12-28)

Build was explicitly done:
--> ...without any custom patches/resources, and
--> ...performed on each system, no copying pre-built, and
--> ...build was successfully completed with QtCreator for first trail, and
--> ...build was successfully completed for second trail using:
qmake "zkanji.pro" -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug && make

Test(s) performed with all settings at default without imported data, dictionaries aside.

Double-checked all dictionary files being in correct format as specified in "Setting up the data files"-section. Both "kanjidic" or "kanjid212" yield crash, assuming the former being the preferred though. Also made an attempt with the fused UTF-8 containing "kanjidic", "kanjid212" & "kanjid213" with same result - dispite proper conversion to EUC-JP.

Is this related to the actual code in "smartvector.h" line 440-443 (see coredump), or the build options?

Coredump info on last core after crash, all say the same:

# Current GIT cloned @ 2017-12-28
$ gdb zkanji
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000558553b86e05 in smartvector<KanjiElement, std::allocator<KanjiElement*> >::operator[] (this=0x5585550aff08, n=18446744073709551615)
    at smartvector.h:442
442	        return const_cast<value_base_type*>(base::operator[](n));

# v0.0.3-alpha.tar.gz, submitted @ 2017-08-09
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00005596df98fb89 in smartvector<KanjiElement, std::allocator<KanjiElement*> >::operator[] (this=0x5596e1e61b08, n=18446744073709551615)
    at smartvector.h:442
442	        return base::operator[](n);

# v0.0.2-alpha.tar.gz, submitted @ 2017-07-30
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000562a9b3c811f in smartvector<KanjiElement, std::allocator<KanjiElement*> >::operator[] (this=0x562a9e289048, n=18446744073709551615)
    at smartvector.h:442
442	        return base::operator[](n);

-- Issue/Bug #2 --

On Linux and plausibly other systems as well:
--> When importing user data at initial run, if browsing then closing the browsing-window (or using cancel), zKanji will hang. No coredump produced. No error seen when running through terminal.

-- Issue/Bug #3 --

On Linux and plausibly other systems as well:
--> When using the "Minimize to tray" option, no icon is drawn at tray and it's impossible to restore window from the no-icon slot which appeared upon minimizing zKanji. Closing/restarting zKanji requires the use of terminal or GUI process handling tool - sending 15 works fine so it doesn't freeze or anything like that.

In individual kanji card window (which is a separate hover tab on which shown: the kanji picture, its on, kun reading, its meaning), when I click on one of the kun readings the app automatically shows me the list of words out there that match the kanji I'm examining and the kun-reading I clicked on in the lower part of the program, where the dictionary is, but when I perform the same but only with on-reading of a kanji the program doesn't list the words that have the selected on-reading, instead this action fills the "reading" namespace in the upper-left corner to show me the available kanji matching that reading I clicked on, but I would really like if by clicking on the on-reading the zkanji app would show me the words available which contain the specificied on-reading of the specified kanji, please tell me if there's something I'm missing that can do it. Thank you.

As you can see in the image below, the radical search is bugged, because if I select that many radicals I should get no resoults at all

Menu-clicking in dictionary-view(s) currently doesn't allow adding Kanji to Kanji-groups - only words to Word-groups. It would be practical if possible to allow this, preferably where user can check/uncheck which of the kanji is appended to the Kanji-group - similar to how things are added to Study-decks.

It could be nice to be offered to copy and/or add to Kanji-group from the "Kanji Information Dialog" as well.

I'm opening an issue for this just in case someone comes to check whether I know about it or not. I don't expect this to live long because I'm going to fix it right away.

Edit: This doesn't seem to be a problem on fresh install, so it was broken while playing around with the program settings or settings file, which is worrying. The corruption might have been caused by the program itself, in which case I'll have to find out why. If the settings file gets corrupted manually by a user, zkanji should be able to recognize it.

As known, no icon showing when minimizing to tray - but, upon clicking this no-icon no-description empty slot, it dissapears and is NOT restored. However, neither does it crash. It's still possible to bring it back up, but it's at the same time not present in an active-window list. It's sort-of restored to a "minimized-yet-semi-invisible"-mode instead of "restore window"-mode.
Also, if trying to launch zkanji while still minimized at tray, it refuses to launch - would it be possible to trigger "restore window"-action instead of refusing completely upon this event?

Solution proposal:
Currently none.

Hello,

All is almost explained in the subject issue.

How to reproduce
dictionary search mode -> search a kanji -> in the list view result, right-click -> "Add word to study deck"

I don't know what is the best option here :

• Create a default study deck when we select the option "Add word to study deck".
• Or a popup warning, asking to user to create a study deck.
• Or create a default study deck at startup if there's no one.
• Or display the study deck configuration window (perhaps the best here)

Logs
qtcreator_debugger.txt
backtrace.txt

note : zkanji v0.0.3-alpha (fedora 26)

Thanks

A brief overview - INDEX:

--> Future feature request #1 - Flags.
--> Future feature request #2 - Annotation descriptions.
--> Future feature request #3 - Font size.
--> Future feature request #4 - Examples, names & multi-lingual.
--> Future feature request #5 - Regex.

-- Future feature request #1 --

In terminal, and plausibly at Help-menu:
--> Flag/switch information, e.g.: --help or -h brings up what options there are and short info.

-- Future feature request #2 --

Annotation descriptions @ Help-menu or Dictionary-menu.
These can be extracted from JMdict:
--> Format: <!ENTITY term "Explanation">
--> Inbetween:

<!-- The following entity codes are used for common elements within the
...
<!-- JMdict created:  

-- Future feature request #3 --

Font size adjustable "by px" or a "Very Large", as so-called "Large" is fairly small - even using a 27" monitor @ 1920x1080. Indeed, there's interface scaling - great, but for those who only wish to increase size of dictionary entries a "Very Large" or freely adjustable "by px" would be perfect.

-- Future feature request #4 --

Browsable & searchable examples dictionary.
Browsable & searchable names dictionary. (Possible to import along with the others? Using like: zkanji -ien PATH)
Build multi-dictionaries (one for each language in JMdict) at initial import (zkanji -ie PATH)

-- Future feature request #5 --

Simple regex (or import existing regex library/module parhaps?) @ search, e.g.:
--> "*" (none-or-more-characters),
--> "." (single-character),
--> "|" (this-or-that, plausibly brackets enclosure, "[" and "]", for multichar-this-or-that)
--> "&" (this-and-that, plausibly brackets enclosure, "[" and "]", for multichar-this-and-that)

Example:
--> ご*そうさま,
--> ご.そうさま,
--> ごち|くそうさま,
--> ご[ちそう|くそう]さま
...would all find 御馳走様「ごちそうさま」, and anything else matching the given pattern.

Notes:
--> "|" and "&" for latin letters could plausibly be used inbetween SPACE(s) instead of brackets.
--> "&" is primarily useful in latin-style lookup and examples.