subject:"Re\: Some points about IM integration"

Hi, all.

This thread is not that long, so I've read it all. I'm yet another
native Chinese user.

I agree with the idea of Taylor's origin post.

Some people want framework of frameworks. I appreciate their efforts.
However, I don't think this make sense if we consider long-term.

If someone is trying to make thing simpler and more elegant, go ahead.

I like the Mac OS X way of language settings. I'm happy to see GNOME
is catching up.

I don't know how much integration is done in code. But I think you
should examine both IBus and Fcitx carefully before hardcode anything.
I think the internally more elegant one should be picked.

From various discussion I've seen, many experienced user would see
Fcitx to IBus migration as a serious regression. So be careful.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Marguerite Su

On Tue, May 15, 2012 at 7:27 AM, Owen Taylor otay...@redhat.com wrote:
 In general, choice of input method framework is not a goal in itself.
 If we choose a single input method framework to integrate with GNOME -
 that doesn't make GNOME like proprietary software from Apple and Microsoft,
 because GNOME will still be 100% Free Software, and will still be developed
 in the open by the GNOME community.

 GNOME doesn't want to work well just for tweakers and enthusiasts - it's
 very important to the project that GNOME works well for all users without
 tweaking. We want to give the choice of using Free Software to
 everybody - this is a much more fundamental form of choice than giving a small
 group of users the ability to swap out a different input method framework
 underneath GNOME.


no offense, but if Chinese or CJK Community is a small group(I think
I've already be clear about what CJK users are doing today. they'are
the nowadays tweakers you called. why? because you didn't ship what
they want. you know, IM is the most famous workaround in i18n world),
GNOME Asia can be shutdown.

so is Chinese or CJK Community a small group or second class? say
that in public in Hong Kong.

so do not make any hypothesis you don't even know about.

I've heard enough of this and feel great disrespect.

assume: if world factory think, oh, english users has little
feedback in Chinese. so they're a small group. then ship any kind of
clothes, shoes they like to Europe market. will you buy it?
absolutely and apparently no.

then that's the case GNOME will face.

I've also heard enough of oh, then the only solution is to drop
GNOME in Chinese Community about this affair.

I'm okay about it. they're users, I as a packager can't force they
choose what they like.

and today they still, although the choice range is becoming narrower
but still, have choices. KDE/xfce.

I'm okay about it. no matter what they will use, they're still my
target as a packager.

but can you be okay about it?

can you even dare a little bit to say CJK is not important? no.

then pretty much GNOME developers will leave GNOME tomorrow.

that's the worst case we both never want to see it ever happens.

if no users/local developers, who will you develop an IM for?

sorry for my wording, but it really drives me crazy.

I think mutual respect is the basis for multi-culture communication.

 GNOME isn't just a set of parts that a Linux distributor takes and uses
 to create a working system - we also take responsibility for creating
 a fully working system. This means deciding how GNOME interacts with
 system components like sound and networking and printing and when necessary
 enhancing those components to provide the right experience to the user.


yes and no. your will is good and respectful.

but have you ever discussed it with downstream distributions?

I cc-ed openSUSE GNOME Community leader, Vincent, to see what he will
think on this.

yes, I agree and thanks for, some of GNOME applications are god-like
good, but GNOME itself is not GOD to make decisions for
users/distributions/others.

or maybe tomorrow you would like to say oh, we should take
responsibility to write a new kernel, we should take responsibility to
reinvent YaST2? that's what you think arrogantly and will certainly
do if you find upstream doesn't accept you proposal.

want to take responsibility is under the hypothesis that the ones
who nowadays had already taken responsibility want to share. but have
you ever asked?

no. at least Vincent will feel surprised on this.

who will judge the right experience? users themselves.

so what if they do not even ever want/like your
over-responsibility-driven product?

that's the case right now.

oh, we should take responsibility to ship an IM we think users like,
while actually a large  group of its users are using and will use a
totally different tool.

what you think, does not, and will not, even ever matters.

 So we can't leave it up to one Linux distributor to combine GNOME with
 fcitx to make a version of GNOME that works well for zh_CN and another
 Linux distributor to combine GNOME with RIME or hime to make a version
 of GNOME that works well for zh_TW. We want GNOME to, without customization,
 work well for zh_CN, zh_TW, hi_IN, ru_RU, en_US, and so forth.


that's what distributions nowadays are doing. and users said, say and
will say, I like it.

they enjoy this freedom feeling.

I think tomorrow I will be a millionaire doesn't make any sense.

do respect reality.

 Of course, it would be a mistake to think that a small group of English
 speaking developers could make GNOME work well in all these languages. That
 would be impossible! But from experience, we know that simply leaving a
 problem like this to external developers and hoping for the best doesn't
 work out well. Instead we need to engage users and developers from these
 language communities into the GNOME development community.

 I don't want to minimize how easy that is - I know

Re: Some points about IM integration

2012-05-15 Thread Sergey Udaltsov

 I've heard enough of this and feel great disrespect.
Please Marguerite, let's not get personal (or even national) on this
thread. You should know better than occusing people who sincerelly
want GNOME to provide the best - and do not mean any nationalism or
disrespect.

But really there is another side to it. The worst thing that happened
to GNOME3 comparing to GNOME2 is that for nearly every aspect GNOME3
is trying to find THE solution (for the valid reason of polished UX) -
and without specifying managed interfaces, all other solutions just
have zero chance to compete (so THE solution immediately becomes THE
ONLY POSSIBLE solution). I am really excited to see that this approach
demonstrates its fundamental weakness in case of IMs - that gives
another chance to everyone to think about general GNOME strategy, to
start thinking in terms of interfaces, not particular implementations.

I understand that GNOME devs would be happy to choose IBus as the
default solution, since it is most GNOME-oriented and the integration
can be as tight as GNOME high UX standards would require. Quite
possible that is sane. But it was told here that IBus (fundamentally?)
lacks some substantial features that other IM frameworks have - so why
IBus should be the only possible option?

Let's have defaul solution - the best point of compromise between
language support, UX, developers attitude to GNOME etc etc. But let's
not make it the only possible solution.

I hope noone is going to fallback to the worst possible argument it
is FOSS, you can always patch it - I would consider it as some kind
of Godwin law for FOSS architectures.

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Tue, May 15, 2012 at 4:40 PM, Marguerite Su i...@marguerite.su wrote:
 no offense, but if Chinese or CJK Community is a small group(I think
 I've already be clear about what CJK users are doing today. they'are
 the nowadays tweakers you called. why? because you didn't ship what
 they want. you know, IM is the most famous workaround in i18n world),
 GNOME Asia can be shutdown.
AFAIK, GNOME never maintained a distro. Some distros don't maintain
CJK input well. That's why some people tweaks. So why not solve the
CJK input problem in GNOME and you packagers can have a rest?

 so is Chinese or CJK Community a small group or second class? say
 that in public in Hong Kong.
 so do not make any hypothesis you don't even know about.
 I've heard enough of this and feel great disrespect.
 assume: if world factory think, oh, english users has little
 feedback in Chinese. so they're a small group. then ship any kind of
 clothes, shoes they like to Europe market. will you buy it?
 absolutely and apparently no.
 then that's the case GNOME will face.
I haven't seen any FOSS projects have this kind of mindsets.
Complaint is not always bad.
Please show people a link or something so motivated people can help
solving problems.

 I've also heard enough of oh, then the only solution is to drop
 GNOME in Chinese Community about this affair.
 I'm okay about it. they're users, I as a packager can't force they
 choose what they like.
 and today they still, although the choice range is becoming narrower
 but still, have choices. KDE/xfce.
 I'm okay about it. no matter what they will use, they're still my
 target as a packager.
 but can you be okay about it?
 can you even dare a little bit to say CJK is not important? no.
 then pretty much GNOME developers will leave GNOME tomorrow.
 that's the worst case we both never want to see it ever happens.
 if no users/local developers, who will you develop an IM for?
 sorry for my wording, but it really drives me crazy.
 I think mutual respect is the basis for multi-culture communication.
I'm tired of this kind of arguments. When some people see
regression/breakage, they just switch to other things without think
twice. I don't this is the way any local or global FOSS community
should work. I try to report a bug for FOSS whenever I'm sure there is
a problem.

 yes and no. your will is good and respectful.
 but have you ever discussed it with downstream distributions?
 I cc-ed openSUSE GNOME Community leader, Vincent, to see what he will
 think on this.
 yes, I agree and thanks for, some of GNOME applications are god-like
 good, but GNOME itself is not GOD to make decisions for
 users/distributions/others.
 or maybe tomorrow you would like to say oh, we should take
 responsibility to write a new kernel, we should take responsibility to
 reinvent YaST2? that's what you think arrogantly and will certainly
 do if you find upstream doesn't accept you proposal.
 want to take responsibility is under the hypothesis that the ones
 who nowadays had already taken responsibility want to share. but have
 you ever asked?
 no. at least Vincent will feel surprised on this.
 who will judge the right experience? users themselves.
 so what if they do not even ever want/like your
 over-responsibility-driven product?
 that's the case right now.
 oh, we should take responsibility to ship an IM we think users like,
 while actually a large  group of its users are using and will use a
 totally different tool.
 what you think, does not, and will not, even ever matters.
 that's what distributions nowadays are doing. and users said, say and
 will say, I like it.
 they enjoy this freedom feeling.
 I think tomorrow I will be a millionaire doesn't make any sense.
 do respect reality.
Whether GNOME, as an international FOSS project, can make CJK input
better or worse in this integration process is highly dependent on
whether there is effective participation of native CJK users. This
need efforts from both sides. But I'm enthusiastic about that.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Vincent Untz

Marguerite,

(First, no need to cc me, I'm obviously subscribed to desktop-devel-list
:-))

Le mardi 15 mai 2012, à 16:40 +0800, Marguerite Su a écrit :
 On Tue, May 15, 2012 at 7:27 AM, Owen Taylor otay...@redhat.com wrote:
  In general, choice of input method framework is not a goal in itself.
  If we choose a single input method framework to integrate with GNOME -
  that doesn't make GNOME like proprietary software from Apple and Microsoft,
  because GNOME will still be 100% Free Software, and will still be developed
  in the open by the GNOME community.
 
  GNOME doesn't want to work well just for tweakers and enthusiasts - it's
  very important to the project that GNOME works well for all users without
  tweaking. We want to give the choice of using Free Software to
  everybody - this is a much more fundamental form of choice than giving a 
  small
  group of users the ability to swap out a different input method framework
  underneath GNOME.
 
 
 no offense, but if Chinese or CJK Community is a small group(I think
 I've already be clear about what CJK users are doing today. they'are
 the nowadays tweakers you called. why? because you didn't ship what
 they want. you know, IM is the most famous workaround in i18n world),
 GNOME Asia can be shutdown.
 
 so is Chinese or CJK Community a small group or second class? say
 that in public in Hong Kong.

I feel you misunderstood what Owen wrote. My understanding is that when
Owen is talking about a small group here, it would only be a small group
because our goal is to have GNOME work well by default for most people,
including most users of the CJK community. If we manage to do that, then
only a small number of people would need to do some changes (like using
a different input method framework).

Now, there's obviously the question of whether this goal is achievable:
can we cover the needs of most users (including most users of the CJK
community) with one input method framework? Some people in this thread
seems to think it's possible, while others believe it's not. I can't
answer this as I've no background on input methods in general.

It would surely help to have some simple wiki page summarizing the
current state of ibus and fctix, both as frameworks in general as well
as for the availability and state of their plugins. People have been
trying to tell the pros and cons of both in various mails, but I don't
think anybody really managed to get a global view because of the number
of mails.

[...]

  GNOME isn't just a set of parts that a Linux distributor takes and uses
  to create a working system - we also take responsibility for creating
  a fully working system. This means deciding how GNOME interacts with
  system components like sound and networking and printing and when necessary
  enhancing those components to provide the right experience to the user.
 
 yes and no. your will is good and respectful.
 
 but have you ever discussed it with downstream distributions?
 
 I cc-ed openSUSE GNOME Community leader, Vincent, to see what he will
 think on this.

Hrm, I'm not sure what you expect me to say here :-) This is the way
GNOME has been working for a while. For instance, this is why GNOME has
tight integration with NetworkManager and PulseAudio. Of course, this
raises challenges for integrators downstream (as well as for some
advanced users) and I'm very well aware of this. But we feel (where we
= GNOME) it helps us build a better user experience.

Cheers,

Vincent

-- 
Les gens heureux ne sont pas pressés.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Tue, May 15, 2012 at 5:45 PM, Vincent Untz vu...@gnome.org wrote:
 It would surely help to have some simple wiki page summarizing the
 current state of ibus and fctix, both as frameworks in general as well
 as for the availability and state of their plugins. People have been
 trying to tell the pros and cons of both in various mails, but I don't
 think anybody really managed to get a global view because of the number
 of mails.
I cannot agree more.
I just registered a Wikia page for you guys.
http://cjkinput.wikia.com/wiki/CJK_Input_Wiki
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Marguerite Su

XOXO, Vuntz,

at first I want to declare a big progress Weng and Takao made in the
other thread.

IBUS won't be compulsory. it will be optional. distribution can customize it.

it's enough for me.

actually I started my thread because I thought IBus will be compulsory
for my openSUSE distro who is planning to rely on Fcitx gradually.

now I got my answer.

then this thread will turn to be a developers' talk about how to make
it better in tech details. in which field I have no idea to express
and no knowledge thus no word to say.

so it's my time to say, Goodbye.

(of course as a Foss distro maintainer, I'll watch this.)

On Tue, May 15, 2012 at 5:45 PM, Vincent Untz vu...@gnome.org wrote:
 Marguerite,

 (First, no need to cc me, I'm obviously subscribed to desktop-devel-list
 :-))

 Le mardi 15 mai 2012, à 16:40 +0800, Marguerite Su a écrit :
 On Tue, May 15, 2012 at 7:27 AM, Owen Taylor otay...@redhat.com wrote:
  In general, choice of input method framework is not a goal in itself.
  If we choose a single input method framework to integrate with GNOME -
  that doesn't make GNOME like proprietary software from Apple and Microsoft,
  because GNOME will still be 100% Free Software, and will still be developed
  in the open by the GNOME community.
 
  GNOME doesn't want to work well just for tweakers and enthusiasts - it's
  very important to the project that GNOME works well for all users without
  tweaking. We want to give the choice of using Free Software to
  everybody - this is a much more fundamental form of choice than giving a 
  small
  group of users the ability to swap out a different input method framework
  underneath GNOME.
 

 no offense, but if Chinese or CJK Community is a small group(I think
 I've already be clear about what CJK users are doing today. they'are
 the nowadays tweakers you called. why? because you didn't ship what
 they want. you know, IM is the most famous workaround in i18n world),
 GNOME Asia can be shutdown.

 so is Chinese or CJK Community a small group or second class? say
 that in public in Hong Kong.

 I feel you misunderstood what Owen wrote. My understanding is that when
 Owen is talking about a small group here, it would only be a small group
 because our goal is to have GNOME work well by default for most people,
 including most users of the CJK community. If we manage to do that, then
 only a small number of people would need to do some changes (like using
 a different input method framework).

 Now, there's obviously the question of whether this goal is achievable:
 can we cover the needs of most users (including most users of the CJK
 community) with one input method framework? Some people in this thread
 seems to think it's possible, while others believe it's not. I can't
 answer this as I've no background on input methods in general.

 It would surely help to have some simple wiki page summarizing the
 current state of ibus and fctix, both as frameworks in general as well
 as for the availability and state of their plugins. People have been
 trying to tell the pros and cons of both in various mails, but I don't
 think anybody really managed to get a global view because of the number
 of mails.


Vuntz, I have a detailed blog about this in tech details I know.

so maybe I can post it on our EN WIKI or lizards.opensuse.org (BTW,
I'm a Member!)

they're just some basic points of IM. it won't help much on IM development.

but it'll be pretty much easy for maintainers to catch up.

(like I said, after James Su left SuSE, no one can understand his work any more)

 [...]

  GNOME isn't just a set of parts that a Linux distributor takes and uses
  to create a working system - we also take responsibility for creating
  a fully working system. This means deciding how GNOME interacts with
  system components like sound and networking and printing and when necessary
  enhancing those components to provide the right experience to the user.

 yes and no. your will is good and respectful.

 but have you ever discussed it with downstream distributions?

 I cc-ed openSUSE GNOME Community leader, Vincent, to see what he will
 think on this.

 Hrm, I'm not sure what you expect me to say here :-) This is the way
 GNOME has been working for a while. For instance, this is why GNOME has
 tight integration with NetworkManager and PulseAudio. Of course, this
 raises challenges for integrators downstream (as well as for some
 advanced users) and I'm very well aware of this. But we feel (where we
 = GNOME) it helps us build a better user experience.


I at first thought GNOME is planning to grab free options from users
and distros.

like we openSUSE choose fcitx as default IM, but we can do nothing on
IBUS then. then we won't choose fcitx any more. because we don't like
to act fool. the we have no freedom to choose our distros default IM.

but apparently not.

I got promise from Takao.

so Vincent, maybe you can say, Congrats? XD.

Marguerite

 Cheers,

 Vincent

 --
 Les gens heureux

Re: Some points about IM integration

2012-05-15 Thread Florian Müllner

On Tue, May 15, 2012 at 10:40 AM, Marguerite Su i...@marguerite.su wrote:

 On Tue, May 15, 2012 at 7:27 AM, Owen Taylor otay...@redhat.com wrote:
  GNOME doesn't want to work well just for tweakers and enthusiasts - it's
  very important to the project that GNOME works well for all users without
  tweaking. We want to give the choice of using Free Software to
  everybody - this is a much more fundamental form of choice than giving a
 small
  group of users the ability to swap out a different input method framework
  underneath GNOME.

 no offense, but if Chinese or CJK Community is a small group(I think
 I've already be clear about what CJK users are doing today. they'are
 the nowadays tweakers you called. why? because you didn't ship what
 they want.



Please, no reason to get offended - assume well and everything. I'm sure
what Owen meant is the following:

The group of CJK users who tweak / replace the IM (because the
out-of-the-box experience sucks) is small compared to the group of CJK
users who don't use free software / GNOME at all (because the
out-of-the-box experience sucks).

Introducing another level of abstraction (IM framework framework) may
make the first group happy, but it doesn't help the second group at all.
Making the out-off-the-box experience not suck on the other hand should
benefit *all* CJK users.


so is Chinese or CJK Community a small group or second class? say
 that in public in Hong Kong.


Well, according to your own words, GNOME does not ship what [CJK users]
want - I guess you can call that second class. The whole idea of
integrating IM into the core desktop rather than keeping it as an
after-thought is to make CJK users *first* class citizens. So again, please
don't feel offended.


Regards,
Florian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

独裁无胆，民主无量，打着为民着想的旗号强奸民意，一句资源有限就可以免于全部责任

去吧，发展葛弄姆特色的自由软件

Go on your work, hurt more fans and lose more users

sent from android
On May 15, 2012 7:28 AM, Owen Taylor otay...@redhat.com wrote:

In general, choice of input method framework is not a goal in itself.
If we choose a single input method framework to integrate with GNOME -
that doesn't make GNOME like proprietary software from Apple and Microsoft,
because GNOME will still be 100% Free Software, and will still be developed
in the open by the GNOME community.

GNOME doesn't want to work well just for tweakers and enthusiasts - it's
very important to the project that GNOME works well for all users without
tweaking. We want to give the choice of using Free Software to
everybody - this is a much more fundamental form of choice than giving a
small
group of users the ability to swap out a different input method framework
underneath GNOME.

GNOME isn't just a set of parts that a Linux distributor takes and uses
to create a working system - we also take responsibility for creating
a fully working system. This means deciding how GNOME interacts with
system components like sound and networking and printing and when necessary
enhancing those components to provide the right experience to the user.

So we can't leave it up to one Linux distributor to combine GNOME with
fcitx to make a version of GNOME that works well for zh_CN and another
Linux distributor to combine GNOME with RIME or hime to make a version
of GNOME that works well for zh_TW. We want GNOME to, without
customization,
work well for zh_CN, zh_TW, hi_IN, ru_RU, en_US, and so forth.

Of course, it would be a mistake to think that a small group of English
speaking developers could make GNOME work well in all these languages. That
would be impossible! But from experience, we know that simply leaving a
problem like this to external developers and hoping for the best doesn't
work out well. Instead we need to engage users and developers from these
language communities into the GNOME development community.

I don't want to minimize how easy that is - I know there are very
significant
barriers of language, timezone, and distance that make this hard. I know
that bugs get ignored and patches sit around unreviewed. But still,
active engagement is the only way forward. I think it's absolutely
wonderful
how many people have gotten involved in the current discussion!

We also need to keep in mind that we aren't talking about the choice of
input
method, we are talking about input method *frameworks*. The basics of
passing
events from application to daemon, loading different input method backends,
handling hotkeys and displaying feedback are going to be very similar for
all East Asian languages.

Things like displaying feedback may be a little different if we move
further
afield to Thai or Hindi - but still, there is no fundamental reason that
they
need a different *framework*.

Using a single input framework for all GNOME users has many benefits.
GNOME developers can reproduce bugs that users run into. Bugs only have to
be fixed once, not in multiple frameworks. We can actually figure out how
to make input methods work with onscreen keyboards and accessibility. Our
designers can collaborate on making the configuration dialogs conform to
GNOME standards.

Finally, using a single input method framework is pretty much essential to
the goal of allowing users to configure languages at runtime with a nice
user
interface. If language A and language B require different input method
*frameworks*, there is no way that the user can switch between them with a
hotkey.

In general, I don't see standardizing D-Bus interfaces so that GNOME can
work with multiple input method frameworks as being a useful activity.
If the D-Bus interfaces are carefully maintained and changed only with
agreement and advanced notice, then they will impede the progress of bug
fixing and making things better. If the interfaces are not carefully
maintained, then they aren't standards at all, and users will constantly
encounter breakage.

And in any case, as described above, there has to be *one* framework that
works as well as we can possibly make it for all users. Multiple partially
working frameworks are not a substitute.

All of the above is an argument only for picking a single input method
framework. It doesn't say anything about what input method framework we
should pick. The fact that the IBus developers have been engaged with
GNOME for quite some time and are willing to work with us to create a user
experience that is simple and consistent with the GNOME principles is
certainly a big plus, but we do need to make sure that the end result
works well as well as looking good.

- Owen

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Xu Pengfei

hi, guys

I saw this bad news from
http://linuxtoy.org/archives/gnome-and-cjk-community-debates-about-ibus-integration-of-gnome-3-6.html

It's a chinese linux news blog, Do you know how to input those characters?
I think the input is the most important things of a desktop.
If i can't input,no mater how beautiful or powerful the desktop is, it is a
rubbish.

To the BOSS,

If Mr. Linus said the kernel will only support KDE, and KDE will be the
standard UI, what will you do?
I don't care which one is the default IM, i just care about that i can
choose the best one i like.

BTW:I like Gnome2 but not 3. i feel Gnome 3 is terrible on my pc.

2012/5/15 Justin Wong justin.w...@gmail.com

独裁无胆，民主无量，打着为民着想的旗号强奸民意，一句资源有限就可以免于全部责任

去吧，发展葛弄姆特色的自由软件

Go on your work, hurt more fans and lose more users

sent from android
On May 15, 2012 7:28 AM, Owen Taylor otay...@redhat.com wrote:

In general, choice of input method framework is not a goal in itself.
If we choose a single input method framework to integrate with GNOME -
that doesn't make GNOME like proprietary software from Apple and
Microsoft,
because GNOME will still be 100% Free Software, and will still be
developed
in the open by the GNOME community.

GNOME isn't just a set of parts that a Linux distributor takes and uses
to create a working system - we also take responsibility for creating
a fully working system. This means deciding how GNOME interacts with
system components like sound and networking and printing and when
necessary
enhancing those components to provide the right experience to the user.

Of course, it would be a mistake to think that a small group of English
speaking developers could make GNOME work well in all these languages.
That
would be impossible! But from experience, we know that simply leaving a
problem like this to external developers and hoping for the best doesn't
work out well. Instead we need to engage users and developers from these
language communities into the GNOME development community.

We also need to keep in mind that we aren't talking about the choice of
input
method, we are talking about input method *frameworks*. The basics of
passing
events from application to daemon, loading different input method
backends,
handling hotkeys and displaying feedback are going to be very similar for
all East Asian languages.

Things like displaying feedback may be a little different if we move
further
afield to Thai or Hindi - but still, there is no fundamental reason that
they
need a different *framework*.

And in any case, as described above, there has to be *one* framework that
works as well as we can possibly make it for all users. Multiple partially
working

Re: Some points about IM integration

Imagine, just imagine one day a desktop environment named the Kernel
Desktop Environment (KDE), would be integrated to linux kernel for better
user experience. U guys argue for kernel should not integrate a DE, then
Linus Torvalds come out and say:

On May 15, 2012 7:28 AM, Owen Taylor otay...@redhat.com wrote:

 In general, choice of input method framework is not a goal in itself.
 If we choose a single input method framework to integrate with GNOME -
 that doesn't make GNOME like proprietary software from Apple and
Microsoft,
 because GNOME will still be 100% Free Software, and will still be
developed
 in the open by the GNOME community.


If we choose KDE as defualt and unchangable DE of linux, it doesn't make
linux like proprietary software from micro$oft, because linux will still be
100% free software, and will still be developed in the open by the linux
community.

 GNOME doesn't want to work well just for tweakers and enthusiasts - it's
 very important to the project that GNOME works well for all users without
 tweaking. We want to give the choice of using Free Software to
 everybody - this is a much more fundamental form of choice than giving a
small
 group of users the ability to swap out a different input method framework
 underneath GNOME.


Linux is not an OS for tweakers and enthusiastics, it's an OS for users, we
want to give the choice of using free software to everybodym this is much
more fundamental form of choice than giving a small groups of users the
ability to swap out a different DE underneath linux.

 GNOME isn't just a set of parts that a Linux distributor takes and uses
 to create a working system - we also take responsibility for creating
 a fully working system. This means deciding how GNOME interacts with
 system components like sound and networking and printing and when
necessary
 enhancing those components to provide the right experience to the user.


 So we can't leave it up to one Linux distributor to combine GNOME with
 fcitx to make a version of GNOME that works well for zh_CN and another
 Linux distributor to combine GNOME with RIME or hime to make a version
 of GNOME that works well for zh_TW. We want GNOME to, without
customization,
 work well for zh_CN, zh_TW, hi_IN, ru_RU, en_US, and so forth.


So we cannot leave it up to one linux distributor to combine linux with
gnome to make a linux distribution that works well for gtk softwares or
lxde to make it works well for lightweight lovers and so on...

Mac OS X and Windows both have *only one* DE in there OSs, and I'm happy
that Linux is catching on.

We are developing a Desktop *Enviroment*, users can still choose Dektop
Softwares to meet their needs, the point is , we should use *one single
enviroment* for better experience, better bug reports and so on.

The KDE team has been engaged to integrate with linux since linux 3.42,
because the lack of resource, we can not both integrate KDE and GNOME, we
cannot integrate 2 different Desktop *Environments*.

Because of your arguments, I think gnome users should not be ignored, so
which do u think is better and be qualified to integrate with linux kernel?
KDE or GNOME?

 Of course, it would be a mistake to think that a small group of English
 speaking developers could make GNOME work well in all these languages.
That
 would be impossible! But from experience, we know that simply leaving a
 problem like this to external developers and hoping for the best doesn't
 work out well. Instead we need to engage users and developers from these
 language communities into the GNOME development community.

 I don't want to minimize how easy that is - I know there are very
significant
 barriers of language, timezone, and distance that make this hard. I know
 that bugs get ignored and patches sit around unreviewed. But still,
 active engagement is the only way forward. I think it's absolutely
wonderful
 how many people have gotten involved in the current discussion!

 We also need to keep in mind that we aren't talking about the choice of
input
 method, we are talking about input method *frameworks*. The basics of
passing
 events from application to daemon, loading different input method
backends,
 handling hotkeys and displaying feedback are going to be very similar for
 all East Asian languages.

 Things like displaying feedback may be a little different if we move
further
 afield to Thai or Hindi - but still, there is no fundamental reason that
they
 need a different *framework*.

 Using a single input framework for all GNOME users has many benefits.
 GNOME developers can reproduce bugs that users run into. Bugs only have to
 be fixed once, not in multiple frameworks. We can actually figure out how
 to make input methods work with onscreen keyboards and accessibility. Our
 designers can collaborate on making the configuration dialogs conform to
 GNOME standards.

 Finally, using a single input method framework is pretty much essential to
 the goal of allowing users to configure

Re: Some points about IM integration

2012-05-15 Thread Yu Shao

I want to add more background on ibus as I watched Huang Peng developed 
it from scratch back to few years ago in Beijing.


One of the main ideas behind ibus was to implement The Specification of 
the IM engine Service Provider Interface which was jointly developed by 
CJK(China, Japan, Korea) IM developers/experts through Northeast Asia 
OSS Forum[1]. You might still find the specification online, otherwise I 
could help to find the doc and post it here. The specification itself 
was coming from about 2 years discussion among the best IM developers 
from China Japan and Korea at the time.


Ibus was firstly written in python initially as the proof of the concept 
of the CJK IM specification, later on rewritten in C to provide the 
necessary performance, mostly following the ideas from the 
specification. So, ibus had inherited all of the best practice coming 
from all CJK countries.


So, I am here want to purpose, it is probably a time for all of the 
input method developer to concentrate on a unified input method 
framework, CJK IM specification is a very good starting point, then 
let's focus more on the input engines(such as pinyin or wubi).


Shao

[1] http://www.neaossforum.org/

On 05/15/2012 07:27 AM, Owen Taylor wrote:

In general, choice of input method framework is not a goal in itself.
If we choose a single input method framework to integrate with GNOME -
that doesn't make GNOME like proprietary software from Apple and Microsoft,
because GNOME will still be 100% Free Software, and will still be developed
in the open by the GNOME community.

GNOME doesn't want to work well just for tweakers and enthusiasts - it's
very important to the project that GNOME works well for all users without
tweaking. We want to give the choice of using Free Software to
everybody - this is a much more fundamental form of choice than giving a small
group of users the ability to swap out a different input method framework
underneath GNOME.

GNOME isn't just a set of parts that a Linux distributor takes and uses
to create a working system - we also take responsibility for creating
a fully working system. This means deciding how GNOME interacts with
system components like sound and networking and printing and when necessary
enhancing those components to provide the right experience to the user.

So we can't leave it up to one Linux distributor to combine GNOME with
fcitx to make a version of GNOME that works well for zh_CN and another
Linux distributor to combine GNOME with RIME or hime to make a version
of GNOME that works well for zh_TW. We want GNOME to, without customization,
work well for zh_CN, zh_TW, hi_IN, ru_RU, en_US, and so forth.

Of course, it would be a mistake to think that a small group of English
speaking developers could make GNOME work well in all these languages. That
would be impossible! But from experience, we know that simply leaving a
problem like this to external developers and hoping for the best doesn't
work out well. Instead we need to engage users and developers from these
language communities into the GNOME development community.

I don't want to minimize how easy that is - I know there are very significant
barriers of language, timezone, and distance that make this hard. I know
that bugs get ignored and patches sit around unreviewed. But still,
active engagement is the only way forward. I think it's absolutely wonderful
how many people have gotten involved in the current discussion!

We also need to keep in mind that we aren't talking about the choice of input
method, we are talking about input method *frameworks*. The basics of passing
events from application to daemon, loading different input method backends,
handling hotkeys and displaying feedback are going to be very similar for
all East Asian languages.

Things like displaying feedback may be a little different if we move further
afield to Thai or Hindi - but still, there is no fundamental reason that they
need a different *framework*.

Using a single input framework for all GNOME users has many benefits.
GNOME developers can reproduce bugs that users run into. Bugs only have to
be fixed once, not in multiple frameworks. We can actually figure out how
to make input methods work with onscreen keyboards and accessibility. Our
designers can collaborate on making the configuration dialogs conform to
GNOME standards.

Finally, using a single input method framework is pretty much essential to
the goal of allowing users to configure languages at runtime with a nice user
interface. If language A and language B require different input method
*frameworks*, there is no way that the user can switch between them with a
hotkey.

In general, I don't see standardizing D-Bus interfaces so that GNOME can
work with multiple input method frameworks as being a useful activity.
If the D-Bus interfaces are carefully maintained and changed only with
agreement and advanced notice, then they will impede the progress of bug
fixing and making things better. If

Re: Some points about IM integration

On Wed, May 16, 2012 at 12:05 AM, Justin Wong justin.w...@gmail.com wrote:
 Imagine, just imagine one day a desktop environment named the Kernel Desktop
 Environment (KDE), would be integrated to linux kernel for better user
 experience. U guys argue for kernel should not integrate a DE, then Linus
 Torvalds come out and say:
 If we choose KDE as defualt and unchangable DE of linux, it doesn't make
 linux like proprietary software from micro$oft, because linux will still be
 100% free software, and will still be developed in the open by the linux
 community.
 Linux is not an OS for tweakers and enthusiastics, it's an OS for users, we
 want to give the choice of using free software to everybodym this is much
 more fundamental form of choice than giving a small groups of users the
 ability to swap out a different DE underneath linux.
 So we cannot leave it up to one linux distributor to combine linux with
 gnome to make a linux distribution that works well for gtk softwares or lxde
 to make it works well for lightweight lovers and so on...
 Mac OS X and Windows both have *only one* DE in there OSs, and I'm happy
 that Linux is catching on.
 We are developing a Desktop *Enviroment*, users can still choose Dektop
 Softwares to meet their needs, the point is , we should use *one single
 enviroment* for better experience, better bug reports and so on.
 The KDE team has been engaged to integrate with linux since linux 3.42,
 because the lack of resource, we can not both integrate KDE and GNOME, we
 cannot integrate 2 different Desktop *Environments*.
Sounds like ReactOS or Haiku?
http://www.reactos.org/
http://www.haiku-os.org/
Linux being the most flexible kernel doesn't imply that every FOSS
kernel should be that flexible. It's free software, you can always
switch or fork.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Tue, May 15, 2012 at 10:40:03AM +0800, Aron Xu wrote:
 Q: What are GNOME people doing?
 A: 1.Super-excellent ideas and design;
 2.Poor implementation;
 3.Working hard on fix-ups and finally it works;
 4.Immediately starting to re-invent wheels from Point 1.

Cool that you have that idea, but raising things like this is *not*
related at all to the subject. Either be specific, or don't post.

I have zero interest to see things about how GNOME might be viewed as
well as your thoughts on GNOME OS.

You mentioned not wanting to start a flame war. Please also don't start
one yourself.

-- 
Regards,
Olav (moderator)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Juanjo Marín



 De: Justin Wong justin.w...@gmail.com
CC: desktop-devel-list@gnome.org 
Enviado: Martes 15 de Mayo de 2012 18:05
Asunto: Re: Some points about IM integration
 

Imagine, just imagine one day a desktop environment named the Kernel Desktop 
Environment (KDE), would be integrated to linux kernel for better user 
experience. U guys argue for kernel should not integrate a DE, then Linus 
Torvalds come out and say:

On May 15, 2012 7:28 AM, Owen Taylor otay...@redhat.com wrote:

 In general, choice of input method framework is not a goal in itself.
 If we choose a single input method framework to integrate with GNOME -
 that doesn't make GNOME like proprietary software from Apple and Microsoft,
 because GNOME will still be 100% Free Software, and will still be developed
 in the open by the GNOME community.

If we choose KDE as defualt and unchangable DE of linux, it doesn't make linux 
like proprietary software from micro$oft, because linux will still be 100% 
free software, and will still be developed in the open by the linux community.





Please, keep the focus on the problem: Providing a good input method support in 
GNOME.
The election of a single IM framework, or not, is a matter of implementation, 
that users 

don't care as long as problem is solved and the solution can be maintained by 
the 

community.


Cheers,

 -- Juanjo Marin

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Wed, May 16, 2012 at 12:05:40AM +0800, Justin Wong wrote:
 If we choose KDE as defualt and unchangable DE of linux, it doesn't make
 linux like proprietary software from micro$oft, because linux will still be
 100% free software, and will still be developed in the open by the linux
 community.

This is completely offtopic. Please be specific in your argumentation.

The topic is how IM can be integrated.

-- 
Regards,
Olav (moderator)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Tue, May 15, 2012 at 11:04:06PM +0800, Xu Pengfei wrote:
 hi, guys
 
 I saw this bad news from
 http://linuxtoy.org/archives/gnome-and-cjk-community-debates-about-ibus-integration-of-gnome-3-6.html
 
 It's a chinese linux news blog, Do you know how to input those characters?
 I think the input is the most important things of a desktop.
 If i can't input,no mater how beautiful or powerful the desktop is, it is a
 rubbish.
 
 To the BOSS,
 
 If Mr. Linus said the kernel will only support KDE, and KDE will be the
 standard UI, what will you do?
 I don't care which one is the default IM, i just care about that i can
 choose the best one i like.
 
 BTW:I like Gnome2 but not 3. i feel Gnome 3 is terrible on my pc.

Hi,

Trolling is not acceptable. You've been banned.


-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

All what I want to say is gnome should NOT use one single IMF, just like
linux should NOT use only one DE !

There IS a solution to integrate multiple IMFs! And u just ignore ignore
and ignore this solution because of your laziness!

It's not the question which imf is better, it's the question u are doing a
abusolutely and completely WRONG thing!

No matter which imf you choose, fcitx or ibus, that means tens of
developers' work will be worth nonthing!

*STOP this WRONG work and prevent gnome from RETROGRESSING!!*

sent from android
On May 16, 2012 12:55 AM, Juanjo Marín juanjomari...@yahoo.es wrote:



  De: Justin Wong justin.w...@gmail.com
 CC: desktop-devel-list@gnome.org
 Enviado: Martes 15 de Mayo de 2012 18:05
 Asunto: Re: Some points about IM integration
 
 
 Imagine, just imagine one day a desktop environment named the Kernel
Desktop Environment (KDE), would be integrated to linux kernel for better
user experience. U guys argue for kernel should not integrate a DE, then
Linus Torvalds come out and say:
 
 On May 15, 2012 7:28 AM, Owen Taylor otay...@redhat.com wrote:
 
  In general, choice of input method framework is not a goal in itself.
  If we choose a single input method framework to integrate with GNOME -
  that doesn't make GNOME like proprietary software from Apple and
Microsoft,
  because GNOME will still be 100% Free Software, and will still be
developed
  in the open by the GNOME community.
 
 If we choose KDE as defualt and unchangable DE of linux, it doesn't make
linux like proprietary software from micro$oft, because linux will still be
100% free software, and will still be developed in the open by the linux
community.
 
 
 


 Please, keep the focus on the problem: Providing a good input method
support in GNOME.
 The election of a single IM framework, or not, is a matter of
implementation, that users

 don't care as long as problem is solved and the solution can be
maintained by the

 community.


 Cheers,

  -- Juanjo Marin

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Wed, May 16, 2012 at 1:05 AM, Justin Wong justin.w...@gmail.com wrote:
 All what I want to say is gnome should NOT use one single IMF, just like
 linux should NOT use only one DE !
False Analogy.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Tue, May 15, 2012 at 09:43:41PM +0800, Justin Wong wrote:
 独裁无胆，民主无量，打着为民着想的旗号强奸民意，一句资源有限就可以免于全部责任
 
 去吧，发展葛弄姆特色的自由软件
 
 Go on your work, hurt more fans and lose more users

Trolling is not acceptable. Disagree all you want but be specific. Else
I'll ban you.

-- 
Regards,
Olav (moderator)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Wed, May 16, 2012 at 01:05:46AM +0800, Justin Wong wrote:
 There IS a solution to integrate multiple IMFs! And u just ignore ignore
 and ignore this solution because of your laziness!

Your tone is not acceptable. Consider yourself banned.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Alan Cox

On Wed, 16 May 2012 00:05:40 +0800
Justin Wong justin.w...@gmail.com wrote:

 Imagine, just imagine one day a desktop environment named the Kernel
 Desktop Environment (KDE), would be integrated to linux kernel for better
 user experience.

We've got one .. it's called the console. It has an assorted set of
problems with Chinese fonts, and no input method support.

There is a difficult balance between integration and flexibility. DRI and
X is a good example of how tricky that can be.

Alan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Bastien Nocera

On Tue, 2012-05-15 at 17:55 +0800, Ma Xiaojun wrote:
 On Tue, May 15, 2012 at 5:45 PM, Vincent Untz vu...@gnome.org wrote:
  It would surely help to have some simple wiki page summarizing the
  current state of ibus and fctix, both as frameworks in general as well
  as for the availability and state of their plugins. People have been
  trying to tell the pros and cons of both in various mails, but I don't
  think anybody really managed to get a global view because of the number
  of mails.
 I cannot agree more.
 I just registered a Wikia page for you guys.
 http://cjkinput.wikia.com/wiki/CJK_Input_Wiki

For GNOME related wiki pages, it's better to use the Wiki at
http://live.gnome.org/

All the GNOME contributors have access to it, and it's better to
integrate it with other design pages.

Could you move the page you created to live.gnome.org? Post the name of
the page afterwards, and we'll make sure somebody puts it in the right
place.

Cheers

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Aron Xu

On Wed, May 16, 2012 at 12:54 AM, Olav Vitters o...@vitters.nl wrote:
 On Tue, May 15, 2012 at 10:40:03AM +0800, Aron Xu wrote:
 Q: What are GNOME people doing?
 A: 1.Super-excellent ideas and design;
 2.Poor implementation;
 3.Working hard on fix-ups and finally it works;
 4.Immediately starting to re-invent wheels from Point 1.

 Cool that you have that idea, but raising things like this is *not*
 related at all to the subject. Either be specific, or don't post.

 I have zero interest to see things about how GNOME might be viewed as
 well as your thoughts on GNOME OS.

 You mentioned not wanting to start a flame war. Please also don't start
 one yourself.


As you are one of the moderators, please don't try to blame someone
based on your very first impression, read the whole post and you'll
find whether it's related. What you have just quoted is rumor, but
it is something that happens right away as far as I can see for IMF
related issue here:

1.GNOME is trying to have IMF integration - cool stuff.
2.But it is warned by specialized people that the plan is broken - can
lead to poor implementation and breakage.
3.People insist on having it right now for 3.6 - then must work hard
on fix-ups in the future.
4.As said before, if IBus is getting replaced - then re-work the whole thing.

I sincerely would like to see both the thread and all the people calm
down and think more about it, then come around it some time later.

I believe everyone who would like to be involved in the implementation
wants to see something constructive, not tempered, not trollish, and
not rushing. Then I'd like to propose all the IBus related work in
wip/input-sources branch of the following components being suspended
at once:
  gnome-control-center
  gnome-shell
  gnome-settings-daemon
  gsettings-desktop-schemas
This feature should postponed at least for GNOME 3.6, even if we have
agreed on something, six months is too short for producing an almost
good release for users according to the current situation.

For future discussions, we will try to make GNOME developers
understand what input method really is and know about user's
requirements. Then we, including GNOME people, IBus developers and
Fcitx developers sit down together to figure out what's the right way
to do, as re-implementing things is painful at least for users, who
really suffer from the result.

--
Regards,
Aron Xu
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

Sorry for being mad, no offence to u.

First I would say I approve GNOME to integrate with an IMF, and even choose
one IMF as defualt.

BUT, IMF must be switchable.

As I have said for several times, provide a interface that IMFs can be well
integrated with GNOME.

There is a solution too satisfy multipul IMFs, but our points' are just
Ignored , even though Wen Xuetian has said he can prove it with code!

GNOME provide machanism, IMFs provide implementation.

It's not time to discuss WHICH IMF should be integrated, it's time to
discuss HOW IMF can be integrated.

I know it will not be a easy job, but it's something that should be done.

Whichever IMF u now choose as the only IMF for gnome, u are KILLING othe
IMFs, so do u think other IMFs' developers work worth nothing?

PLEASE, calm down, slow down, and discuss about how to provide a machanism,
and how IMFs can be integrated.

P.S. Ma said u can switch and fork, yes, surely I can do, but GNOME user
will suffer an dirty hacked input system, that's too selfish.

sent from android
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Jasper St. Pierre

Is there any reason that picking one input method framework is bad, if
we do it right? If the experience sucks and users have to switch to
another input method framework, yes, we've done it wrong, as Owen says
in the original email. But if it works pretty much out of the box for
all cases, what's wrong with tight integration?

We already have several hard requirements, out of practicality. GNOME
chose GTK+ as our main toolkit. GNOME chose PulseAudio as our main
sound server. We do this because we don't have the resources to
support Qt or EFL or Motif or Xaw. Nor do we have the resources to
support ESD or OSS.

I doubt we have the resources to support both IBus and FCITX, and
provide a good experience for both. Individual distributions may, but
that's their call, not GNOME's.

As for the prove it with code argument, it's not a data point until
it happens. When it happens, I may switch my opinion.

On Tue, May 15, 2012 at 2:41 PM, Justin Wong bigea...@xdlinux.info wrote:
 Sorry for being mad, no offence to u.

 First I would say I approve GNOME to integrate with an IMF, and even choose
 one IMF as defualt.

 BUT, IMF must be switchable.

 As I have said for several times, provide a interface that IMFs can be well
 integrated with GNOME.

 There is a solution too satisfy multipul IMFs, but our points' are just
 Ignored , even though Wen Xuetian has said he can prove it with code!

 GNOME provide machanism, IMFs provide implementation.

 It's not time to discuss WHICH IMF should be integrated, it's time to
 discuss HOW IMF can be integrated.

 I know it will not be a easy job, but it's something that should be done.

 Whichever IMF u now choose as the only IMF for gnome, u are KILLING othe
 IMFs, so do u think other IMFs' developers work worth nothing?

 PLEASE, calm down, slow down, and discuss about how to provide a machanism,
 and how IMFs can be integrated.

 P.S. Ma said u can switch and fork, yes, surely I can do, but GNOME user
 will suffer an dirty hacked input system, that's too selfish.

 sent from android


 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
  Jasper
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Wed, May 16, 2012 at 1:39 AM, Aron Xu aro...@gnome.org wrote:
 1.GNOME is trying to have IMF integration - cool stuff.
 2.But it is warned by specialized people that the plan is broken - can
 lead to poor implementation and breakage.
 3.People insist on having it right now for 3.6 - then must work hard
 on fix-ups in the future.
 4.As said before, if IBus is getting replaced - then re-work the whole thing.
Such bad cycle can happen in any software projects.

 I sincerely would like to see both the thread and all the people calm
 down and think more about it, then come around it some time later.
 I believe everyone who would like to be involved in the implementation
 wants to see something constructive, not tempered, not trollish, and
 not rushing. Then I'd like to propose all the IBus related work in
 wip/input-sources branch of the following components being suspended
 at once:
  gnome-control-center
  gnome-shell
  gnome-settings-daemon
  gsettings-desktop-schemas
 This feature should postponed at least for GNOME 3.6, even if we have
 agreed on something, six months is too short for producing an almost
 good release for users according to the current situation.
 For future discussions, we will try to make GNOME developers
 understand what input method really is and know about user's
 requirements. Then we, including GNOME people, IBus developers and
 Fcitx developers sit down together to figure out what's the right way
 to do, as re-implementing things is painful at least for users, who
 really suffer from the result.
Would the situation change if we suspend the work now?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Bastien Nocera

On Wed, 2012-05-16 at 01:41 +0800, Justin Wong wrote:
 Sorry for being mad, no offence to u.
 
 First I would say I approve GNOME to integrate with an IMF, and even
 choose one IMF as defualt.
 
 BUT, IMF must be switchable.

We already mentioned that we want the features to be in the engines from
each framework, if there needs to be multiple engines. Swappable IMFs
just means more unreproduceable bugs, more moving parts so more bugs in
general and a bad out-of-the-box experience.

 As I have said for several times, provide a interface that IMFs can be
 well integrated with GNOME.

Whether IMFs or something, you cannot add more options, have more moving
parts and have less bugs. In fact, you'd end up with the bugs from all
the IMFs.

 There is a solution too satisfy multipul IMFs, but our points' are
 just Ignored , even though Wen Xuetian has said he can prove it with
 code!

Your points aren't ignored. We already explained why we don't want
multiple IMFs for GNOME.

 GNOME provide machanism, IMFs provide implementation.
 
 It's not time to discuss WHICH IMF should be integrated, it's time to
 discuss HOW IMF can be integrated.
 
 I know it will not be a easy job, but it's something that should be
 done.
 
 Whichever IMF u now choose as the only IMF for gnome, u are KILLING
 othe IMFs, so do u think other IMFs' developers work worth nothing?

The other IMFs will likely continue to exist. They will require users to
make changes to their systems to use them (just like right now if you're
not using the default IMF for your distribution), and you won't have
integrated preferences (just like right now).

 PLEASE, calm down, slow down, and discuss about how to provide a
 machanism, and how IMFs can be integrated.

If we choose to merge integration based on IBus (because of a variety of
reasons), then two things can happen:
- Developers of other Input Frameworks can start creating patches to the
upstream GNOME to provide a better integration than the default choice.
- They choose to start working on the selected IMF because it's the
selected IMF
- They choose to concentrate on other desktops

In all cases, the implementation will evolve, and the integration will
get better. I don't want to have the choice between 2 equally badly
integrated IMFs for GNOME.

Cheers

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Wed, May 16, 2012 at 1:41 AM, Justin Wong bigea...@xdlinux.info wrote:
 There is a solution too satisfy multipul IMFs, but our points' are just
 Ignored , even though Wen Xuetian has said he can prove it with code!
Should be Weng Xuetian :)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Bastien Nocera

On Wed, 2012-05-16 at 01:39 +0800, Aron Xu wrote:
 On Wed, May 16, 2012 at 12:54 AM, Olav Vitters o...@vitters.nl wrote:
  On Tue, May 15, 2012 at 10:40:03AM +0800, Aron Xu wrote:
  Q: What are GNOME people doing?
  A: 1.Super-excellent ideas and design;
  2.Poor implementation;
  3.Working hard on fix-ups and finally it works;
  4.Immediately starting to re-invent wheels from Point 1.
 
  Cool that you have that idea, but raising things like this is *not*
  related at all to the subject. Either be specific, or don't post.
 
  I have zero interest to see things about how GNOME might be viewed as
  well as your thoughts on GNOME OS.
 
  You mentioned not wanting to start a flame war. Please also don't start
  one yourself.
 
 
 As you are one of the moderators, please don't try to blame someone
 based on your very first impression, read the whole post and you'll
 find whether it's related. What you have just quoted is rumor, but
 it is something that happens right away as far as I can see for IMF
 related issue here:
 
 1.GNOME is trying to have IMF integration - cool stuff.
 2.But it is warned by specialized people that the plan is broken - can
 lead to poor implementation and breakage.
 3.People insist on having it right now for 3.6 - then must work hard
 on fix-ups in the future.
 4.As said before, if IBus is getting replaced - then re-work the whole thing.

If IBus gets replaced, then it gets replaced. Code doesn't just
disappear and I'm pretty sure that code can be adapted rather than
completely trashed and having to restart from scratch.

 I sincerely would like to see both the thread and all the people calm
 down and think more about it, then come around it some time later.
 
 I believe everyone who would like to be involved in the implementation
 wants to see something constructive, not tempered, not trollish, and
 not rushing. Then I'd like to propose all the IBus related work in
 wip/input-sources branch of the following components being suspended
 at once:
   gnome-control-center
   gnome-shell
   gnome-settings-daemon
   gsettings-desktop-schemas

Why should the work be suspended? People are working on this, and
actually making progress. Where are the better implementations for
fcitx integration in GNOME? See below as well.

 This feature should postponed at least for GNOME 3.6, even if we have
 agreed on something, six months is too short for producing an almost
 good release for users according to the current situation.
 
 For future discussions, we will try to make GNOME developers
 understand what input method really is and know about user's
 requirements. Then we, including GNOME people, IBus developers and
 Fcitx developers sit down together to figure out what's the right way
 to do, as re-implementing things is painful at least for users, who
 really suffer from the result.

The only reason one would make noise in this thread would be if they
wanted to have either
1. fcitx integrated (rather than IBus)
or
2. thought that we should make Input Method frameworks swappable

2. isn't an option, as already discussed. For 1., we should in fact
merge the IBus support as soon as possible, and have fcitx developers
show us how they can do the integration better. A lot of the code should
be reusable, and you can show how much more awesome and complete your
favourite IMF is.

Cheers

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On May 16, 2012 2:08 AM, Bastien Nocera had...@hadess.net wrote:

 On Wed, 2012-05-16 at 01:41 +0800, Justin Wong wrote:
  Sorry for being mad, no offence to u.
 
  First I would say I approve GNOME to integrate with an IMF, and even
  choose one IMF as defualt.
 
  BUT, IMF must be switchable.

 We already mentioned that we want the features to be in the engines from
 each framework, if there needs to be multiple engines. Swappable IMFs
 just means more unreproduceable bugs, more moving parts so more bugs in
 general and a bad out-of-the-box experience.

  As I have said for several times, provide a interface that IMFs can be
  well integrated with GNOME.

 Whether IMFs or something, you cannot add more options, have more moving
 parts and have less bugs. In fact, you'd end up with the bugs from all
 the IMFs.

  There is a solution too satisfy multipul IMFs, but our points' are
  just Ignored , even though Wen Xuetian has said he can prove it with
  code!

 Your points aren't ignored. We already explained why we don't want
 multiple IMFs for GNOME.

  GNOME provide machanism, IMFs provide implementation.
 
  It's not time to discuss WHICH IMF should be integrated, it's time to
  discuss HOW IMF can be integrated.
 
  I know it will not be a easy job, but it's something that should be
  done.
 
  Whichever IMF u now choose as the only IMF for gnome, u are KILLING
  othe IMFs, so do u think other IMFs' developers work worth nothing?

 The other IMFs will likely continue to exist. They will require users to
 make changes to their systems to use them (just like right now if you're
 not using the default IMF for your distribution), and you won't have
 integrated preferences (just like right now).


That's what I mean switchable, but I really doubt that, if even clutter
has been integrated to one specific IMF.

  PLEASE, calm down, slow down, and discuss about how to provide a
  machanism, and how IMFs can be integrated.

 If we choose to merge integration based on IBus (because of a variety of
 reasons), then two things can happen:
 - Developers of other Input Frameworks can start creating patches to the
 upstream GNOME to provide a better integration than the default choice.
 - They choose to start working on the selected IMF because it's the
 selected IMF
 - They choose to concentrate on other desktops

 In all cases, the implementation will evolve, and the integration will
 get better. I don't want to have the choice between 2 equally badly
 integrated IMFs for GNOME.

 Cheers

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Aron Xu

On Wed, May 16, 2012 at 2:19 AM, Bastien Nocera had...@hadess.net wrote:
 On Wed, 2012-05-16 at 01:39 +0800, Aron Xu wrote:
 On Wed, May 16, 2012 at 12:54 AM, Olav Vitters o...@vitters.nl wrote:
  On Tue, May 15, 2012 at 10:40:03AM +0800, Aron Xu wrote:
  Q: What are GNOME people doing?
  A: 1.Super-excellent ideas and design;
  2.Poor implementation;
  3.Working hard on fix-ups and finally it works;
  4.Immediately starting to re-invent wheels from Point 1.
 
  Cool that you have that idea, but raising things like this is *not*
  related at all to the subject. Either be specific, or don't post.
 
  I have zero interest to see things about how GNOME might be viewed as
  well as your thoughts on GNOME OS.
 
  You mentioned not wanting to start a flame war. Please also don't start
  one yourself.
 

 As you are one of the moderators, please don't try to blame someone
 based on your very first impression, read the whole post and you'll
 find whether it's related. What you have just quoted is rumor, but
 it is something that happens right away as far as I can see for IMF
 related issue here:

 1.GNOME is trying to have IMF integration - cool stuff.
 2.But it is warned by specialized people that the plan is broken - can
 lead to poor implementation and breakage.
 3.People insist on having it right now for 3.6 - then must work hard
 on fix-ups in the future.
 4.As said before, if IBus is getting replaced - then re-work the whole thing.

 If IBus gets replaced, then it gets replaced. Code doesn't just
 disappear and I'm pretty sure that code can be adapted rather than
 completely trashed and having to restart from scratch.


This is not a strong claim because you even don't have the basic ideas
about input methods right now, which is the reason for why I want all
the work get suspended at once.

 I sincerely would like to see both the thread and all the people calm
 down and think more about it, then come around it some time later.

 I believe everyone who would like to be involved in the implementation
 wants to see something constructive, not tempered, not trollish, and
 not rushing. Then I'd like to propose all the IBus related work in
 wip/input-sources branch of the following components being suspended
 at once:
   gnome-control-center
   gnome-shell
   gnome-settings-daemon
   gsettings-desktop-schemas

 Why should the work be suspended? People are working on this, and
 actually making progress. Where are the better implementations for
 fcitx integration in GNOME? See below as well.


Actually current experience with Fcitx's kimpanel plugin for
gnome-shell is much better than IBus already, the progress in those
branches are re-inventing things in IBus to catch up with Fcitx in the
first place.

 This feature should postponed at least for GNOME 3.6, even if we have
 agreed on something, six months is too short for producing an almost
 good release for users according to the current situation.

 For future discussions, we will try to make GNOME developers
 understand what input method really is and know about user's
 requirements. Then we, including GNOME people, IBus developers and
 Fcitx developers sit down together to figure out what's the right way
 to do, as re-implementing things is painful at least for users, who
 really suffer from the result.

 The only reason one would make noise in this thread would be if they
 wanted to have either
 1. fcitx integrated (rather than IBus)
 or
 2. thought that we should make Input Method frameworks swappable


This is not true. The valid one should be something like the following points:

1.We want to have better input experience for input method users of
GNOME, as the already integrated XKB stuff.

2.Forcibly choose between IBus and Fcitx is not a good idea because
most people around still doesn't have the concept of what is IMF and
why foo can be better than bar.

3.Whether it will be a hard dependency is subject to discussion among
related developers, and it is very likely to be not necessary if you
understand the current design of Fcitx.

4.If it is feasible to not hardcode, why do that? Having a recommended
implementation in GNOME is something good, but only hardcode when
necessary and being agreed by related people.

5.GNOME need listen to CJK developers before trying to assume things on IMF.

 2. isn't an option, as already discussed. For 1., we should in fact
 merge the IBus support as soon as possible, and have fcitx developers
 show us how they can do the integration better. A lot of the code should
 be reusable, and you can show how much more awesome and complete your
 favourite IMF is.

 Cheers


See above. It isn't something absolute, so please suspend right now,
listen and discuss first.

--
Regards,
Aron Xu
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Weng Xuetian

On Wed, May 16, 2012 at 2:19 AM, Bastien Nocera had...@hadess.net wrote:
 On Wed, 2012-05-16 at 01:39 +0800, Aron Xu wrote:
 On Wed, May 16, 2012 at 12:54 AM, Olav Vitters o...@vitters.nl wrote:
  On Tue, May 15, 2012 at 10:40:03AM +0800, Aron Xu wrote:
  Q: What are GNOME people doing?
  A: 1.Super-excellent ideas and design;
  2.Poor implementation;
  3.Working hard on fix-ups and finally it works;
  4.Immediately starting to re-invent wheels from Point 1.
 
  Cool that you have that idea, but raising things like this is *not*
  related at all to the subject. Either be specific, or don't post.
 
  I have zero interest to see things about how GNOME might be viewed as
  well as your thoughts on GNOME OS.
 
  You mentioned not wanting to start a flame war. Please also don't start
  one yourself.
 

 As you are one of the moderators, please don't try to blame someone
 based on your very first impression, read the whole post and you'll
 find whether it's related. What you have just quoted is rumor, but
 it is something that happens right away as far as I can see for IMF
 related issue here:

 1.GNOME is trying to have IMF integration - cool stuff.
 2.But it is warned by specialized people that the plan is broken - can
 lead to poor implementation and breakage.
 3.People insist on having it right now for 3.6 - then must work hard
 on fix-ups in the future.
 4.As said before, if IBus is getting replaced - then re-work the whole thing.

 If IBus gets replaced, then it gets replaced. Code doesn't just
 disappear and I'm pretty sure that code can be adapted rather than
 completely trashed and having to restart from scratch.

 I sincerely would like to see both the thread and all the people calm
 down and think more about it, then come around it some time later.

 I believe everyone who would like to be involved in the implementation
 wants to see something constructive, not tempered, not trollish, and
 not rushing. Then I'd like to propose all the IBus related work in
 wip/input-sources branch of the following components being suspended
 at once:
   gnome-control-center
   gnome-shell
   gnome-settings-daemon
   gsettings-desktop-schemas

 Why should the work be suspended? People are working on this, and
 actually making progress. Where are the better implementations for
 fcitx integration in GNOME? See below as well.

 This feature should postponed at least for GNOME 3.6, even if we have
 agreed on something, six months is too short for producing an almost
 good release for users according to the current situation.

 For future discussions, we will try to make GNOME developers
 understand what input method really is and know about user's
 requirements. Then we, including GNOME people, IBus developers and
 Fcitx developers sit down together to figure out what's the right way
 to do, as re-implementing things is painful at least for users, who
 really suffer from the result.

 The only reason one would make noise in this thread would be if they
 wanted to have either
 1. fcitx integrated (rather than IBus)
 or
 2. thought that we should make Input Method frameworks swappable

 2. isn't an option, as already discussed. For 1., we should in fact
 merge the IBus support as soon as possible, and have fcitx developers
 show us how they can do the integration better. A lot of the code should
 be reusable, and you can show how much more awesome and complete your
 favourite IMF is.


Actually I don't quite favor continue this discussion, part of my
object is actually accomplished.
Thank for your guys support, though some of speech is not quite acceptable.

As being developer one of my point is to provide better experience for
user, this has never conflicted with Gnome nor IBus. And actually I
really prefer the way to talk with what we have done, but not we
will done.

Understood other project requirement is also important for me.

For hackers like me, they will always be way :).

Actually I'd say, to others, even if, even if only ibus available
gnome, and I can still make my way for fcitx in gnome.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

Hi, all.

I've started the documentation process of CJK Input.
https://live.gnome.org/InputCJK

It just contains trivial information currently. But I will add content
from time to time.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Aron Xu

On Wed, May 16, 2012 at 3:20 AM, Ma Xiaojun damage3...@gmail.com wrote:
 Hi, all.

 I've started the documentation process of CJK Input.
 https://live.gnome.org/InputCJK

 It just contains trivial information currently. But I will add content
 from time to time.

Looks great, thanks for bringing us a good start!

--
Regards,
Aron Xu
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Jasper St. Pierre

On Tue, May 15, 2012 at 4:20 PM, Ma Xiaojun damage3...@gmail.com wrote:
 Hi, all.

 I've started the documentation process of CJK Input.
 https://live.gnome.org/InputCJK

Thanks, this looks like a good start!

 It just contains trivial information currently. But I will add content
 from time to time.
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list

-- 
  Jasper
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Rovanion Luckey

Greetings all,

This fall I and three other students did an accessibility study in which
Dasher was a part. One of the issues we encountered was that the user after
having typed it's sentence or any other text into Dasher had to copy and
paste it into the application they were actually using. And if they later
discovered an issue in the text they'd have to copy it back to Dasher, edit
it and then copy and paste it to the application again.

If this hasn't changed since then and without having any knowledge of the
input management code or the Dasher code I would like to ask a question:
Wouldn't it be great to have Dasher appear when a text field is activated
in Gnome much like it does on Android[1]?

The Input Manager is called when the text area is activated. It then puts
characters in the field. This has been a great success on Android with the
most popular keyboard in the store being installed on about 100.000
devices. Couldn't something of the sorts be done in Gnome for on screen
keyboards, accessibility tools and other input managers like the one
discussed in this thread? They all seem to do the same thing, just in
different ways.

Now forgive me if these topics aren't related and thank you for your time.

[1]http://i.imgur.com/LAY1s.png
-- 
www.twitter.com/Rovanion
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

民主无量，独裁无胆
一句 资源有限 就试图为自己托则，简直就是共产党

Go on your work, ignore and lose more users!

sent from android
On May 15, 2012 7:28 AM, Owen Taylor otay...@redhat.com wrote:

 In general, choice of input method framework is not a goal in itself.
 If we choose a single input method framework to integrate with GNOME -
 that doesn't make GNOME like proprietary software from Apple and Microsoft,
 because GNOME will still be 100% Free Software, and will still be developed
 in the open by the GNOME community.

 GNOME doesn't want to work well just for tweakers and enthusiasts - it's
 very important to the project that GNOME works well for all users without
 tweaking. We want to give the choice of using Free Software to
 everybody - this is a much more fundamental form of choice than giving a
 small
 group of users the ability to swap out a different input method framework
 underneath GNOME.

 GNOME isn't just a set of parts that a Linux distributor takes and uses
 to create a working system - we also take responsibility for creating
 a fully working system. This means deciding how GNOME interacts with
 system components like sound and networking and printing and when necessary
 enhancing those components to provide the right experience to the user.

 So we can't leave it up to one Linux distributor to combine GNOME with
 fcitx to make a version of GNOME that works well for zh_CN and another
 Linux distributor to combine GNOME with RIME or hime to make a version
 of GNOME that works well for zh_TW. We want GNOME to, without
 customization,
 work well for zh_CN, zh_TW, hi_IN, ru_RU, en_US, and so forth.

 Of course, it would be a mistake to think that a small group of English
 speaking developers could make GNOME work well in all these languages. That
 would be impossible! But from experience, we know that simply leaving a
 problem like this to external developers and hoping for the best doesn't
 work out well. Instead we need to engage users and developers from these
 language communities into the GNOME development community.

 I don't want to minimize how easy that is - I know there are very
 significant
 barriers of language, timezone, and distance that make this hard. I know
 that bugs get ignored and patches sit around unreviewed. But still,
 active engagement is the only way forward. I think it's absolutely
 wonderful
 how many people have gotten involved in the current discussion!

 We also need to keep in mind that we aren't talking about the choice of
 input
 method, we are talking about input method *frameworks*. The basics of
 passing
 events from application to daemon, loading different input method backends,
 handling hotkeys and displaying feedback are going to be very similar for
 all East Asian languages.

 Things like displaying feedback may be a little different if we move
 further
 afield to Thai or Hindi - but still, there is no fundamental reason that
 they
 need a different *framework*.

 Using a single input framework for all GNOME users has many benefits.
 GNOME developers can reproduce bugs that users run into. Bugs only have to
 be fixed once, not in multiple frameworks. We can actually figure out how
 to make input methods work with onscreen keyboards and accessibility. Our
 designers can collaborate on making the configuration dialogs conform to
 GNOME standards.

 Finally, using a single input method framework is pretty much essential to
 the goal of allowing users to configure languages at runtime with a nice
 user
 interface. If language A and language B require different input method
 *frameworks*, there is no way that the user can switch between them with a
 hotkey.

 In general, I don't see standardizing D-Bus interfaces so that GNOME can
 work with multiple input method frameworks as being a useful activity.
 If the D-Bus interfaces are carefully maintained and changed only with
 agreement and advanced notice, then they will impede the progress of bug
 fixing and making things better. If the interfaces are not carefully
 maintained, then they aren't standards at all, and users will constantly
 encounter breakage.

 And in any case, as described above, there has to be *one* framework that
 works as well as we can possibly make it for all users. Multiple partially
 working frameworks are not a substitute.

 All of the above is an argument only for picking a single input method
 framework. It doesn't say anything about what input method framework we
 should pick. The fact that the IBus developers have been engaged with
 GNOME for quite some time and are willing to work with us to create a user
 experience that is simple and consistent with the GNOME principles is
 certainly a big plus, but we do need to make sure that the end result
 works well as well as looking good.

 - Owen


 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

Sorry for being mad, no offence to u.

As I have said for sevral times, provide a interface that IMFs can be well
integrated with GNOME

but our points' are just ignored , even though Wen Xuetian has said he can
prove it with code!  ( even code cannot convince u, i am disappointed)

GNOME provide machanism, IMFs provide implementation, that's my point.

I know it will not be a easy job, but it's something that should be done.

Whichever IMF u now choose as the only IMF for gnome, u are KILLING othe
IMFs, so do u think other IMFs' developers work worth nothing?

PLEASE, calm down, slow down, and discuss about how to provide a machanism,
and how IMFs can be integrated.

sent from android
On May 16, 2012 12:58 AM, Olav Vitters o...@vitters.nl wrote:
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

Sorry for being mad, no offence to u.

As I have said for sevral times, provide a interface that IMFs can be well
integrated with GNOME, but our points' are just
Ignored by u, even though Wen Xuetian has said he can prove it with code!

GNOME provide machanism, IMFs provide implementation.

I know it will not be a easy job, but it's something that should be done.

Whichever IMF u now choose as the only IMF for gnome, u are KILLING othe
IMFs, so do u think other IMFs' developers work worth nothing?

PLEASE, calm down, slow down, and discuss about how to provide a machanism,
and how IMFs can be integrated.

sent from android
On May 16, 2012 12:58 AM, Olav Vitters o...@vitters.nl wrote:

 On Wed, May 16, 2012 at 12:05:40AM +0800, Justin Wong wrote:
  If we choose KDE as defualt and unchangable DE of linux, it doesn't make
  linux like proprietary software from micro$oft, because linux will still
 be
  100% free software, and will still be developed in the open by the linux
  community.

 This is completely offtopic. Please be specific in your argumentation.

 The topic is how IM can be integrated.

 --
 Regards,
 Olav (moderator)
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

Sorry for being mad, no offence to u.

First I would say I approve  GNOME to integrate with an IMF, and even
choose one IMF as defualt.

BUT, IMF must be switchable.

As I have said for several times, provide a interface that IMFs can be well
integrated with GNOME.

There is a solution too satisfy multipul IMFs,  but our points' are just
Ignored , even though Wen Xuetian has said he can prove it with code!

GNOME provide machanism, IMFs provide implementation.

It's not time to discuss WHICH IMF should be integrated, it's time to
discuss HOW IMF can be integrated.

I know it will not be a easy job, but it's something that should be done.

Whichever IMF u now choose as the only IMF for gnome, u are KILLING othe
IMFs, so do u think other IMFs' developers work worth nothing?

PLEASE, calm down, slow down, and discuss about how to provide a machanism,
and how IMFs can be integrated.

P.S.   Ma said u can switch and fork, yes, surely I can do,  but GNOME
user will suffer an dirty hacked input system, that's too selfish.
On May 16, 2012 12:58 AM, Olav Vitters o...@vitters.nl wrote:

 On Wed, May 16, 2012 at 12:05:40AM +0800, Justin Wong wrote:
  If we choose KDE as defualt and unchangable DE of linux, it doesn't make
  linux like proprietary software from micro$oft, because linux will still
 be
  100% free software, and will still be developed in the open by the linux
  community.

 This is completely offtopic. Please be specific in your argumentation.

 The topic is how IM can be integrated.

 --
 Regards,
 Olav (moderator)
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Nguyen Thai Ngoc Duy

On Wed, May 16, 2012 at 12:53 AM, Jasper St. Pierre
jstpie...@mecheye.net wrote:
 Is there any reason that picking one input method framework is bad, if
 we do it right? If the experience sucks and users have to switch to
 another input method framework, yes, we've done it wrong, as Owen says
 in the original email. But if it works pretty much out of the box for
 all cases, what's wrong with tight integration?

There is resistance to changes after some support is in. Someone
already mentioned the power off button case, which took several cycles
to finally get fixed. I _think_ designers/developers moved their focus
to other stuff because it sort of works already.

So if there are strong opposing opinions from the beginning. I'd
rather see the discussion settled down than just go with one and see
what (likely never) happens next.

 We already have several hard requirements, out of practicality. GNOME
 chose GTK+ as our main toolkit. GNOME chose PulseAudio as our main
 sound server. We do this because we don't have the resources to
 support Qt or EFL or Motif or Xaw. Nor do we have the resources to
 support ESD or OSS.

 I doubt we have the resources to support both IBus and FCITX, and
 provide a good experience for both. Individual distributions may, but
 that's their call, not GNOME's.

 As for the prove it with code argument, it's not a data point until
 it happens. When it happens, I may switch my opinion.

-- 
Duy
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Takao Fujiwara


(05/15/12 19:13), Marguerite Su-san wrote:

I at first thought GNOME is planning to grab free options from users
and distros.

like we openSUSE choose fcitx as default IM, but we can do nothing on
IBUS then. then we won't choose fcitx any more. because we don't like
to act fool. the we have no freedom to choose our distros default IM.

but apparently not.

I got promise from Takao.


Hmm.., probably it's not accurate.
I explained my current patch and confirmed if it can resolve your concerns but 
don't promise anything. I think the design would be decided by GNOME.

fujiwara
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Tue, May 15, 2012 at 7:27 AM, Owen Taylor otay...@redhat.com wrote:
 In general, choice of input method framework is not a goal in itself.
 If we choose a single input method framework to integrate with GNOME -
 that doesn't make GNOME like proprietary software from Apple and Microsoft,
 because GNOME will still be 100% Free Software, and will still be developed
 in the open by the GNOME community.

 GNOME doesn't want to work well just for tweakers and enthusiasts - it's
 very important to the project that GNOME works well for all users without
 tweaking. We want to give the choice of using Free Software to
 everybody - this is a much more fundamental form of choice than giving a small
 group of users the ability to swap out a different input method framework
 underneath GNOME.

 GNOME isn't just a set of parts that a Linux distributor takes and uses
 to create a working system - we also take responsibility for creating
 a fully working system. This means deciding how GNOME interacts with
 system components like sound and networking and printing and when necessary
 enhancing those components to provide the right experience to the user.

 So we can't leave it up to one Linux distributor to combine GNOME with
 fcitx to make a version of GNOME that works well for zh_CN and another
 Linux distributor to combine GNOME with RIME or hime to make a version
 of GNOME that works well for zh_TW. We want GNOME to, without customization,
 work well for zh_CN, zh_TW, hi_IN, ru_RU, en_US, and so forth.

 Of course, it would be a mistake to think that a small group of English
 speaking developers could make GNOME work well in all these languages. That
 would be impossible! But from experience, we know that simply leaving a
 problem like this to external developers and hoping for the best doesn't
 work out well. Instead we need to engage users and developers from these
 language communities into the GNOME development community.

 I don't want to minimize how easy that is - I know there are very significant
 barriers of language, timezone, and distance that make this hard. I know
 that bugs get ignored and patches sit around unreviewed. But still,
 active engagement is the only way forward. I think it's absolutely wonderful
 how many people have gotten involved in the current discussion!

 We also need to keep in mind that we aren't talking about the choice of input
 method, we are talking about input method *frameworks*. The basics of passing
 events from application to daemon, loading different input method backends,
 handling hotkeys and displaying feedback are going to be very similar for
 all East Asian languages.

 Things like displaying feedback may be a little different if we move further
 afield to Thai or Hindi - but still, there is no fundamental reason that they
 need a different *framework*.

 Using a single input framework for all GNOME users has many benefits.
 GNOME developers can reproduce bugs that users run into. Bugs only have to
 be fixed once, not in multiple frameworks. We can actually figure out how
 to make input methods work with onscreen keyboards and accessibility. Our
 designers can collaborate on making the configuration dialogs conform to
 GNOME standards.

 Finally, using a single input method framework is pretty much essential to
 the goal of allowing users to configure languages at runtime with a nice user
 interface. If language A and language B require different input method
 *frameworks*, there is no way that the user can switch between them with a
 hotkey.

 In general, I don't see standardizing D-Bus interfaces so that GNOME can
 work with multiple input method frameworks as being a useful activity.
 If the D-Bus interfaces are carefully maintained and changed only with
 agreement and advanced notice, then they will impede the progress of bug
 fixing and making things better. If the interfaces are not carefully
 maintained, then they aren't standards at all, and users will constantly
 encounter breakage.

 And in any case, as described above, there has to be *one* framework that
 works as well as we can possibly make it for all users. Multiple partially
 working frameworks are not a substitute.

 All of the above is an argument only for picking a single input method
 framework. It doesn't say anything about what input method framework we
 should pick. The fact that the IBus developers have been engaged with
 GNOME for quite some time and are willing to work with us to create a user
 experience that is simple and consistent with the GNOME principles is
 certainly a big plus, but we do need to make sure that the end result
 works well as well as looking good.


First let me clarify a question though nobody ask, but I think you
have this question in mind. That is why not fcitx work with ibus,
isn't that a feasible solution too?.

It's kinds of the same question why there are so many distribution for
linux? There is some reason important that make two similar projects
are not the same

Re: Some points about IM integration

2012-05-14 Thread Aron Xu

Hi Owen,

I'm sorry to see that you are trying to drag us back to discuss about
which IMF is better, which is very likely to start a flame war on
the list.

Please excuse me if some of my replies are _tooo_ direct and
_seems_ to be unfriendly, the idea behind is that I *sincerely* wish
to lead both sides to a happy result.

On Tue, May 15, 2012 at 7:27 AM, Owen Taylor otay...@redhat.com wrote:
 In general, choice of input method framework is not a goal in itself.
 If we choose a single input method framework to integrate with GNOME -
 that doesn't make GNOME like proprietary software from Apple and Microsoft,
 because GNOME will still be 100% Free Software, and will still be developed
 in the open by the GNOME community.


No. Given no choice is something wrong. GNOME3 is advertised to be
design driven, but have you heard about some rumors like this one:

Q: What are GNOME people doing?
A: 1.Super-excellent ideas and design;
2.Poor implementation;
3.Working hard on fix-ups and finally it works;
4.Immediately starting to re-invent wheels from Point 1.

So, let's concentrate on the integration of IMF, and surely yes, we
all know that integration can possibly bring users a better
experience. But this will work if and *only* if we don't push people
very hard to work in a way they don't think feasible. Given that GNOME
cannot reinvent another IMF definitely, and given that GNOME is
lacking specialized people on this particular item, please at least
follow their advice and don't try to push them to fit schedule.

Just emphasizing the good side of doing such will very probably bring
a half-baked broken system to users. And I want to emphasize again
that IMF is very important to their users, much more important than
any other visible components including but not limited to music
players, editors, etc. Because when the input system isn't working
well or become confusing, the user is forced to stop using the whole
environment or he/she cannot be producible. Think about your keyboard
is not working properly and you are stopped away from inputting
anything to Web, Gedit and any other applications, can you continue
your work with it?

So _don't be hurry_, _don't rush_. Let's sit down for a cup of tea and
plan it _much more carefully_.

 GNOME doesn't want to work well just for tweakers and enthusiasts - it's
 very important to the project that GNOME works well for all users without
 tweaking. We want to give the choice of using Free Software to
 everybody - this is a much more fundamental form of choice than giving a small
 group of users the ability to swap out a different input method framework
 underneath GNOME.


Distributions are already trying their best to cook out the best
recipe for their target users, and all of these efforts are based on
the fact that the software they use is an open system with a free
license.

But GNOME is on its way of being a closed system, though it comes with
a free and open source license, it has been actively taking away users
and developers' choices in the _name_ of experience. What free
software users are expecting is an open system with a free license,
and I doubt what's for a closed system with a free license. Is this
like using free software to build an DRM enabled system? Anyway users
are not able to change the presets anymore because they are
deliberately made to be deep dependency, in the name of we can only
concentrate on foo, so bar is totally ignored, use foo or go away.

 GNOME isn't just a set of parts that a Linux distributor takes and uses
 to create a working system - we also take responsibility for creating
 a fully working system. This means deciding how GNOME interacts with
 system components like sound and networking and printing and when necessary
 enhancing those components to provide the right experience to the user.


Then please raise the proposal about GNOME OS again, so all others can
stop making GNOME based distributions because all others are just
making a working system but GNOME OS will possibly be a fully
working one. The difference in the given wording is obvious, I think.

 So we can't leave it up to one Linux distributor to combine GNOME with
 fcitx to make a version of GNOME that works well for zh_CN and another
 Linux distributor to combine GNOME with RIME or hime to make a version
 of GNOME that works well for zh_TW. We want GNOME to, without customization,
 work well for zh_CN, zh_TW, hi_IN, ru_RU, en_US, and so forth.


Why GNOME can't? Why just stop other distributions to make a best
recipe for their users? This means all GNOME users and distributors
must accept ALL or NOTHING. This reminds something that truly bad in
our mind, and think about who is pushing such changes.

Just _thinking_ something is good is not the right approach, because
GNOME is not a lord project that everyone must follow. Users of these
languages are using all the different input method frameworks and
engines for years, and GNOME is not able to change the fact

Re: Some points about IM integration

2012-05-14 Thread Owen Taylor

On Tue, 2012-05-15 at 10:12 +0800, Weng Xuetian wrote:

  All of the above is an argument only for picking a single input method
  framework. It doesn't say anything about what input method framework we
  should pick. The fact that the IBus developers have been engaged with
  GNOME for quite some time and are willing to work with us to create a user
  experience that is simple and consistent with the GNOME principles is
  certainly a big plus, but we do need to make sure that the end result
  works well as well as looking good.
 
 
 First let me clarify a question though nobody ask, but I think you
 have this question in mind. That is why not fcitx work with ibus,
 isn't that a feasible solution too?.

 It's kinds of the same question why there are so many distribution for
 linux? There is some reason important that make two similar projects
 are not the same projects. Though from some other people point of
 view, they don't understand or don't know the  reason. To make it
 simple, the reason that it's impossible for ibus to implement the
 feature I want in input method.

I think it's quite interesting to learn about the differences in
philosophy and the differences in technical decisions between projects.

But certainly suggesting that people stop working on their projects
or merge efforts is generally not reasonable. (We've all heard plenty
of people saying Wouldn't it be great if GNOME and KDE merged over
the years...)

Once projects have been around for a while they have their own
philosophies, their own users, their own history. So I'm not expecting
anybody to give up work on their own projects.

But that doesn't mean that we can simply be neutral, work with all
projects equally. I think the end result of that is poor integration,
poor user interfaces, and unhappy users.

[]

 And for example, the keyboard layout integration, settings is actually
 duplicated there and within ibus, and the UI even not cover all
 available option inside.ibus. My point is, why not let input method
 guys to implements theirs own gnome-control-center module? This should
 be the right way to go. And much more easier and decouple with GNOME
 core, and will works even better. What you guys choose now even limits
 ibus itself from my view.

For the GNOME philosophy on configuration, see the section called
The Question of Preferences in:

 http://ometer.com/free-software-ui.html
 
In general, we wouldn't believe that giving the user more options is
necessarily better. Even as something as basic as the list of
possible input methods is something that we think needs careful thought
and planning. When I look at the screenshot at:

 http://fcitx-im.org/wiki/File:Fcitx-configtool.png

I would certainly wonder if including a Dvorak layout for Cameroon makes
sense. (The equivalent part of the UI we're working on can be found
https://live.gnome.org/Design/SystemSettings/RegionAndLanguage - 
under Input Sources, but I'm not sure if there are more current or
more extensive designs elsewhere)

 And from my point of view, setting interface of ibus is hardcoded, so
 those pygtk setting code must be replace one by one if they want to
 move to another toolkit (even from gtk2 to gtk3). And make it
 impossible to put the setting just inside the gnome-control-center.

Are you saying that fcitx generates the configuration GUI based on
a description? In general, our experience has definitely been over the
years that auto-generated configuration have some downsides. They
don't allow customized design of controls for particular options, and
don't handle the interaction between interacting options well.

I don't want people to draw the conclusion that because I'm saying that
input methods should have simple configuration without a lot of options,
I think that they aren't important. I'm very aware that every single
user that comes to GNOME and wants to write in Chinese needs to use an
input method. But if we have so many options that the defaults don't get
well tested, or if options conflict and produce bugs, then we're not
shipping a good ';';'''
'


- Owen


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-14 Thread Jasper St. Pierre

On Mon, May 14, 2012 at 11:39 PM, Owen Taylor otay...@redhat.com wrote:
 But if we have so many options that the defaults don't get
 well tested, or if options conflict and produce bugs, then we're not
 shipping a good ';';'''
 '

I'm hoping this is a clever joke involving buggy input methods rather
than your cat hitting Send accidentally.

 - Owen


 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list

-- 
  Jasper
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-14 Thread Owen Taylor

On Mon, 2012-05-14 at 23:39 -0400, Owen Taylor wrote:

 I don't want people to draw the conclusion that because I'm saying that
 input methods should have simple configuration without a lot of options,
 I think that they aren't important. I'm very aware that every single
 user that comes to GNOME and wants to write in Chinese needs to use an
 input method. But if we have so many options that the defaults don't get
 well tested, or if options conflict and produce bugs, then we're not
 shipping a good ';';'''

[ I'm sorry - had an input problem here - but attributable to a crumb in
  my keyboard rather than anything to do with input methods:-) ]

then we're not shipping a good product. The configuration should be as
complex as it needs to be but no more.

I don't think there are easy answers, because there are a lot of people
out there who really want to make input work well and work well with
GNOME. So, mostly what I can do here is try to explain a bit about
the way we usually think about things in GNOME and what we consider
successful UI.

- Owen


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Tue, May 15, 2012 at 11:39 AM, Owen Taylor otay...@redhat.com wrote:
 On Tue, 2012-05-15 at 10:12 +0800, Weng Xuetian wrote:

  All of the above is an argument only for picking a single input method
  framework. It doesn't say anything about what input method framework we
  should pick. The fact that the IBus developers have been engaged with
  GNOME for quite some time and are willing to work with us to create a user
  experience that is simple and consistent with the GNOME principles is
  certainly a big plus, but we do need to make sure that the end result
  works well as well as looking good.
 

 First let me clarify a question though nobody ask, but I think you
 have this question in mind. That is why not fcitx work with ibus,
 isn't that a feasible solution too?.

 It's kinds of the same question why there are so many distribution for
 linux? There is some reason important that make two similar projects
 are not the same projects. Though from some other people point of
 view, they don't understand or don't know the  reason. To make it
 simple, the reason that it's impossible for ibus to implement the
 feature I want in input method.

 I think it's quite interesting to learn about the differences in
 philosophy and the differences in technical decisions between projects.

 But certainly suggesting that people stop working on their projects
 or merge efforts is generally not reasonable. (We've all heard plenty
 of people saying Wouldn't it be great if GNOME and KDE merged over
 the years...)

 Once projects have been around for a while they have their own
 philosophies, their own users, their own history. So I'm not expecting
 anybody to give up work on their own projects.

 But that doesn't mean that we can simply be neutral, work with all
 projects equally. I think the end result of that is poor integration,
 poor user interfaces, and unhappy users.

 []

 And for example, the keyboard layout integration, settings is actually
 duplicated there and within ibus, and the UI even not cover all
 available option inside.ibus. My point is, why not let input method
 guys to implements theirs own gnome-control-center module? This should
 be the right way to go. And much more easier and decouple with GNOME
 core, and will works even better. What you guys choose now even limits
 ibus itself from my view.

 For the GNOME philosophy on configuration, see the section called
 The Question of Preferences in:

  http://ometer.com/free-software-ui.html

 In general, we wouldn't believe that giving the user more options is
 necessarily better. Even as something as basic as the list of
 possible input methods is something that we think needs careful thought
 and planning. When I look at the screenshot at:

  http://fcitx-im.org/wiki/File:Fcitx-configtool.png

 I would certainly wonder if including a Dvorak layout for Cameroon makes
 sense. (The equivalent part of the UI we're working on can be found
 https://live.gnome.org/Design/SystemSettings/RegionAndLanguage -
 under Input Sources, but I'm not sure if there are more current or
 more extensive designs elsewhere)

The default option of current language is selected.
By the way, it's still kinds of UI design but not internal problem.
When I want to go further I would also rethink about the UI part.
 And from my point of view, setting interface of ibus is hardcoded, so
 those pygtk setting code must be replace one by one if they want to
 move to another toolkit (even from gtk2 to gtk3). And make it
 impossible to put the setting just inside the gnome-control-center.

 Are you saying that fcitx generates the configuration GUI based on
 a description? In general, our experience has definitely been over the
 years that auto-generated configuration have some downsides. They
 don't allow customized design of controls for particular options, and
 don't handle the interaction between interacting options well.

fcitx doesn't force this, external command would be allowed. But for
common case it's quite a lot easier to integrate with UI better.

 I don't want people to draw the conclusion that because I'm saying that
 input methods should have simple configuration without a lot of options,
 I think that they aren't important. I'm very aware that every single
 user that comes to GNOME and wants to write in Chinese needs to use an
 input method. But if we have so many options that the defaults don't get
 well tested, or if options conflict and produce bugs, then we're not
 shipping a good ';';'''
 '
Options are really required in order to meet people need especially
for input method. This is a basic components for people.

This shows your poor understand on input method, when you look at
Chinese Pinyin, you might found a lots of option (say more than 10-20
about pronunciation) are useless for common people, but others CANNOT
use it correctly without such options. This is the same case of
accessibility part in desktop.
___

Re: Some points about IM integration

2012-05-14 Thread Germán Póo-Caamaño

On Tue, 2012-05-15 at 12:21 +0800, Weng Xuetian wrote:
  I don't want people to draw the conclusion that because I'm saying
 that
  input methods should have simple configuration without a lot of
 options,
  I think that they aren't important. I'm very aware that every single
  user that comes to GNOME and wants to write in Chinese needs to use
 an
  input method. But if we have so many options that the defaults don't
 get
  well tested, or if options conflict and produce bugs, then we're not
  shipping a good ';';'''
  '
 Options are really required in order to meet people need especially
 for input method. This is a basic components for people. 

Is it possible you can enumerate all those special needs and why are
compulsory?

Just stating the options are important does not help to understand why,
neither gives the opportunity to think or determine which approach would
fit better.

-- 
Germán Póo-Caamaño
http://people.gnome.org/~gpoo/


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Tue, May 15, 2012 at 11:47 AM, Owen Taylor otay...@redhat.com wrote:
 On Mon, 2012-05-14 at 23:39 -0400, Owen Taylor wrote:

 I don't want people to draw the conclusion that because I'm saying that
 input methods should have simple configuration without a lot of options,
 I think that they aren't important. I'm very aware that every single
 user that comes to GNOME and wants to write in Chinese needs to use an
 input method. But if we have so many options that the defaults don't get
 well tested, or if options conflict and produce bugs, then we're not
 shipping a good ';';'''

 [ I'm sorry - had an input problem here - but attributable to a crumb in
  my keyboard rather than anything to do with input methods:-) ]

 then we're not shipping a good product. The configuration should be as
 complex as it needs to be but no more.

Sorry for my later mail, I didn't catch up this.

 I don't think there are easy answers, because there are a lot of people
 out there who really want to make input work well and work well with
 GNOME. So, mostly what I can do here is try to explain a bit about
 the way we usually think about things in GNOME and what we consider
 successful UI.

 - Owen



As long as we put our point to UI part, that may not be my expert field. :)
I think you guys know this part better than me.

But actually I hope there is some possibility for other developer to
work on theirs gnome integration.
Since some code in gnome-settings-daemon branch seems will be going to
shutdown the door for them even if they want. (I mean, without patch)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration