Kongzi Beta-8 announced for June

Okay. Kongzi Beta-7 has been in classroom-use testing for about 6 months now and it seems pretty solid. A lot of changes have gone on under the hood. It’s using a database for the main type of save files now and you can merge (import) data from other files without destroying your user info. This will be tuned as time goes by, but as of now it is solid for general use.


All the quizzes have gotten a swift kick up in power, they now don’t just present random items but will sometimes present items which are similar to the correct answer. To do this I have created an engine which analyzes the user’s expected knowledge level and searches for similar words .This works in any language and with sentences (shown below) as well as with words (shown above).

Another thing which I’ve done is add the list of test mistakes to the score screen for easy studying. The following example is from the dictionary I use to teach “Let’s Talk in English” to Chinese students.


Once I give the manual a once-over and double check a few features on my to-do list, I’m going to have to start looking at how to package this beast.

For one, I plan to blow away the competition by offering a companion textbook with preloaded vocabulary. The MCI Chinese project (see the navbar up top) isn’t dead at all and has actually expanded with sister projects such as MCI Japanese and so forth. Here are some shots of the MCI Japanese book, “Welcome to Japanese”:





As you can probably guess I’m really excited to have reached this point in the Kongzi project and I will be able to package and offer these materials to YOU (well, to anyone) very soon. Target is this summer, around June for a complete Chinese/Japanese/Korean package which will take you from step one to “fluency”.

Thank you for keeping patient all these years. The wait has been difficult for me, too! But it is almost ready now, for real!


Kongzi Beta-2

Kongzi Beta-2: Tag EditorKongzi Beta-2: Add Entries

Kongzi is growing – it is now 4,000 lines of code. Feast your eyes on the new Tag Tree System (shown above).

Additionally, I’ve improved the load/save functions – you can now export tag lists, and they are generally much smaller than exporting word lists – by several times. For example, one popular application seems to require 23 bytes for one dictionary entry in a word list, on average. Kongzi requires around 7 bytes for a tag and an entry, on average. Convenience is improved as well – you don’t need 30 different word lists to use Kongzi – you only need one dictionary file per language.

I’m amazed at how far the program has come. The user intrerface is still amateurish, but the program is bursting with a power I didn’t expect. For example take the innovative Shortcut System I’ve designed. It allows end users to create and share shortcut files (just like they can create and share tag tree files). What this really means is that users do not need an IME to type pinyin – they can just type ni3 and it will automatically resolve to nǐ. If you prefer Japanese, you can configure “no” to mean . It’s so configurable it’s scary – you can type ni3- and it will resolve to . Although, there is a catch – it depends on end users (or myself) to slowly enter all the shortcuts that users might want to use. Anyone with an IME doesn’t need the shortcuts system, but it saves a heck of a lot of time switching between Pinyin, Ascii, and Chinese all the time. The silver lining here is that once entered, the shortcut can be saved, and is integrated within the program. So slowly but surely all of the important tags (read; Pinyin and Hiragana/Katakana/whatever) will be created and distributed with the program.

The program is less than 200k in size; although if you don’t have a Chinese Unicode font you will need the version which includes the Bitstream font the program uses by default.

Over the next few days I plan to add innovative, cutting edge features like a mix and match quiz type, and a memory game with Chinese characters (again, or Japanese, Korean, whatever you have a font and an IME or shortcuts for).

I will also be experimenting with licencing numbers soon, so I can distribute the program. Keep an eye on this space, I’ll be giving away dozens (maybe a hundred or more) free copies to beta testers soon!

Dynamically modifying nodes in a JTree

First let me just say I hate JTrees. Now, let’s proceed.

When you first try to learn how to use a JTree, the examples you find will set up a tree, say with DefaultMutableTreeNodes, and then add them to the tree, which gets displayed. All neat and nice. Well thats crap, I say, because they don’t teach you anything, they just let you alone to figure things out. And when you try to use this level of understanding in the real world something strange happens. When you add the first child of a node like “node.add(childnode)”, it works, but when you add more children it doesn’t display properly. Whats maddening is that every diagnostic you could imagine will tell you that the nodes are there, it’s just that the JTree isn’t displaying them.

What you were never told, and SHOULD have been told, is that the JTree maintains a data model and a selection model separate from the actual data. This is because it allows you to remodel existing data structures into tree form without having to extend DefaultMutableTreeNode to create your tree node element. That allows you to display, as a tree, stuff that really isn’t a tree. Why you would want to do this is up to you. But for the rest of us, who just extend DefaultMutableTreeNode because it is the right thing to do at the time, we need to know this.

When I first ran into this error, I panicked and wondered what I did wrong. The first solution I found was a common one, but was actually quite useless to me (and, I suspect, many others) because of how I wanted to extend TreeNodes for my data structure, and why I wanted to do this. I’ll tell you that solution anyways. It’s to add the nodes like this:

DefaultTreeModel model = (DefaultTreeModel) jtree.getModel(); model.insertNodeInto( (DefaultMutableTreeNode) newnode, (DefaultMutableTreeNode) parentnode, parentnode.getChildCount());

Wow, huh? Who would have thought? And thats why I hate JTrees. And you know what, this is exactly the kind of crap Ruby people bring up when they say Java is bloated. But.. rather than being like everyone else and force you to adopt some twisted Java paradigm that doesn’t make sense, giving Ruby people more ammo, I will teach you a dirty little hack that works, and allows you to keep thinking the way you want to think about jtrees and data structures. So this is for both the 95% of us that will never need to display non-tree data as trees, and also for the 5% of us who are capable of beating ruby people at their own game.

Just call model.reload().

Yeah it’s that simple. All those jerks that tried to make you type
DefaultTreeModel model = (DefaultTreeModel) jtree.getModel(); model.insertNodeInto( (DefaultMutableTreeNode) newnode, (DefaultMutableTreeNode) parentnode, parentnode.getChildCount());

can be safely ignored. All you really need to do is


Okay, maybe yourtree.getModel().reload(), if you don’t keep a model lying around, but same basic thing. Simple, huh? What’s even better is that if you’re loading the information in from a save file or something, and you need to do a lot of .add() operations, you can get away with just .add()ing and it will likely take less processor time. Just model.reload() when you’re done and you’re good to go.

As mentioned this practically encourages you to store your tree data in extended DefaultMutableTreeNodes – since you will only need one copy of the data, ever, regardless of how many jtrees you want to use. Just call model.reload for each jtree. Hey, it’s better than calling insertNodeWhatever for every jtree each time you add a node, right? Of course it is.

Good luck out there 🙂