01 October, 2007
scim-python 0.1.2 released
scim-python is a python wrapper of scim. Now you can write input method in Python!
10 September, 2007
An interface design issue of scim
SCIM's panel module is responsive for all GUI-related works. During user typing, it will show a lookup-table window to allow user choose what he/she want according to his/her input.
To support multiple IMEngine, SCIM defines a pair of signal/slot, whose name is update_lookup_table, to allow IMEngine sending the content of lookup table to panel. The prototype of this slot is:
void update_lookup_table(const LookupTable &);
Here LookupTable is an abstract class, IMEngine may use any class derived from it to store the content of lookup table. It's cool for all-in-one-process solution, which offers more flexibility.
But in most cases, SCIM runs in a multi-process mode, that is, IMEngines run in the scim daemon process, panel runs in a scim-panel process and IMModule runs in the client application's process. To exchange info, these processes communicate via standards socket connection. The problem is, the receiver in one process has no idea about the actual type of this LookupTable in another process. The current behavior of the receiver is using CommonLookupTable, which is derived from LookupTable, to store and manage the content it receives and offer this CommonLookupTable object as a LookupTable to other part of code.
Currently LookupTable has only one subclass, i.e. CommonLookupTable. It won't bring real benefit if declare the type of this argument as a abstract class. IMHO, it should be CommonLookupTable directly.
To support multiple IMEngine, SCIM defines a pair of signal/slot, whose name is update_lookup_table, to allow IMEngine sending the content of lookup table to panel. The prototype of this slot is:
void update_lookup_table(const LookupTable &);
Here LookupTable is an abstract class, IMEngine may use any class derived from it to store the content of lookup table. It's cool for all-in-one-process solution, which offers more flexibility.
But in most cases, SCIM runs in a multi-process mode, that is, IMEngines run in the scim daemon process, panel runs in a scim-panel process and IMModule runs in the client application's process. To exchange info, these processes communicate via standards socket connection. The problem is, the receiver in one process has no idea about the actual type of this LookupTable in another process. The current behavior of the receiver is using CommonLookupTable, which is derived from LookupTable, to store and manage the content it receives and offer this CommonLookupTable object as a LookupTable to other part of code.
Currently LookupTable has only one subclass, i.e. CommonLookupTable. It won't bring real benefit if declare the type of this argument as a abstract class. IMHO, it should be CommonLookupTable directly.
28 August, 2007
SCIM on Nokia 770
I got a Nokia 770 Internet Tablet. With Maemo, a linux based operating system, it officially supports several European languages. Fortunately, there is Maemo CJK Project, which brings East Asian language support to Nokia 770 / Nokia 800. Since the OS is Linux and GTK+ based, lots of input method on Linux can be ported to it. At this time, SCIM is the only choice for Chinese language pack. Thank you, wolfg.
PS: wolfg also ports StarDict to Nokia 800.
PS: wolfg also ports StarDict to Nokia 800.
25 May, 2007
SCIMPort development resumed
Have not check in anything to repository for a long time, which means the development of SCIMPort suspended. Of coz I have a lot excuses:
But excuses are excuses. I decide to continue debugging known bugs in SCIMPort from now on.
- Got a new job, spent lots of time and energy on getting acquainted with my work project and was tired when went back home;
- Moving to a new house, which was also an energy consumption process;
- It is not easy to switch context from .NET, C#, COM, ATL to Carbon, Cocoa and objc every day.
But excuses are excuses. I decide to continue debugging known bugs in SCIMPort from now on.
20 April, 2007
SCIMPort Startup
If I have seen further it is by standing on the shoulders of giants.
-- Sir Isaac Newton
Now we have an opportunity, standing on the shoulders of SU Zhe (I wish my weight won't hurt him), to develop an (or a bundle of) open source input method on Mac OS X, Microsoft Windows, or even embedded devices. That is the purpose of SCIMPort.
The followings are some questions and answers you might ask:
Why porting SCIM?
SCIM, an open source input method platform, can significantly reduce the effort to develop an input method. Besides originally developed input method, such as rawcode, scim-table, scim-pinyin, many input methods are ported on it, including fcitx, chewing, open-vanilla etc. If we port SCIM to other platforms, these input method will be very easily ported to these platforms too (even some of them already work on these OSes). That's the most efficient way to bring mature open source input methods to multiple OS.
Why OSX first?
First, SCIM is originally developed on GNU/Linux, running on POSIX system with XWindow and GTK+ (of coz there is a mutation: skim, which based on Qt). Since OSX supports POSIX well, it needs much less effort than porting to other platform.
Second, OSX users, especially users using simplified Chinese, have less choices on input methods than other platforms. SCIMPort will significantly alleviates this.
And Third, I have a MacBook.
Progress now?
From the point of end user, SCIMPort is just at beginning. If you compile and install it manually, you can only see a blank window with several meaningless buttons, plus several menus say "English Keyboard" or "RAWCODE". No matter opening SCIM or not, keystrokes always become characters input to system, as if SCIM does not exist.
Form perspective of developer, it does a lot.
At runtime, in most scenarios, SCIM is made of three connected parts: 1) daemon, manages multiple input method and other things; 2) panel, handles all GUI component and interact with user; 3) component, talks between OS and SCIM, translating messages. Let's analogize it to human being. To port SCIM, likes to do a surgery on people. First, doctor places and consolidates bones to the correct position (three main parts connected), then connects nerves (I'm rewriting message handler in component and panel) and finally sews skin (I'll try to write a neat, configurable GUI).
As you can see, we are at the middle of the whole process, but I will release SCIMPort as 0.0.1 at the end of second step, with an ugly and unconfigurable GUI.
This project is hosted on sourceforge, at http://sourceforge.net/projects/scimport/. If you want to help, contributing code and artwork, or even giving some suggestions, please feel free to contact me.
Thank you.
-- Sir Isaac Newton
Now we have an opportunity, standing on the shoulders of SU Zhe (I wish my weight won't hurt him), to develop an (or a bundle of) open source input method on Mac OS X, Microsoft Windows, or even embedded devices. That is the purpose of SCIMPort.
The followings are some questions and answers you might ask:
Why porting SCIM?
SCIM, an open source input method platform, can significantly reduce the effort to develop an input method. Besides originally developed input method, such as rawcode, scim-table, scim-pinyin, many input methods are ported on it, including fcitx, chewing, open-vanilla etc. If we port SCIM to other platforms, these input method will be very easily ported to these platforms too (even some of them already work on these OSes). That's the most efficient way to bring mature open source input methods to multiple OS.
Why OSX first?
First, SCIM is originally developed on GNU/Linux, running on POSIX system with XWindow and GTK+ (of coz there is a mutation: skim, which based on Qt). Since OSX supports POSIX well, it needs much less effort than porting to other platform.
Second, OSX users, especially users using simplified Chinese, have less choices on input methods than other platforms. SCIMPort will significantly alleviates this.
And Third, I have a MacBook.
Progress now?
From the point of end user, SCIMPort is just at beginning. If you compile and install it manually, you can only see a blank window with several meaningless buttons, plus several menus say "English Keyboard" or "RAWCODE". No matter opening SCIM or not, keystrokes always become characters input to system, as if SCIM does not exist.
Form perspective of developer, it does a lot.
At runtime, in most scenarios, SCIM is made of three connected parts: 1) daemon, manages multiple input method and other things; 2) panel, handles all GUI component and interact with user; 3) component, talks between OS and SCIM, translating messages. Let's analogize it to human being. To port SCIM, likes to do a surgery on people. First, doctor places and consolidates bones to the correct position (three main parts connected), then connects nerves (I'm rewriting message handler in component and panel) and finally sews skin (I'll try to write a neat, configurable GUI).
As you can see, we are at the middle of the whole process, but I will release SCIMPort as 0.0.1 at the end of second step, with an ugly and unconfigurable GUI.
This project is hosted on sourceforge, at http://sourceforge.net/projects/scimport/. If you want to help, contributing code and artwork, or even giving some suggestions, please feel free to contact me.
Thank you.
Subscribe to:
Posts (Atom)
