SCIM › scim-devel

The future of SCIM project

28 messages

1 2

Ryo Dairiki-2

The future of SCIM project

Reply Threaded

Hi everyone,

Today, I would like to discuss with you about the future of SCIM project.
Now development of SCIM has low activity, due to lack of developers.
We can fix only small bugs for now, but we have to restart the project
to solve fundamental problems of SCIM-1.x framework.

As you know, SCIM-1.x framework have some problem.
- It is written in C++, and causes ABI conflict with some commercial
products.
- There are too many frontends and backends, which makes SCIM complicated.
- The core library and immodules are not completely separated from GUI
libraries.
- There are no console support. (now under development)

I think we should now stop maintaining SCIM-1.x branch,
and choose one the the following:

1. Stop develop SCIM completely, move into IBus.
2. Create a new branch which have no backward compatibility with SCIM-1.x.

Talking about IBus, which is a very simple framework under development.
Joining to IBus project and making it stable enough for daily use is one
thought.
Or developing SCIM-2.0 is another thought.
(We need more developers for starting SCIM-2.0 branch.
Please volunteer to join the project if you choose SCIM-2.0.)

What do you think?
Please give me your idea.

Regards,
Ryo Dairiki <[hidden email]>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

Arne Goetje

The future of SCIM project

Reply Threaded

Ryo Dairiki wrote:
> 1. Stop develop SCIM completely, move into IBus.
> 2. Create a new branch which have no backward compatibility with SCIM-1.x.
>
> Talking about IBus, which is a very simple framework under development.
> Joining to IBus project and making it stable enough for daily use is one
> thought.
> Or developing SCIM-2.0 is another thought.
> (We need more developers for starting SCIM-2.0 branch.
> Please volunteer to join the project if you choose SCIM-2.0.)

I would highly appreciate a fundamental rework. I will be focussing on
IBus for the meantime and Ubuntu will probably use IBus instead of SCIM
in future, once the major issues have been solved. (Unless of course
SCIM-2.0 is faster and better implemented...)

However, I'd like to propose a fundamental change on how input methods
work: X has not been designed for any other languages than English. What
we have now to support additional languages is XKB and the XIM protocol,
both of them are more or less dirty hacks and have their problems. I'd
like to replace those stuff altogether with one general framework, where
X is not the major role anymore. The idea is to have a service running
where X (via X extensions), as well as framebuffer and other
environments can connect to. This service should take care of all
keyboard (and virtual keyboard through on-screen keyboards) activity to
have consistent behavior in all applications. That means, that if this
service is installed and running, X (and framebuffer, etc.) pipes all
keyboard activity to the service and gets the result (the string with
the codepoints) back. The service interacts with the user like the old
solutions did, through a front end, which needs to be written separately
for GTK, QT and other widget sets. IBus uses dbus to communicate between
those instances, which is a good idea IMHO.
I will try to push the development into this direction to get rid of
this XIM, GTK-IM and QT-IM crap.

The big advatage with this approach would be that any (Unicode aware)
application could use this, without the need for extra code to implement
IME stuff... the applications just receive strings, like they would with
pure ASCII systems.

Just my 2 NT$.

Cheers
Arne
--
Arne Götje (高盛華) <[hidden email]>
PGP/GnuPG key: 1024D/685D1E8C
Fingerprint: 2056 F6B7 DEA8 B478 311F 1C34 6E9F D06E 685D 1E8C
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

signature.asc (260 bytes) Download Attachment

Gerrit Sangel-2

Re: The future of SCIM project

Reply Threaded

Am Donnerstag 06 November 2008 schrieb Arne Goetje:

> However, I'd like to propose a fundamental change on how input methods
> work: X has not been designed for any other languages than English. What
> we have now to support additional languages is XKB and the XIM protocol,
> both of them are more or less dirty hacks and have their problems. I'd
> like to replace those stuff altogether with one general framework, where
> X is not the major role anymore. The idea is to have a service running
> where X (via X extensions), as well as framebuffer and other
> environments can connect to. This service should take care of all
> keyboard (and virtual keyboard through on-screen keyboards) activity to
> have consistent behavior in all applications. That means, that if this
> service is installed and running, X (and framebuffer, etc.) pipes all
> keyboard activity to the service and gets the result (the string with
> the codepoints) back. The service interacts with the user like the old
> solutions did, through a front end, which needs to be written separately
> for GTK, QT and other widget sets. IBus uses dbus to communicate between
> those instances, which is a good idea IMHO.
> I will try to push the development into this direction to get rid of
> this XIM, GTK-IM and QT-IM crap.
>
> The big advatage with this approach would be that any (Unicode aware)
> application could use this, without the need for extra code to implement
> IME stuff... the applications just receive strings, like they would with
> pure ASCII systems.
>
> Just my 2 NT$.
>
> Cheers
> Arne

From a users perspective, I would also strongly recommend this. If I compare
CJK input of Linux with Windows or Mac, it is really a difference like day
and night. I’m always wondering why I have to switch between two kind of
input methods, first the “normal” scripts like english, german, and then
complex scripts like Japanese, Chinese. To unify this all in _one_ selection
menu would be great.

Also, maybe I would recommend to first collect ideas about input systems and
then design the IME with all this in mind. If not, and somebody has a cool
idea, he maybe cannot implement it without all these dirty hacks.

E.g., I have the idea to create an input method for latin based languages in
order to conveniently type diacritics, even on a keyboard layout which
usually doesn’t support them. You would not need compose keys, deadkeys
(well, ok, that’s not a bad idea), or character tables anymore, but you can
just choose the character you want to (e.g. type “Kohler” and you can
choose “Köhler” or just leave it the way it is).
Also I have the idea to create an input method for German Fraktur script
(which I guess would be great in such a latin based IME), with which you can
conveniently choose between latin and Fraktur just with the keyboard. The
thing is, because these two scripts are unified in Unicode, you have to
differentiate them via the font. The input method could then maybe via dbus
tell the application in which you are typing to create markup depending on
the script you would like to type. This could also be used if you want to
type mixed Japanese or Chinese. A Chinese IME or Japanese IME would tell the
text editor to switch the font (which would need different markups depending
on the markup language, .g. in XeTeX, html, or Openoffice, etc.).

what I would like to say with this, is, that I think it would be really cool
to first collect ideas and (although not implement these right away) leave
the possibility open to support them, e.g. with font selections right out of
the IME.

Gerrit

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

Zhe Su

Re: The future of SCIM project

Reply Threaded

In reply to this post by Arne Goetje

iBus has a fundamental issue: It uses raw dbus protocol which is not suitable for transferring complex objects. Thus the feature of iBus is very limited and can't cover the requirement of all existing input methods (both free/opensource and commercial).

Actually I always want to resume the development of imbus project (http://code.google.com/p/imbus/), which was co-designed by many experienced input method developers, including Hideki Hiura (the author of XIM and IIIMF), Choe Hwanjin (Korean input method developer) and me (the author of SCIM).

From features perspective, imbus is far superior than iBus and SCIM. Because it has a fully object oriented architecture and supports transferring very complex objects over wire.

I'll try my best to find some time next year to continue this project. If you are interested in it, feel free to contact me.

On Thu, Nov 6, 2008 at 9:46 AM, Arne Goetje <[hidden email]> wrote:

Ryo Dairiki wrote:
> 1. Stop develop SCIM completely, move into IBus.
> 2. Create a new branch which have no backward compatibility with SCIM-1.x.
>
> Talking about IBus, which is a very simple framework under development.
> Joining to IBus project and making it stable enough for daily use is one
> thought.
> Or developing SCIM-2.0 is another thought.
> (We need more developers for starting SCIM-2.0 branch.
> Please volunteer to join the project if you choose SCIM-2.0.)

I would highly appreciate a fundamental rework. I will be focussing on
IBus for the meantime and Ubuntu will probably use IBus instead of SCIM
in future, once the major issues have been solved. (Unless of course
SCIM-2.0 is faster and better implemented...)

However, I'd like to propose a fundamental change on how input methods
work: X has not been designed for any other languages than English. What
we have now to support additional languages is XKB and the XIM protocol,
both of them are more or less dirty hacks and have their problems. I'd
like to replace those stuff altogether with one general framework, where
X is not the major role anymore. The idea is to have a service running
where X (via X extensions), as well as framebuffer and other
environments can connect to. This service should take care of all
keyboard (and virtual keyboard through on-screen keyboards) activity to
have consistent behavior in all applications. That means, that if this
service is installed and running, X (and framebuffer, etc.) pipes all
keyboard activity to the service and gets the result (the string with
the codepoints) back. The service interacts with the user like the old
solutions did, through a front end, which needs to be written separately
for GTK, QT and other widget sets. IBus uses dbus to communicate between
those instances, which is a good idea IMHO.
I will try to push the development into this direction to get rid of
this XIM, GTK-IM and QT-IM crap.

Your proposal looks great, however, in most case it's not applicable. The communication between input method and application is far beyond transferring string with codepoints. Both Windows and Mac provide complex API between application and input method. windows has TSF and IME(Input Method Editor API), Mac 10.5 has IMKit.

All of these API require application to communicate with input method directly. And all keyboard events will go first into application then dispatch to input method selectively through the API. input method may ask application for wide range of informations and actions through the API, for example to display the composing string inside application's window, or to return the context around input cursor, etc.

Actually GTK-IM and QT-IM do the almost same thing like TSF and IMKit. Unfortunately, we have multiple choices on Linux.

The big advatage with this approach would be that any (Unicode aware)
application could use this, without the need for extra code to implement
IME stuff... the applications just receive strings, like they would with
pure ASCII systems.

Just my 2 NT$.

Cheers
Arne
--
Arne Götje (高盛華) <[hidden email]>
PGP/GnuPG key: 1024D/685D1E8C
Fingerprint: 2056 F6B7 DEA8 B478 311F 1C34 6E9F D06E 685D 1E8C
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

David Oftedal

Re: The future of SCIM project

Reply Threaded

In reply to this post by Gerrit Sangel-2

Continuing in the same vein, from a user's perspective, it makes sense
to maintain a much greater degree of separation between the mechanism
used for switching between input methods and the input methods
themselves. All of the current major input method solutions on Linux
(SCIM, UIM, and IIIMF) have aimed to be universal frameworks containing
their own switching mechanisms, with the result that bridging software
such as scim-uim has been necessary to make input methods accessible
from one framework accessible to the others.

If Linux were to get a standard, universal protocol whereby all input
methods could communicate with all text widgets, such a separation
between the selection mechanism and the methods themselves would
finally become feasible.

As a bonus, it would also minimise the need for extensive configuration
before the methods would work, as they would be handled through a
mechanism that was already a part of the system, rather than a
non-standard add-on.

In short, the changeover to a standard interface would be a vast
improvement to the user experience. I'm a little skeptical about the
prospect of intercepting keystrokes, seeing as there are applications
that capture keystrokes for other purposes than inputting text, but if
that could be resolved somehow, it would certainly make Linux a lot
easier to use with non-Western languages.

David Oftedal

On Thu, 6 Nov 2008 12:23:10 +0100
Gerrit Sangel <[hidden email]> wrote:

> Am Donnerstag 06 November 2008 schrieb Arne Goetje:
>
> > However, I'd like to propose a fundamental change on how input
> > methods work: X has not been designed for any other languages than
> > English. What we have now to support additional languages is XKB
> > and the XIM protocol, both of them are more or less dirty hacks and
> > have their problems. I'd like to replace those stuff altogether
> > with one general framework, where X is not the major role anymore.
> > The idea is to have a service running where X (via X extensions),
> > as well as framebuffer and other environments can connect to. This
> > service should take care of all keyboard (and virtual keyboard
> > through on-screen keyboards) activity to have consistent behavior
> > in all applications. That means, that if this service is installed
> > and running, X (and framebuffer, etc.) pipes all keyboard activity
> > to the service and gets the result (the string with the codepoints)
> > back. The service interacts with the user like the old solutions
> > did, through a front end, which needs to be written separately for
> > GTK, QT and other widget sets. IBus uses dbus to communicate
> > between those instances, which is a good idea IMHO. I will try to
> > push the development into this direction to get rid of this XIM,
> > GTK-IM and QT-IM crap.
> >
> > The big advatage with this approach would be that any (Unicode
> > aware) application could use this, without the need for extra code
> > to implement IME stuff... the applications just receive strings,
> > like they would with pure ASCII systems.
> >
> > Just my 2 NT$.
> >
> > Cheers
> > Arne
>
> From a users perspective, I would also strongly recommend this. If I
> compare CJK input of Linux with Windows or Mac, it is really a
> difference like day and night. I’m always wondering why I have to
> switch between two kind of input methods, first the “normal” scripts
> like english, german, and then complex scripts like Japanese,
> Chinese. To unify this all in _one_ selection menu would be great.
>
> Also, maybe I would recommend to first collect ideas about input
> systems and then design the IME with all this in mind. If not, and
> somebody has a cool idea, he maybe cannot implement it without all
> these dirty hacks.
>
> E.g., I have the idea to create an input method for latin based
> languages in order to conveniently type diacritics, even on a
> keyboard layout which usually doesn’t support them. You would not
> need compose keys, deadkeys (well, ok, that’s not a bad idea), or
> character tables anymore, but you can just choose the character you
> want to (e.g. type “Kohler” and you can choose “Köhler” or just leave
> it the way it is). Also I have the idea to create an input method for
> German Fraktur script (which I guess would be great in such a latin
> based IME), with which you can conveniently choose between latin and
> Fraktur just with the keyboard. The thing is, because these two
> scripts are unified in Unicode, you have to differentiate them via
> the font. The input method could then maybe via dbus tell the
> application in which you are typing to create markup depending on the
> script you would like to type. This could also be used if you want to
> type mixed Japanese or Chinese. A Chinese IME or Japanese IME would
> tell the text editor to switch the font (which would need different
> markups depending on the markup language, .g. in XeTeX, html, or
> Openoffice, etc.).
>
> what I would like to say with this, is, that I think it would be
> really cool to first collect ideas and (although not implement these
> right away) leave the possibility open to support them, e.g. with
> font selections right out of the IME.
>
> Gerrit
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK
> & win great prizes Grand prize is a trip for two to an Open Source
> event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________ Scim-devel mailing
> list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/scim-devel

Zhe Su

Re: The future of SCIM project

Reply Threaded

That's the idea behind imbus and iBus projects. You may read this slides to see how imbus was designed:

http://imbus-dev.googlegroups.com/web/imbus.odp

Regards
James Su

On Thu, Nov 6, 2008 at 8:05 PM, David Oftedal <[hidden email]> wrote:

Continuing in the same vein, from a user's perspective, it makes sense
to maintain a much greater degree of separation between the mechanism
used for switching between input methods and the input methods
themselves. All of the current major input method solutions on Linux
(SCIM, UIM, and IIIMF) have aimed to be universal frameworks containing
their own switching mechanisms, with the result that bridging software
such as scim-uim has been necessary to make input methods accessible
from one framework accessible to the others.

If Linux were to get a standard, universal protocol whereby all input
methods could communicate with all text widgets, such a separation
between the selection mechanism and the methods themselves would
finally become feasible.

As a bonus, it would also minimise the need for extensive configuration
before the methods would work, as they would be handled through a
mechanism that was already a part of the system, rather than a
non-standard add-on.

In short, the changeover to a standard interface would be a vast
improvement to the user experience. I'm a little skeptical about the
prospect of intercepting keystrokes, seeing as there are applications
that capture keystrokes for other purposes than inputting text, but if
that could be resolved somehow, it would certainly make Linux a lot
easier to use with non-Western languages.

David Oftedal

On Thu, 6 Nov 2008 12:23:10 +0100
Gerrit Sangel <[hidden email]> wrote:

> Am Donnerstag 06 November 2008 schrieb Arne Goetje:
>
> > However, I'd like to propose a fundamental change on how input
> > methods work: X has not been designed for any other languages than
> > English. What we have now to support additional languages is XKB
> > and the XIM protocol, both of them are more or less dirty hacks and
> > have their problems. I'd like to replace those stuff altogether
> > with one general framework, where X is not the major role anymore.
> > The idea is to have a service running where X (via X extensions),
> > as well as framebuffer and other environments can connect to. This
> > service should take care of all keyboard (and virtual keyboard
> > through on-screen keyboards) activity to have consistent behavior
> > in all applications. That means, that if this service is installed
> > and running, X (and framebuffer, etc.) pipes all keyboard activity
> > to the service and gets the result (the string with the codepoints)
> > back. The service interacts with the user like the old solutions
> > did, through a front end, which needs to be written separately for
> > GTK, QT and other widget sets. IBus uses dbus to communicate
> > between those instances, which is a good idea IMHO. I will try to
> > push the development into this direction to get rid of this XIM,
> > GTK-IM and QT-IM crap.
> >
> > The big advatage with this approach would be that any (Unicode
> > aware) application could use this, without the need for extra code
> > to implement IME stuff... the applications just receive strings,
> > like they would with pure ASCII systems.
> >
> > Just my 2 NT$.
> >
> > Cheers
> > Arne
>
> From a users perspective, I would also strongly recommend this. If I
> compare CJK input of Linux with Windows or Mac, it is really a
> difference like day and night. I'm always wondering why I have to
> switch between two kind of input methods, first the "normal" scripts
> like english, german, and then complex scripts like Japanese,
> Chinese. To unify this all in _one_ selection menu would be great.
>
> Also, maybe I would recommend to first collect ideas about input
> systems and then design the IME with all this in mind. If not, and
> somebody has a cool idea, he maybe cannot implement it without all
> these dirty hacks.
>
> E.g., I have the idea to create an input method for latin based
> languages in order to conveniently type diacritics, even on a
> keyboard layout which usually doesn't support them. You would not
> need compose keys, deadkeys (well, ok, that's not a bad idea), or
> character tables anymore, but you can just choose the character you
> want to (e.g. type "Kohler" and you can choose "Köhler" or just leave
> it the way it is). Also I have the idea to create an input method for
> German Fraktur script (which I guess would be great in such a latin
> based IME), with which you can conveniently choose between latin and
> Fraktur just with the keyboard. The thing is, because these two
> scripts are unified in Unicode, you have to differentiate them via
> the font. The input method could then maybe via dbus tell the
> application in which you are typing to create markup depending on the
> script you would like to type. This could also be used if you want to
> type mixed Japanese or Chinese. A Chinese IME or Japanese IME would
> tell the text editor to switch the font (which would need different
> markups depending on the markup language, .g. in XeTeX, html, or
> Openoffice, etc.).
>
> what I would like to say with this, is, that I think it would be
> really cool to first collect ideas and (although not implement these
> right away) leave the possibility open to support them, e.g. with
> font selections right out of the IME.
>
> Gerrit
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK
> & win great prizes Grand prize is a trip for two to an Open Source
> event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________ Scim-devel mailing
> list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/scim-devel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

Arne Goetje

Re: The future of SCIM project

Reply Threaded

In reply to this post by Zhe Su

Zhe Su wrote:
> iBus has a fundamental issue: It uses raw dbus protocol which is not
> suitable for transferring complex objects. Thus the feature of iBus is
> very limited and can't cover the requirement of all existing input
> methods (both free/opensource and commercial).

I guess this can be resolved and your input on this would be highly
appreciated. :)

> Actually I always want to resume the development of imbus project
> (http://code.google.com/p/imbus/), which was co-designed by many
> experienced input method developers, including Hideki Hiura (the author
> of XIM and IIIMF), Choe Hwanjin (Korean input method developer) and me
> (the author of SCIM).
>
> From features perspective, imbus is far superior than iBus and SCIM.
> Because it has a fully object oriented architecture and supports
> transferring very complex objects over wire.

Probably. But imbus is not in a usable state right now and we need a
replacement for SCIM asap, because we have too much trouble with it.

> I'll try my best to find some time next year to continue this project.
> If you are interested in it, feel free to contact me.

I am, but I won't be much help in coding, as I have no coding experience...

> Your proposal looks great, however, in most case it's not applicable.
> The communication between input method and application is far beyond
> transferring string with codepoints. Both Windows and Mac provide
> complex API between application and input method. windows has TSF and
> IME(Input Method Editor API), Mac 10.5 has IMKit.
>
> All of these API require application to communicate with input method
> directly. And all keyboard events will go first into application then
> dispatch to input method selectively through the API. input method may
> ask application for wide range of informations and actions through the
> API, for example to display the composing string inside application's
> window, or to return the context around input cursor, etc.
>
> Actually GTK-IM and QT-IM do the almost same thing like TSF and IMKit.
> Unfortunately, we have multiple choices on Linux.

I know that it currently works this way. But the question is if this is
really necessary. As we can see, many applications have trouble with the
on-the-spot feature. Bottom line: as long as we depend on each
application / widget set to include some additional code to deal with
this IME communication, we will always have trouble. What would help is
a centralized library which can just be included by any application /
widget set and takes care of such stuff. Would also be much easier to
maintain... if this is feasible, I don't know. Would need some input
from professional developers...
IMHO these multiple choices are exactly the problem. And I'd like to get
rid of them.
But it's equally important to keep things simple. The more complex
things get, the more trouble we will have, especially if we depend on
other application coders to include this stuff into their applications
(which is bad anyways).
If we could have such an API and if we could force^Wencourage everyone
else to add full API support into their applications, that would also
work. But I guess that's utopia. (There are still lots of applications
which don't use GTK or QT...)
Therefor I like the idea that the applications don't need to care about
such communication and just receive strings, like they would with pure
ASCII and also XKB. And IMHO over-the-spot with a separate editing box
floating just below the cursor position is fine also (it's actually even
better when you are dealing with complex characters which need to be
displayed at a bigger font size to be able to make judgments). ;)

But that's just me. :)

Cheers
Arne
--
Arne Götje (高盛華) <[hidden email]>
PGP/GnuPG key: 1024D/685D1E8C
Fingerprint: 2056 F6B7 DEA8 B478 311F 1C34 6E9F D06E 685D 1E8C
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

signature.asc (260 bytes) Download Attachment

Arne Goetje

Re: The future of SCIM project

Reply Threaded

In reply to this post by Gerrit Sangel-2

Gerrit Sangel wrote:
> From a users perspective, I would also strongly recommend this. If I compare
> CJK input of Linux with Windows or Mac, it is really a difference like day
> and night. I’m always wondering why I have to switch between two kind of
> input methods, first the “normal” scripts like english, german, and then
> complex scripts like Japanese, Chinese. To unify this all in _one_ selection
> menu would be great.

That's the idea. :)

> E.g., I have the idea to create an input method for latin based languages in
> order to conveniently type diacritics, even on a keyboard layout which
> usually doesn’t support them. You would not need compose keys, deadkeys
> (well, ok, that’s not a bad idea), or character tables anymore, but you can
> just choose the character you want to (e.g. type “Kohler” and you can
> choose “Köhler” or just leave it the way it is).

That would need some word lists, I guess and it should be possible to
copy that functionality from CJK IMEs, because they more or less work
the same way. But it might be problematic if the word (with diacritics)
does not exists in the wordlist... then you would need dead-keys anyways.

> Also I have the idea to create an input method for German Fraktur script
> (which I guess would be great in such a latin based IME), with which you can
> conveniently choose between latin and Fraktur just with the keyboard. The
> thing is, because these two scripts are unified in Unicode, you have to
> differentiate them via the font. The input method could then maybe via dbus
> tell the application in which you are typing to create markup depending on
> the script you would like to type. This could also be used if you want to
> type mixed Japanese or Chinese. A Chinese IME or Japanese IME would tell the
> text editor to switch the font (which would need different markups depending
> on the markup language, .g. in XeTeX, html, or Openoffice, etc.).

yes, sending markup language is a nice feature, but the applications
need to understand the markup and react accordingly. So, this is not
really an IME problem, but more an application problem. FWIW, inputting
Fraktur would need full knowledge of the rules in which cases Joiners or
Non-Joiners need to be inserted into the text, so that the font displays
ligated text and non-ligated text properly. I guess it's doable, but
would probably also need a huge wordlist...

> what I would like to say with this, is, that I think it would be really cool
> to first collect ideas and (although not implement these right away) leave
> the possibility open to support them, e.g. with font selections right out of
> the IME.

That's why we discuss things here, right? ;)

Cheers
Arne
--
Arne Götje (高盛華) <[hidden email]>
PGP/GnuPG key: 1024D/685D1E8C
Fingerprint: 2056 F6B7 DEA8 B478 311F 1C34 6E9F D06E 685D 1E8C
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

signature.asc (260 bytes) Download Attachment

ZhengPeng Hou-2

Re: The future of SCIM project

Reply Threaded

In reply to this post by Arne Goetje

On Thu, Nov 06, 2008 at 10:43:53PM +0800, Arne Goetje wrote:

> Zhe Su wrote:
> > iBus has a fundamental issue: It uses raw dbus protocol which is not
> > suitable for transferring complex objects. Thus the feature of iBus is
> > very limited and can't cover the requirement of all existing input
> > methods (both free/opensource and commercial).
>
> I guess this can be resolved and your input on this would be highly
> appreciated. :)
>
> > Actually I always want to resume the development of imbus project
> > (http://code.google.com/p/imbus/), which was co-designed by many
> > experienced input method developers, including Hideki Hiura (the author
> > of XIM and IIIMF), Choe Hwanjin (Korean input method developer) and me
> > (the author of SCIM).
> >
> > From features perspective, imbus is far superior than iBus and SCIM.
> > Because it has a fully object oriented architecture and supports
> > transferring very complex objects over wire.
>
> Probably. But imbus is not in a usable state right now and we need a
> replacement for SCIM asap, because we have too much trouble with it.

because scim has been used widely and pretty long, then we find so many

problems, how about ibus? :) you really think it can be the default input
method in ubuntu's next release?

Cheers
Zhengpeng Hou

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

signature.asc (204 bytes) Download Attachment

Arne Goetje

Re: The future of SCIM project

Reply Threaded

ZhengPeng Hou wrote:
> because scim has been used widely and pretty long, then we find so many
> problems, how about ibus? :) you really think it can be the default input
> method in ubuntu's next release?

Maybe not next release, development time is too short for that. And in
it's current state certainly not. But we have learned a lot from the
problems with SCIM and are focusing on improving IBus, so that we don't
have the same problems again.
If imbus gets to a point where it's usable and it's better than what we
have, then I'm happy to switch over to imbus.

Cheers
Arne
--
Arne Götje (高盛華) <[hidden email]>
PGP/GnuPG key: 1024D/685D1E8C
Fingerprint: 2056 F6B7 DEA8 B478 311F 1C34 6E9F D06E 685D 1E8C
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

signature.asc (260 bytes) Download Attachment

Zhe Su

Re: The future of SCIM project

Reply Threaded

In reply to this post by Arne Goetje

On Thu, Nov 6, 2008 at 10:43 PM, Arne Goetje <[hidden email]> wrote:

Zhe Su wrote:
> iBus has a fundamental issue: It uses raw dbus protocol which is not
> suitable for transferring complex objects. Thus the feature of iBus is
> very limited and can't cover the requirement of all existing input
> methods (both free/opensource and commercial).

I guess this can be resolved and your input on this would be highly
appreciated. :)

I have no idea on it. It's caused by the limitation of dbus. That's why we decided not to use dbus when we designed imbus.

> Actually I always want to resume the development of imbus project
> (http://code.google.com/p/imbus/), which was co-designed by many
> experienced input method developers, including Hideki Hiura (the author
> of XIM and IIIMF), Choe Hwanjin (Korean input method developer) and me
> (the author of SCIM).
>
> From features perspective, imbus is far superior than iBus and SCIM.
> Because it has a fully object oriented architecture and supports
> transferring very complex objects over wire.

Probably. But imbus is not in a usable state right now and we need a
replacement for SCIM asap, because we have too much trouble with it.

That's why we need more resource on imbus to make it usable as soon as possible.

> I'll try my best to find some time next year to continue this project.
> If you are interested in it, feel free to contact me.

I am, but I won't be much help in coding, as I have no coding experience...

> Your proposal looks great, however, in most case it's not applicable.
> The communication between input method and application is far beyond
> transferring string with codepoints. Both Windows and Mac provide
> complex API between application and input method. windows has TSF and
> IME(Input Method Editor API), Mac 10.5 has IMKit.
>
> All of these API require application to communicate with input method
> directly. And all keyboard events will go first into application then
> dispatch to input method selectively through the API. input method may
> ask application for wide range of informations and actions through the
> API, for example to display the composing string inside application's
> window, or to return the context around input cursor, etc.
>
> Actually GTK-IM and QT-IM do the almost same thing like TSF and IMKit.
> Unfortunately, we have multiple choices on Linux.

I know that it currently works this way. But the question is if this is
really necessary. As we can see, many applications have trouble with the
on-the-spot feature. Bottom line: as long as we depend on each
application / widget set to include some additional code to deal with
this IME communication, we will always have trouble. What would help is
a centralized library which can just be included by any application /
widget set and takes care of such stuff. Would also be much easier to
maintain... if this is feasible, I don't know. Would need some input
from professional developers...
IMHO these multiple choices are exactly the problem. And I'd like to get
rid of them.
But it's equally important to keep things simple. The more complex
things get, the more trouble we will have, especially if we depend on
other application coders to include this stuff into their applications
(which is bad anyways).
If we could have such an API and if we could force^Wencourage everyone
else to add full API support into their applications, that would also
work. But I guess that's utopia. (There are still lots of applications
which don't use GTK or QT...)
Therefor I like the idea that the applications don't need to care about
such communication and just receive strings, like they would with pure
ASCII and also XKB. And IMHO over-the-spot with a separate editing box
floating just below the cursor position is fine also (it's actually even
better when you are dealing with complex characters which need to be
displayed at a bigger font size to be able to make judgments). ;)

Being a generic input method framework, it must support all features required by any existing input methods and languages. At least we shall try our best to make it. Otherwise, it won't be adopted by everybody, thus it's impossible to unify the solution.

But that's just me. :)

Cheers
Arne
--
Arne Götje (高盛華) <[hidden email]>
PGP/GnuPG key: 1024D/685D1E8C
Fingerprint: 2056 F6B7 DEA8 B478 311F 1C34 6E9F D06E 685D 1E8C
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

Doug Rintoul-2

Re: The future of SCIM project

Reply Threaded

Zhe Su wrote:
>
> Probably. But imbus is not in a usable state right now and we need a
> replacement for SCIM asap, because we have too much trouble with it.
>
> That's why we need more resource on imbus to make it usable as soon as
> possible.
What still needs to be done to get imbus into a usable state? I too
would like to see a replacement for SCIM sooner than later. We in SIL
are developing multilingual applications, and really need a good input
method framework in place to support our applications. I could probably
commit some development time to imbus if it would help move this forward.

Doug Rintoul
SIL Intl.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

Zhe Su

Re: The future of SCIM project

Reply Threaded

Welcome to join imbus project :-)

basically, imbus has two major components: libimbus and imbus daemon. libimbus was almost done, except for code clean up and unit tests. imbus daemon is not available yet.

So we need:
1. write unit tests for libimbus to make sure the code is correct and the design is ok.
2. implement imbus daemon.
3. write documentation

Then we need:
4. write various components based on imbus, like gui, input methods (can be ported from existing projects), gtk/qt im modules, xim server, etc.
5. push everybody to adopt imbus :-)

On Fri, Nov 7, 2008 at 12:32 AM, Doug Rintoul <[hidden email]> wrote:

Zhe Su wrote:
>
> Probably. But imbus is not in a usable state right now and we need a
> replacement for SCIM asap, because we have too much trouble with it.
>
> That's why we need more resource on imbus to make it usable as soon as
> possible.

What still needs to be done to get imbus into a usable state? I too
would like to see a replacement for SCIM sooner than later. We in SIL
are developing multilingual applications, and really need a good input
method framework in place to support our applications. I could probably
commit some development time to imbus if it would help move this forward.

Doug Rintoul
SIL Intl.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

David Oftedal

Re: The future of SCIM project

Reply Threaded

In reply to this post by Zhe Su

Thank you. It'll be interesting to see what lies ahead for imbus!

David Oftedal

On Thu, 6 Nov 2008 21:33:46 +0800
"Zhe Su" <[hidden email]> wrote:

> That's the idea behind imbus and iBus projects. You may read this
> slides to see how imbus was designed:
>
> http://imbus-dev.googlegroups.com/web/imbus.odp
>
> Regards
> James Su
>
> On Thu, Nov 6, 2008 at 8:05 PM, David Oftedal <[hidden email]> wrote:
>
> > Continuing in the same vein, from a user's perspective, it makes
> > sense to maintain a much greater degree of separation between the
> > mechanism used for switching between input methods and the input
> > methods themselves. All of the current major input method solutions
> > on Linux (SCIM, UIM, and IIIMF) have aimed to be universal
> > frameworks containing their own switching mechanisms, with the
> > result that bridging software such as scim-uim has been necessary
> > to make input methods accessible from one framework accessible to
> > the others.
> >
> > If Linux were to get a standard, universal protocol whereby all
> > input methods could communicate with all text widgets, such a
> > separation between the selection mechanism and the methods
> > themselves would finally become feasible.
> >
> > As a bonus, it would also minimise the need for extensive
> > configuration before the methods would work, as they would be
> > handled through a mechanism that was already a part of the system,
> > rather than a non-standard add-on.
> >
> > In short, the changeover to a standard interface would be a vast
> > improvement to the user experience. I'm a little skeptical about the
> > prospect of intercepting keystrokes, seeing as there are
> > applications that capture keystrokes for other purposes than
> > inputting text, but if that could be resolved somehow, it would
> > certainly make Linux a lot easier to use with non-Western languages.
> >
> > David Oftedal
> >
> >
> > On Thu, 6 Nov 2008 12:23:10 +0100
> > Gerrit Sangel <[hidden email]> wrote:
> >
> > > Am Donnerstag 06 November 2008 schrieb Arne Goetje:
> > >
> > > > However, I'd like to propose a fundamental change on how input
> > > > methods work: X has not been designed for any other languages
> > > > than English. What we have now to support additional languages
> > > > is XKB and the XIM protocol, both of them are more or less
> > > > dirty hacks and have their problems. I'd like to replace those
> > > > stuff altogether with one general framework, where X is not the
> > > > major role anymore. The idea is to have a service running where
> > > > X (via X extensions), as well as framebuffer and other
> > > > environments can connect to. This service should take care of
> > > > all keyboard (and virtual keyboard through on-screen keyboards)
> > > > activity to have consistent behavior in all applications. That
> > > > means, that if this service is installed and running, X (and
> > > > framebuffer, etc.) pipes all keyboard activity to the service
> > > > and gets the result (the string with the codepoints) back. The
> > > > service interacts with the user like the old solutions did,
> > > > through a front end, which needs to be written separately for
> > > > GTK, QT and other widget sets. IBus uses dbus to communicate
> > > > between those instances, which is a good idea IMHO. I will try
> > > > to push the development into this direction to get rid of this
> > > > XIM, GTK-IM and QT-IM crap.
> > > >
> > > > The big advatage with this approach would be that any (Unicode
> > > > aware) application could use this, without the need for extra
> > > > code to implement IME stuff... the applications just receive
> > > > strings, like they would with pure ASCII systems.
> > > >
> > > > Just my 2 NT$.
> > > >
> > > > Cheers
> > > > Arne
> > >
> > > From a users perspective, I would also strongly recommend this.
> > > If I compare CJK input of Linux with Windows or Mac, it is really
> > > a difference like day and night. I'm always wondering why I have
> > > to switch between two kind of input methods, first the "normal"
> > > scripts like english, german, and then complex scripts like
> > > Japanese, Chinese. To unify this all in _one_ selection menu
> > > would be great.
> > >
> > > Also, maybe I would recommend to first collect ideas about input
> > > systems and then design the IME with all this in mind. If not, and
> > > somebody has a cool idea, he maybe cannot implement it without all
> > > these dirty hacks.
> > >
> > > E.g., I have the idea to create an input method for latin based
> > > languages in order to conveniently type diacritics, even on a
> > > keyboard layout which usually doesn't support them. You would not
> > > need compose keys, deadkeys (well, ok, that's not a bad idea), or
> > > character tables anymore, but you can just choose the character
> > > you want to (e.g. type "Kohler" and you can choose "Köhler" or
> > > just leave it the way it is). Also I have the idea to create an
> > > input method for German Fraktur script (which I guess would be
> > > great in such a latin based IME), with which you can conveniently
> > > choose between latin and Fraktur just with the keyboard. The
> > > thing is, because these two scripts are unified in Unicode, you
> > > have to differentiate them via the font. The input method could
> > > then maybe via dbus tell the application in which you are typing
> > > to create markup depending on the script you would like to type.
> > > This could also be used if you want to type mixed Japanese or
> > > Chinese. A Chinese IME or Japanese IME would tell the text editor
> > > to switch the font (which would need different markups depending
> > > on the markup language, .g. in XeTeX, html, or Openoffice, etc.).
> > >
> > > what I would like to say with this, is, that I think it would be
> > > really cool to first collect ideas and (although not implement
> > > these right away) leave the possibility open to support them,
> > > e.g. with font selections right out of the IME.
> > >
> > > Gerrit
> > >
> > > -------------------------------------------------------------------------
> > > This SF.Net email is sponsored by the Moblin Your Move Developer's
> > > challenge Build the coolest Linux based applications with Moblin
> > > SDK & win great prizes Grand prize is a trip for two to an Open
> > > Source event anywhere in the world
> > > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > > _______________________________________________ Scim-devel mailing
> > > list [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/scim-devel
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> > challenge
> > Build the coolest Linux based applications with Moblin SDK & win
> > great prizes
> > Grand prize is a trip for two to an Open Source event anywhere in
> > the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Scim-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/scim-devel
> >

Huang Peng-2

Re: The future of SCIM project

Reply Threaded

In reply to this post by Ryo Dairiki-2

On Thu, Nov 6, 2008 at 8:52 AM, Ryo Dairiki <[hidden email]> wrote:

Hi everyone,

Today, I would like to discuss with you about the future of SCIM project.
Now development of SCIM has low activity, due to lack of developers.
We can fix only small bugs for now, but we have to restart the project
to solve fundamental problems of SCIM-1.x framework.

As you know, SCIM-1.x framework have some problem.
- It is written in C++, and causes ABI conflict with some commercial
products.
- There are too many frontends and backends, which makes SCIM complicated.
- The core library and immodules are not completely separated from GUI
libraries.
- There are no console support. (now under development)

I think we should now stop maintaining SCIM-1.x branch,
and choose one the the following:

1. Stop develop SCIM completely, move into IBus.
2. Create a new branch which have no backward compatibility with SCIM-1.x.

I was a SCIM package maintainer in Red Hat. I and colleagues have considered this those questions for a long time. After investigation of the imbus design and disscussion about some issues with dbus authors and hackers, I began to develop the first prototype of ibus and several engins for ibus. It bases on dbus and uses Python language, and it is bus centre architechure (like the design of imbus). Until now, I released several source snaps. It works well. It proved our solution is OK.

Last month, I began development of the second implemention of ibus in C language. And I will try to release the first workable version in next month. Now, you could get the source code in develop branch http://github.com/phuang/ibus/tree/c_impl .

The secound implemention of ibus also bases on dbus, and uses gobject object system. It uses mature projects instead of developing from scratch. It will save more efforts and avoid riskes. For example: lacking resources for maintaining project continuously. It also keeps ibus simple and easy to maintain and extend.

Wish more developers can join us.

Thanks
Peng Huang

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

Zhe Su

Re: The future of SCIM project

Reply Threaded

On Fri, Nov 7, 2008 at 12:35 PM, Peng Huang <[hidden email]> wrote:

On Thu, Nov 6, 2008 at 8:52 AM, Ryo Dairiki <[hidden email]> wrote:

Hi everyone,

Today, I would like to discuss with you about the future of SCIM project.
Now development of SCIM has low activity, due to lack of developers.
We can fix only small bugs for now, but we have to restart the project
to solve fundamental problems of SCIM-1.x framework.

As you know, SCIM-1.x framework have some problem.
- It is written in C++, and causes ABI conflict with some commercial
products.
- There are too many frontends and backends, which makes SCIM complicated.
- The core library and immodules are not completely separated from GUI
libraries.
- There are no console support. (now under development)

I think we should now stop maintaining SCIM-1.x branch,
and choose one the the following:

1. Stop develop SCIM completely, move into IBus.
2. Create a new branch which have no backward compatibility with SCIM-1.x.

I was a SCIM package maintainer in Red Hat. I and colleagues have considered this those questions for a long time. After investigation of the imbus design and disscussion about some issues with dbus authors and hackers, I began to develop the first prototype of ibus and several engins for ibus. It bases on dbus and uses Python language, and it is bus centre architechure (like the design of imbus). Until now, I released several source snaps. It works well. It proved our solution is OK.

Last month, I began development of the second implemention of ibus in C language. And I will try to release the first workable version in next month. Now, you could get the source code in develop branch http://github.com/phuang/ibus/tree/c_impl .

The secound implemention of ibus also bases on dbus, and uses gobject object system. It uses mature projects instead of developing from scratch. It will save more efforts and avoid riskes. For example: lacking resources for maintaining project continuously. It also keeps ibus simple and easy to maintain and extend.

Wish more developers can join us.

Then how about those rich features we agreed when designing imbus? The main goal of project imbus is to define a complete set of objects, events and high level protocols for input methods. Actually, imbus has an abstract layer above low level communication implementation, it's easy to adapt dbus as an implementation, which then will take advantages of dbus.
In this point of view, I see no reason to start another project instead of working on imbus together.
Anyway, I'll support ibus if it can support all features that designed for imbus.

Thanks
Peng Huang

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

Huang Peng-2

Re: The future of SCIM project

Reply Threaded

In reply to this post by Zhe Su

On Thu, Nov 6, 2008 at 7:56 PM, Zhe Su <james.su@gmail.com> wrote:

iBus has a fundamental issue: It uses raw dbus protocol which is not suitable for transferring complex objects. Thus the feature of iBus is very limited and can't cover the requirement of all existing input methods (both free/opensource and commercial).

dbus does not have object system. So it can not transfer objects by default. But it supports transfer variant type data and very complex structures. With this featrue, implementing object transferring is not difficult. And I am developing it in development branch. And I also want to discuss this feature with dbus community, and decide if should make a patch to implementing this feature for dbus.

BTW, I really do not think it is good to re-develop a dbus like protocol just be used by one project.

BRs
Peng Huang

Zhe Su

Re: The future of SCIM project

Reply Threaded

On Fri, Nov 7, 2008 at 12:59 PM, Peng Huang <[hidden email]> wrote:

On Thu, Nov 6, 2008 at 7:56 PM, Zhe Su <james.su@gmail.com> wrote:

iBus has a fundamental issue: It uses raw dbus protocol which is not suitable for transferring complex objects. Thus the feature of iBus is very limited and can't cover the requirement of all existing input methods (both free/opensource and commercial).

dbus does not have object system. So it can not transfer objects by default. But it supports transfer variant type data and very complex structures. With this featrue, implementing object transferring is not difficult. And I am developing it in development branch. And I also want to discuss this feature with dbus community, and decide if should make a patch to implementing this feature for dbus.

BTW, I really do not think it is good to re-develop a dbus like protocol just be used by one project.

I suggest you to read the source code of imbus. In imbus, there is an interface called IMStream, which is in charge of marshalling/demarshalling data. It's very easy to write an IMStream implementation based on dbus. Now, there are two different implementations, one is IMTextStream, another is IMBinaryStream, we can have IMDBusStream, and even IMXMLStream, etc. So, you can see that, imbus is not re-developing a protocol, instead, it provides an interface to make it easy to reuse existing protocol.

BRs
Peng Huang

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel

Ryo Dairiki-2

Re: The future of SCIM project

Reply Threaded

In reply to this post by Ryo Dairiki-2

There seems so much idea and opinion on this topic.
I'm happy to see so many people have interest on it. :)

My opinion:

- Messaging daemon
There should be only one daemon for passing messages here and there.
All the clients should use single protocol to communicate with the daemon.
From this point of view, SCIM is too complex.
All the IMModule load SCIM library on it, and use SCIM library directly.
There is many lines saying the same thing in SCIM-GTKIM and SCIM-QTIM.
I think this makes SCIM much heavier.

- X IM extension
I'm agree with Arne Goetje's idea.
X is one type of the client for IM server.
We can develop it separately with IM framework itself.
So, it's a topic to discuss another day.

- Configuration tool
Maybe, compiz is a good example.
All the plugin for compiz provide XML entry file,
which describes all options (name, type, and default value),
and translation texts for them.
There are compiz configuration tools based on both GTK and KDE.
Both of them renders widgets from data read from the XML file.
Basically, there is no dependency between Compiz plugins and GUI libraries.

> Peng Huang
Btw, talking about IBus, please join me the project.
My account: [hidden email]

Regards,
Ryo Dairiki <[hidden email]>

Ryo Dairiki wrote:

> Hi everyone,
>
> Today, I would like to discuss with you about the future of SCIM project.
> Now development of SCIM has low activity, due to lack of developers.
> We can fix only small bugs for now, but we have to restart the project
> to solve fundamental problems of SCIM-1.x framework.
>
> As you know, SCIM-1.x framework have some problem.
> - It is written in C++, and causes ABI conflict with some commercial
> products.
> - There are too many frontends and backends, which makes SCIM complicated.
> - The core library and immodules are not completely separated from GUI
> libraries.
> - There are no console support. (now under development)
>
> I think we should now stop maintaining SCIM-1.x branch,
> and choose one the the following:
>
> 1. Stop develop SCIM completely, move into IBus.
> 2. Create a new branch which have no backward compatibility with SCIM-1.x.
>
> Talking about IBus, which is a very simple framework under development.
> Joining to IBus project and making it stable enough for daily use is one
> thought.
> Or developing SCIM-2.0 is another thought.
> (We need more developers for starting SCIM-2.0 branch.
> Please volunteer to join the project if you choose SCIM-2.0.)
>
> What do you think?
> Please give me your idea.
>
> Regards,
> Ryo Dairiki <[hidden email]>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Scim-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/scim-devel
>
>

Huang Peng-2

Re: The future of SCIM project

Reply Threaded

On Sat, Nov 8, 2008 at 12:13 AM, Ryo Dairiki <[hidden email]> wrote:

There seems so much idea and opinion on this topic.
I'm happy to see so many people have interest on it. :)

My opinion:

- Messaging daemon
There should be only one daemon for passing messages here and there.
All the clients should use single protocol to communicate with the daemon.
From this point of view, SCIM is too complex.
All the IMModule load SCIM library on it, and use SCIM library directly.
There is many lines saying the same thing in SCIM-GTKIM and SCIM-QTIM.
I think this makes SCIM much heavier.

- X IM extension
I'm agree with Arne Goetje's idea.
X is one type of the client for IM server.
We can develop it separately with IM framework itself.
So, it's a topic to discuss another day.

- Configuration tool
Maybe, compiz is a good example.
All the plugin for compiz provide XML entry file,
which describes all options (name, type, and default value),
and translation texts for them.
There are compiz configuration tools based on both GTK and KDE.
Both of them renders widgets from data read from the XML file.
Basically, there is no dependency between Compiz plugins and GUI libraries.

It is a good idea. It likes an issue in ibus (http://code.google.com/p/ibus/issues/detail?id=100 ) . In this issue, I prepare use an array to describe the configurable items, but maybe XML is better.

BTW, I consider if all option items from differernt engines should pe put in one UI (Like compiz) . Or separate them. Each engine has a configure UI and ibus provides API or service for create UI from XML.

> Peng Huang
Btw, talking about IBus, please join me the project.
My account: [hidden email]

Done.
Source code is in http://github.com/phuang . You could folk my git trees in github.com or clone them to other places.

1 2