Re: 3.6 Feature: IBus/XKB integration



On Sun, May 13, 2012 at 5:54 PM, Ma Xiaojun <damage3025 gmail com> wrote:
> Hi, all.
>
> I subscribed this list for this thread. As yet another native Chinese
> Linux user I'd say I support IBus integration.
>

to what? GNOME? or all over Linux Distros?

> When I saw Ubuntu Bug #983254, Unity's IBus "integration", I feel that
> it was wrong and I spent some efforts to spread that bug in Chinese
> use community.
> https://bugs.launchpad.net/nux/+bug/983254
>
> However, now I feel that such integration is correct. People who find
> IBus sucks and able to install and use other frameworks instead often
> find origin GNOME and/or Unity sucks for them also.
>

1. here we are discussing "be able to" install and use other framworks.

2. is it a theory? prove "people who find IBus suck and ...often find
origin GNOME and/or Unity sucks for them also."

or it'll turn to be a great disrespect to all people around here.

as to me, GNOME is good, but yes, ibus sucks.

so I have to prevent a space rocket binding with a bicycle.

3. stop trying to binding Unity with GNOME. they're different things.

Unity is a distro-only software. As a distro, Ubuntu is free to do
anything they want and doesn't need to consider things to that deep.
they even can drop it as a whole. (that maybe the hope of some people
because Ubuntu is famous for embarrassing itself by its unstable
distro-only software. but not people here. Xu in this thread is of the
same role as you in Ubuntu distro. and others are objective about it.
but it doesn't even matter) and it will not affect any other distros
and people, because there're still many alternatives. like in your
launchpad thread, there're still persons who are against that idea.
they might be not Ubuntu users right now. but they still have Distros.

But GNOME?

I think you must missed the sentence that:

IBus maybe compulsory. then it'll be not possible for every distro
contains GNOME to change its default input method? not to say, users.

and Ubuntu and Unity does not the leader of Linux. sometimes they're
just the obstacle of  Linux. like in this case. under the circumstance
that every one is this thread knows IBus is not a good idea(not any
single IM will be a good idea), it can only embarrasses Unity again,
which has already be on Hall of Shame of IM maintained by people who
truly understand IM.

anyway please concentrating on "GNOME" and "IM".

GNOME can't use IBus only because Unity use it. because there're still
openSUSE who will drop IBus in the near future.

> I guess no one can unify Linux desktop experience in near future. But
> if none the camps provides a work-out-of-the-solution, it's just a
> illusion of choices. I'm happy to see GNOME and Unity is becoming less
> and less "powerful".
>

this thread is not to "unify" Linux desktop experience. but to unify
or diversify IM under GNOME. although the sentence itself is true.

there's no illusion here. everything's clear in details based on facts.

IBus is not a good choice and it's not the only choice.

and "powerful" is another story.

> Emacs, Perl, Unix, ninjas have 1000 ways to avoid IBus. I don't worry
> about these guys. Some people in this thread manage to maintain their
> own input method framework :)
>

only because there're ways to avoid, then you push to them?

I want to hear what such people say.

of course there's a simplest way to avoid IBus in this thread, and
everyone knows but no one even mention it, that is, do not use GNOME.

is it the thing we want and discussed?

to maintain by oneself is another story. everyone in this thread can
build IM from tarball. but it doesn't even matter. it's not our topic
here.

> Best Regards,
> Ma Xiaojun
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

actually to me, all you said sounds like a support not to use IBus in
a reverse expression. don't know what you really want to say.

Marguerite


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]