Mathieu Tozer's Dev Blog

Upon the services invocation to add to words
Determine the highlighted word
Determine the location of the highlighted word on the screen
Start a new bubbleWindow at the location
The bubble window will be a cute little animated thing with some
whispering sounds
Also start asking Words to define the highlighted word
Words searches the user's local dictionary first, then checks the
remote dictionaries second.
The word is added to the user's history.
And a summary of the definition is displayed in the bubble.
The user can click in the bubble to display the word in the expanded
view of Words (the main window).

It's been amazing the amount of fear that multi threading can instill
in the heart of a novice programmer! It's just such a break away from
the norm. But just now I've seen my first thread be spawned by my
application. Feels like I'm a Dragon Master in a Wyrn. Remember those
threads that rained fire from space?

Nasty bug, dance, dance dance!

I'm going to live with it for a bit longer. I've asked the community about it and am awaiting a reply.

Some other changes I've made in the process is to remove the +Smart List button from the main window, as I believe it will be something that the user will only do occasionally, and it is a task which takes longer to complete anyway and thus the added commitment to go to the menu is a small in comparison overhead to adding a smart group (the predicate editor will have to be set etc).

I've also recently decided on a new, secret direction for Words.

So I'm going to move on ignoring the fetching issue on the smart groups after they have been through the data store.

Hmm, the plot thickens! (I know I said I'd leave it aside) If I add a new smart list from the menu - it updates fine! Does it have something then to do with the way the predicate is being stored? It's not being stored so that it can be dynamic when it is fetched? Does it grow stale in the store? Might I work around this by saving it as a string instead and refreshing it when it's loaded?

One thing that's holding be back from developing and exporting dictionaries further is this feeling (assuredness) that the data model is going to change again, which will mean that I'll have to build all the dictionaries and languages again from scratch.

Perhaps the best bet is to simply build the languages and dictionaries to be custom to the testers who are using it.

Words now supports Jargon and Sweedish as languages, with basic dictionaries for those languages available when connected to the internet. These come via dict.org.

スエーデン語をサポートしました。日本語／スエーデン語に訳す辞書がありませんが、英語／スエーデン語はあります。どうぞお勉強を頑張り下さい。

Words 0.09

I want words to define words in a separate thread, so that it doesn't
take control of the application
But I have to carefully design how this is going to happen?
At the word level?
At the word list level?

I think atomically at the word level it would be best.

I'd imaging that it would work something like this.

Define Word(s)
Start a new (worker?) thread
Pass the words to it
For each word
Start a progress indicator
When the word has been returned
Stop the progress indicator for that word.

Might the network connection monitor actually be better in another
thread too?
But that's not what takes all the time...
The application at any time needs to have connected dictionaries.
Should each dictionary have its own thread?
Or should the one thread manage all connected dictionaries.. or
should a connected dictionary itself be passed to the thread?
Or should a connected dictionary start a new thread for each stream
of words it needs to define?

So, when you ask a dictionary to define:words, it connects (if it
can) and starts a new thread to define the words. And quits when it's
done.

This model might make it easier because I don't have to change much
of the existing code base. But is it good form for a model object to
start a thread? Seems like a controller thing to do really.
But we do want each word to be able to be defining itself atomically
and independently of everything else.
And it would be nice to say "hey, you, try and define yourself!"
which could be done around a loop for each word, and it will go away
and create a thread for itself and look up everything in the right
dictionary etc.

For each word being defined
Start a new thread
Pass the define:word method to it
Kill the thread once the defining is done.

This could have too much overhead with starting and stopping all
those threads.

I kind of need to decide for certain though how I want the system to
define things.
Obviously I want it to try to define stuff for itself, but there also
has to be some way to force it to define words through the user
interface as well.

But this is the way it WILL work, if each dictionary has it's own
thread. So it's dictionary thread centric. A new dictionary thread is
started and is fed a word object which it takes. It does the work of
defining the word, and then defines the word (if it can), and let's
us know when it's done.

So by this, the define method in the dictionary should create the
thread.

I wonder if I start a thread at the point in the code that takes a
lot of time and makes the program freeze, that it will just work. The
new threads will follow along, and return back to the main thread
when the work is done, and just proceed like normal...

An undefined words smart group.

Perhaps try to implement the speech bubble as a plain box first that
appears with a definition. But before that happens, I want more stuff
'up top' to be working sufficiently.

I REALLY don't know the answer to my core data issues... :-(

Now that I have set the architecture up for importing and exporting
languages and dictionaries, and then setting them into the project
bundle to be part of the next release of the software, I feel I must
return to the actual looking up of words, when that happens, and all
that.

Primarily, I want it to, as per the spec
a) Attempt to define words *as they are entered*, and display and
indicator to that effect.
b) Attempt to define undefined words.
c) Be able to wipe definitions clean.
d) Fix the network awareness.
e) Let the user know when nothing was found.
f) The definitions view, but that's another whole kettle of fish.
g) Implement the buttons which add the main definitions
h) When defining words, display a spiral progress indicator and let
the user keep working with Words.

yes yes Indicators Indicators INDICATORS! It's time to start telling
the user what's happening when Words takes control of the computer.

Another thing to think about is what I'm aiming for for first time
users.
1) Launch Words
2) See Some Example Languages Already Set Up (Maybe??)
OR show the add languages view
3)See the example words be defined automatically by the system.

I wouldn't mind having an even closer to user interface like a bubble
that appears above the highlighted word text.

It might be best for me to have a worker thread for defining words.

Now that I can safely import and export dictionaries, it is up to me to
a) Add support for as many dictionaries as possible.
b) Create more languages which are supported to match those
dictionaries.
c) Implement the add all supported dictionaries on startup procedure.

The problem is that sure, on first launch, import all the
dictionaries. But what about on updated versions of words? I guess if
a person is HANDED a dictionary, then they use the regular import
command.
We are only talking about importing the supported dictionaries here,
the internal ones. So it is sufficient to add them all, or more
precisely, add all the dictionaries to the store on launch that
aren't already in the store.

This will slow start up down efficiently, but let's see how it goes.
The dictionaries are fairly light, and it wouldn't be too hard to
optimise the checking with versioning.

It seems to work. Haven't fully tested it yet though
The question is now, of course, will it scale, and work well under
the pressure of the real world as opposed to the toy world situation.

I can now use the dictionary factory view to pump out dictionaries.
I still have more work to do to get it exporting those dictionaries,
and from there I still have to implement the 'available from launch'
dictionary method.

I am really excited about finishing this off because it is one of the
final fronteirs to getting words up and running the way I want it.
Until now it has been very touchy, and quite unusable to anyone but me.

But since I have started to implement the advanced dictionary and
language management, having kind of finished the word management
side, I feel more people will be ready to use it, because I can pass
them new dictionaries and languages, and then add them to the next
release of words.

There is still quite a bit of work to do, as I said. But it's nice to
see it coming together somewhat. I'll try to release Version 0.08 soon.

It is now possible to create languages in the 'language
factory' (including an icon) export them to file, import them from
file using the language factory. Words will also look for files
contained within the bundle and display a list of them to choose from
in the 'supported languages' list when you add a language, and the
language will be added when you click add.

The next thing is to do the same for dictionaries, and see if it all
matches up. Perhaps language objects can keep an array of dictionary
names that it will try to set as 'in use' if they are available.

On export
Put all the dictionaries that a language should try to set itself up
for when initialised into an array and archive it with the rest of
the language.

On import
Fetch dictionaries to that capability.
Take the array and search the available dictionary names and if there
is a match then connect it up!

Words will also need some initialiser text - the text that is
displayed first when you import a language.

But now I think I need to talk about dictionaries.
They need to be created, for whichever type they are, able to be
exported, and then fetched by the system when it loads, imported into
the user's database (not the whole file of index / definitions for
local dictionaries of course, just their Words management part).

Once I manage to get it into the managed object context, the existing
code should take care of the rest.

I'm going to remove the second context because it doesn't really make
all that much sense to have a second managed object conext. It would
be better to simply have an import exporter function and automate
this process on the first start up or something. Ie, just keep them
in the bundle as .wordslanguage files or something.

What is the goal of what I'm working on now???
To be able to have the user select from an internally supported list
of languages which have dictionary files already set up to use.
So be able to export and import dictionaries first.
Then implement a way to insert these dictionaries into the user's
dictionary sql file so that can start adding and learning words.

It is perhaps more intelligent to leave the dictionaries separate
from the languages when archived. This way languages too can be
passed about freely, without the weight of dictionaries attached to
them. Although it is not intended that languages be passed about as a
commodity like dictionaries will be.

Therefore when the user clicks export, a neat little bundle of
archived language data will be exported somewhere.

When a user adds a new language, the supported languages bundle will
be searched, the contents (or just their names) unarchived, and then
presented to the user. The user will then choose one of the supported
languages and then it will be copied into the user dictionary.
This way unneeded and unused languages won't be making the database
heavy.

So the next step is to enable languages to archive and unarchive
themselves.
This would include the words and that come default with that language...

The final release will be fine tuned, so leave that for later. Make a
simple import export method for what a language constitutes today.

Done! In a single train ride.

This stuff is too easy.