Re: Concerning Keyboard Status Menu

[Ma Xiaojun]

On Fri, Nov 23, 2012 at 1:24 AM, Bastien Nocera  wrote:
> Do you realise you've still not given a single good reason why we should
> do that? You gave 2 reasons to do that:
> - to enable users to use newly installed engines, for which we don't
> need to remove filtering

So you want to keep of track all useful engines? What's good for that?
To show that GNOME is *proprietary*?

> - Because users want to see a long list of half-broken, unmaintained
> engines that they wouldn't know which one to choose for their language

As I said several times, the distributions should only install
supported engine by default.
If a user install a package / compile from source for engine, she
should know exactly what she is doing.
Even general Windows users know how to download and install and
third-party engines. Some of them may also be broken but who cares? Is
uninstalling a black magic?

> You filed a bug in the middle of this conversation:
> https://bugzilla.gnome.org/show_bug.cgi?id=688914
>
> With gems like:
>> http://code.google.com/p/ibus-cloud-pinyin/
>> ( This one is outdated, it will may revive though. )
>> http://code.google.com/p/ibus-t9/
>> ( I'm not sure about the current state of this one. )
>
> You just listed 2 good reasons to keep a whitelist.

What's wrong with that.
Why don't GNOME maintain a whitelist for applications either?
I find that you are arrogant and show no respect to other people's work.
You can pick a default list according to your standard.
But users and developers have freedom to use and develop 'third-party'
one. As I said white list is unprecedented sh*t in the history of CJK
inputing.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Concerning Keyboard Status Menu

[Bastien Nocera]

On Thu, 2012-11-22 at 23:58 -0600, Ma Xiaojun wrote:
> On Thu, Nov 22, 2012 at 11:54 PM, anish patil  
> wrote:
> 
> > Such a mail thread is limitless, we need to think about working solutions or
> > solving the problems
> > How about creating a wiki page about current problems? what you expect from
> > GNOME upstream/designers ? What you expect from Ibus?
> 
> Engine list filtering should be changed to black list instead.
> I guess we need to black list some m17n advertised engines and ibus-xkbc.
> The code change should be easy but determining black list need some
> effort, I'm trying now.
> 
> Property menu filtering should be removed, I'd do this before above task.

Do you realise you've still not given a single good reason why we should
do that? You gave 2 reasons to do that:
- to enable users to use newly installed engines, for which we don't
need to remove filtering
- Because users want to see a long list of half-broken, unmaintained
engines that they wouldn't know which one to choose for their language

You filed a bug in the middle of this conversation:
https://bugzilla.gnome.org/show_bug.cgi?id=688914

With gems like:
> http://code.google.com/p/ibus-cloud-pinyin/
> ( This one is outdated, it will may revive though. )
> http://code.google.com/p/ibus-t9/
> ( I'm not sure about the current state of this one. )

You just listed 2 good reasons to keep a whitelist.

I filed a bug about letting users select newly installed engines, which
makes sense, but it's likely going to be invasive and for 3.8 only:
https://bugzilla.gnome.org/show_bug.cgi?id=688918

So you'd be better get started on proposing missing engines for the
languages you care about and know.

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

Re: Concerning Keyboard Status Menu

[Ma Xiaojun]

Bug report created:
https://bugzilla.gnome.org/show_bug.cgi?id=688916
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Concerning supported_ibus_engines in gnome-region-panel-input.c

[Ma Xiaojun]

A bug report is created for it.
Though some heated discussion happened in another thread.

https://bugzilla.gnome.org/show_bug.cgi?id=688914
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Concerning Keyboard Status Menu

[Ma Xiaojun]

On Thu, Nov 22, 2012 at 11:54 PM, anish patil  wrote:

> Such a mail thread is limitless, we need to think about working solutions or
> solving the problems
> How about creating a wiki page about current problems? what you expect from
> GNOME upstream/designers ? What you expect from Ibus?

Engine list filtering should be changed to black list instead.
I guess we need to black list some m17n advertised engines and ibus-xkbc.
The code change should be easy but determining black list need some
effort, I'm trying now.

Property menu filtering should be removed, I'd do this before above task.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Concerning Keyboard Status Menu

[Ma Xiaojun]

Another regression case for engine list filtering is that some people
used to created custom table through ibus-table or ibus-m17n, which is
now unusable without show_all_sources.

For example:
http://code.google.com/p/ibus/issues/detail?id=1544
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Concerning Keyboard Status Menu

[anish patil]

Hi,

>I'm definitely willing to do stuff. But the design is completely wrong
here.

Such a mail thread is limitless, we need to think about working solutions
or solving the problems
How about creating a wiki page about current problems? what you expect from
GNOME upstream/designers ? What you expect from Ibus?

-- 
Anish Patil
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Concerning Keyboard Status Menu

[Ma Xiaojun]

On Thu, Nov 22, 2012 at 10:24 PM, Mathieu Bridon
 wrote:
> That's all technical problems, they can all be fixed.
>
> "It's hard and will take a long time" is not an excuse for not doing it.

At least it won't happen soon. That's why we should not make
regressions for current IBus, even if you doubt the necessity of
having multiple engines for same Chinese input scheme.

> That's GNOME, not "the IBus platform" as I was responding to, but you
> removed that context from your answer.
>
> And GNOME still is open to third party, you just need to set a configuration
> to true (I'm sure there will be a checkbox in GNOME Tweak Tool before long),
> or actually talk to the GNOME developers about why your engine is important,
> and it will be available by default.
>
> Believe it or not, it actually works, I asked for the specific engines we
> needed in Hong Kong, and Rui made sure they would be white-listed. I didn't
> even have to bribe him or threaten him. :)

I saw that bug report. Why we need to take this bureaucracy of
explicitly asking for white listing? What's good about it?

The only real use of it seems to be block some XKB duplicates. That
can be handled by black listing instead.

As I said, the kind of work flow is indeed *proprietary*. A truly
*open* system (.e.g. Windows) never have such stupid restriction.

And I repeat, property menu is a separate issue that affects supported
engines also. Currently only ibus-anthy probably ibus-hangual has
working menu. ibus-type-booster gives up its menu.

> Well, I'm talking from my experience, not from what I don't know, and in
> Hong Kong, there actually are three "flavors", and that's it. If you do them
> properly (and they are not properly done at the moment), almost nobody will
> look anywhere else.
>
> What I actually find very rude of you is that you seem to somehow interpret
> my messages as having some kind of background intent.
>
> I was asking a question. A real question, because I wanted you to inform me
> on how things are in Mainland China. But you assumed I was just trying to
> undermine your argument and assuming that I was already right, which
> absolutely wasn't the case.
>
> Can we not just have a honest conversation where both parties talk seriously
> and inform each other, instead of interpreting what we think others are
> saying, and calling them "arrogant"?

Simple, there should be no white list filtering of supported engines
and there should be no filtering at all for property menu. Otherwise,
Mainland people won't use IBus with GNOME; people don't like software
having arbitrary regression, period.

Some information in above messages may be kind of off topic.

I do feel that you try hard to defend GNOME's current implementation
rather than thinking about it critically.
That's fine. But I decided to not to waste both of our time to explain
things. If you really want to know why, try the following exercises
first:
Type one paragraph using any Pinyin engine in the following page
http://zh.wikipedia.org/wiki/Gnome

> If not, I will quietly go back to my work, fix the IBus situation in Hong
> Kong with the help of others in the local community who are eager to do
> stuff instead of complaining on a mailing list, and ignore whatever you're
> saying and doing.

I'm definitely willing to do stuff. But the design is completely wrong here.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Concerning Keyboard Status Menu

[Ma Xiaojun]

On Thu, Nov 22, 2012 at 9:22 PM, Mathieu Bridon
 wrote:
> That's just a bug, let's fix it.
>
> You seem to know how these could be fixed, why don't you do it, or help
> others who could?

The desired feature list can be very extremely long. Though it may be
good to explicitly list them out.
Anyway, one thing is quite hard for us.
Some companies have server to collect the input data of input method
users and update their phrase databases with the help of human
editors. Then they push the phrases databases to users, in a
categorized manner.

> It actually is open to third-party engines.

Repeat, by default third-party engines are filtered out. And their
essential property menu are also filtered out so currently only
ibus-anthy and probably ibus-hangual is ready to use.

> Is it because the built-in engines in Windows suck, or because people just
> enjoy trying new stuff all the time?

It is because people always want better stuff and there is a competing
market for that, period.

Think Chinese input methods as something has flavors. The idea that
there will be one flavor suitable for everyone is really arrogant.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Concerning Keyboard Status Menu

[Mathieu Bridon]

On Friday, November 23, 2012 11:11 AM, Ma Xiaojun wrote:

On Thu, Nov 22, 2012 at 8:09 PM, Mathieu Bridon
 wrote:


Could it be because none of them are of sufficient quality that they feel
the need to constantly try new ones, in the hopes that it will be better
than the rest?


Yes, but the closed-source Windows engines basically outperform
current IBus engines currently.


That's just a bug, let's fix it.


But for Pinyin, Wubi and probably some others
are much harder.


You seem to know how these could be fixed, why don't you do it, or help 
others who could?



Instead, we should try to do things.
1. Keep the IBus platform open to third-party engines.


It actually is open to third-party engines.


Also, when you say "users", who are you talking about? Linux users, who are
generally more eager to tinker and try stuff? Or the more general population
who only use computers as a tool to get something done?


Don't be bad to Linux geeks.


What part of my message lead you to believe this? There was absolutely 
no moral judgement in my message.


(I mean, I actually **am** a Linux geek)


I don't have much experience with computers in work space, Mainland.
But for personal Windows I met, none of them are using Windows
built-in engines.


Is it because the built-in engines in Windows suck, or because people 
just enjoy trying new stuff all the time?



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

Re: Concerning Keyboard Status Menu

[Ma Xiaojun]

On Thu, Nov 22, 2012 at 8:09 PM, Mathieu Bridon
 wrote:

> Could it be because none of them are of sufficient quality that they feel
> the need to constantly try new ones, in the hopes that it will be better
> than the rest?

Yes, but the closed-source Windows engines basically outperform
current IBus engines currently.

You should check a fancy one to get some inspiration (just screenshots).
http://pinyin.engkoo.com/help?b=1
Sogou's smart edition is fancy in another aspect but it is hard to
explain without certain Chinese language knowledge.

Anyway, I'm not arguing that Windows rocks. I'd argue that we are not
in a position that we try to provide all the input experience to user
directly. Because we are not able to do so. You probably able to
develop ibus-cangjie even without extensive Chinese knowledge because
it's simple in itself. But for Pinyin, Wubi and probably some others
are much harder.

Instead, we should try to do things.
1. Keep the IBus platform open to third-party engines. We probably
never have a perfect engine for Pinyin, but that's OK. As long as
different people can served by different engines.
2. Keep a list of supported engines and let distributions ship them. I
really feel that Mac OS X's default input method list is much cleaner
than Windows's. But it is worse in most currently Linux distributions
because input method installation is generally dependent on language.
If a English-speaking user want to get some inspiration on Japanese by
try inputting Japanese, she'd figure out ibus-anthy or ibus-mozc is
the package to install, too hard.
Note that a filter of supported engines doesn't help. For example, on
a system without Chinese engines installed. A user try to install some
Chinese engines. She will be confused by the fact that some appear
after installation and some don't.

> Also, when you say "users", who are you talking about? Linux users, who are
> generally more eager to tinker and try stuff? Or the more general population
> who only use computers as a tool to get something done?

Don't be bad to Linux geeks.
Even though many of them try hard to use other IMFs and they are
beyond our scope. Many Mainland Chinese Linux users are OK with IBus
1.4 by using ibus-pinyin, ibus-sunpinyin or ibus-rime. But if we break
the property menu, then I don't think they can tolerate that. I
cannot, either!

I don't have much experience with computers in work space, Mainland.
But for personal Windows I met, none of them are using Windows
built-in engines. This means that general computer users do understand
the concept of engines. ( I don't think they understand the concept of
frameworks, though. )
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Concerning Keyboard Status Menu

[Mathieu Bridon]

On Friday, November 23, 2012 07:39 AM, Ma Xiaojun wrote:

In case you don't know. Unlike other language groups, Chinese users
are used to the fact there are many third-party engines available for
same input scheme and they would make a random or non-random choices
between them.


Could it be because none of them are of sufficient quality that they 
feel the need to constantly try new ones, in the hopes that it will be 
better than the rest?


Also, when you say "users", who are you talking about? Linux users, who 
are generally more eager to tinker and try stuff? Or the more general 
population who only use computers as a tool to get something done?



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

Re: Concerning Keyboard Status Menu

[Ma Xiaojun]

Even in IBus, we have the following 'third-party' Pinyin engines:
http://code.google.com/p/rimeime/
http://code.google.com/p/sunpinyin/
http://code.google.com/p/libgooglepinyin/
http://code.google.com/p/ibus-cloud-pinyin/

Having ibus-pinyin/ibus-libpinyin, ibus-chewing, ibus-table by no way
means that we are done with Chinese support.
It's always an open bazaar and please don't destroy it.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Concerning Keyboard Status Menu

[Ma Xiaojun]

In case you don't know. Unlike other language groups, Chinese users
are used to the fact there are many third-party engines available for
same input scheme and they would make a random or non-random choices
between them.

For example, on Windows, popular Pinyin engines include:
http://www.google.com/intl/zh-CN/ime/pinyin/
http://www.microsoft.com/china/pinyin/
http://pinyin.sogou.com/
http://www.unispim.com/
http://py.qq.com/
http://shurufa.baidu.com/

If any of the following company try to make a IBus version (Sogou is
doing a Fcitx version and I have no idea for others). Then what?
They need to ask explicitly for white listing?

That's why I advocate black listing now.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Concerning Keyboard Status Menu

[Ma Xiaojun]

If 'all the ibus modules that exactly replicate XKB layouts' bothers
you, black list them.
That's the right way to do it.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Concerning Keyboard Status Menu

[Ma Xiaojun]

On Thu, Nov 22, 2012 at 4:30 PM, Bastien Nocera  wrote:
> I've tried setting up a number of languages following the Fedora guides
> that were available. For a majority of the languages that people have
> tested and reported on, the steps are now reduced to a single one:
> select the input method in the list.

I like this aspect too, that's why I supported your integration proposal early.

> For example, all the ibus modules that exactly replicate XKB layouts,
> simply because they were not integrated before, and duplicate
> functionality.

That's unrelated to my concerns at all.

> Some of it isn't in my power, but some Fedora contributors have been
> trying to clean up the default installation from all the duplicated
> features, other unused desktop files.

I want a decent, not more, not less, default either.
But the problem I repeated several times is that its' extremely
unfriendly for 'unsupported', 'third-party' engines now. Even if you
argue that gsettings change to show them all is still acceptable (I
don't think so, there is no reason for this superfluous,
non-discoverable, rarely documented step). The newly installed engined
are handicapped by the menu filter again. As I mentioned, it's natural
that Chinese engines have several IBus.Property that are frequently
used.

Worse, your filter even hurt almost all supported Chinese engines,
ibus-pinyin, ibus-chewing and ibus-table.

So we shouldn't to hard-coded filtering at very beginning. What we
need to do is select a set of supported engines and polish their
property menu.
Whether or not other engines are going to polish themselves also
should not 'governed' by GNOME.

> I would rather the energy was spent on figuring out what languages are
> currently badly supported, and enable the ones that are sufficiently
> useful for the majority of the users of that language.

Have you really read my previous messages?
Didn't you notice that it is almost all about Chinese?

> You can still enable showing all the input methods if it's really
> required.
>
> Daiki's been doing great work on whitelisting input methods that are of
> high enough quality and usage to show by default, and we've advanced
> greatly in the support of Indian languages.
>
> Now, can you come up with languages that are not covered currently, and
> talk to us about selecting the best engine for each of those? That would
> make a positive impact to the discussion.

That's indeed proprietary.
If a new engine appear or an old engine revive, why should its
developer ask you for whitelisting? What's good about that?
IBus is an open platform rather than a proprietary platform.
Many closed-source platform are more open than that of your current
state. They don't a white list at all.

> You seem to be thinking that we don't care about certain users, quite
> the contrary, we wanted to solve the problems where all the different
> groups of Linux users that required input methods had to come up with
> their own hacks.
Integration itself is a nice idea, but do not being proprietary, please.
Users can install a engine by installing a ibus-* package than done, now what?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Concerning Keyboard Status Menu

[Bastien Nocera]

Em Thu, 2012-11-22 às 15:47 -0600, Ma Xiaojun escreveu:
> On Thu, Nov 22, 2012 at 2:40 PM, Bastien Nocera  wrote:
> > It's free software. And half of the existing IBus engines are
> > low-quality, and badly integrated.
> >
> > That's why they're not integrated.
> 
> Have you ever used any of above mentioned one?

I've tried setting up a number of languages following the Fedora guides
that were available. For a majority of the languages that people have
tested and reported on, the steps are now reduced to a single one:
select the input method in the list.

> What's your definition of low-quality? Please specify it.

For example, all the ibus modules that exactly replicate XKB layouts,
simply because they were not integrated before, and duplicate
functionality.

> If you need engines to do some manageable porting code-wise. It's
> still acceptable. Please show me evidences that you ever sent
> requests. All existing engines are designed and implemented before
> GNOME ever came up with the idea of IM integration.
> 
> If 'low-quality' stuff must be filter out even if a user really want
> to use it, why don't you do this for apps also?

Some of it isn't in my power, but some Fedora contributors have been
trying to clean up the default installation from all the duplicated
features, other unused desktop files.

> Regarding to definition of 'proprietary', Merriam-Webster 1st entry
> one that possesses, owns, or holds exclusive right to something
> 
> I feel that the definition describes your current mindset on IM
> integration quite well.
> 
> Yes you are free software license-wise so some people come up with the
> following:
> https://github.com/tigersoldier/gnome-control-center

An fcitx developer is forking gnome-control-center to add fcitx
integration. That's hardly surprising.

> And Arch already disabled IBus integration and Ubuntu raring probably follow.
> https://bugs.archlinux.org/task/32071

Again, the developer of another Input Method. Great care was taken to be
able to remove ibus support and mostly behave as before, to avoid the
major regressions from downstream deployments. I think it's great that
Arch are making changes to allow that.

> https://lists.ubuntu.com/archives/ubuntu-desktop/2012-November/004100.html

They're preparing for the next release. FWIW, we discussed the
integration work we did in GNOME with seb128 that they want to
eventually replicate in Unity. I doubt they'll stay put with the badly
integrated XKB/IM we had before.

> Do you really want such kind of fragmentation over GNOME?

I would rather the energy was spent on figuring out what languages are
currently badly supported, and enable the ones that are sufficiently
useful for the majority of the users of that language.

> You can argue that 3.8 will be better and people will use it. Well, I
> really doubt how far you can go if you still have current mind set
> that 'low-quality' stuff should be filter out.

You can still enable showing all the input methods if it's really
required.

Daiki's been doing great work on whitelisting input methods that are of
high enough quality and usage to show by default, and we've advanced
greatly in the support of Indian languages.

Now, can you come up with languages that are not covered currently, and
talk to us about selecting the best engine for each of those? That would
make a positive impact to the discussion.

You seem to be thinking that we don't care about certain users, quite
the contrary, we wanted to solve the problems where all the different
groups of Linux users that required input methods had to come up with
their own hacks.

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

Re: Concerning Keyboard Status Menu

[Ma Xiaojun]

On Thu, Nov 22, 2012 at 2:40 PM, Bastien Nocera  wrote:
> It's free software. And half of the existing IBus engines are
> low-quality, and badly integrated.
>
> That's why they're not integrated.

Have you ever used any of above mentioned one?
What's your definition of low-quality? Please specify it.

If you need engines to do some manageable porting code-wise. It's
still acceptable. Please show me evidences that you ever sent
requests. All existing engines are designed and implemented before
GNOME ever came up with the idea of IM integration.

If 'low-quality' stuff must be filter out even if a user really want
to use it, why don't you do this for apps also?

Regarding to definition of 'proprietary', Merriam-Webster 1st entry
one that possesses, owns, or holds exclusive right to something

I feel that the definition describes your current mindset on IM
integration quite well.

Yes you are free software license-wise so some people come up with the
following:
https://github.com/tigersoldier/gnome-control-center

And Arch already disabled IBus integration and Ubuntu raring probably follow.
https://bugs.archlinux.org/task/32071
https://lists.ubuntu.com/archives/ubuntu-desktop/2012-November/004100.html

Do you really want such kind of fragmentation over GNOME?

You can argue that 3.8 will be better and people will use it. Well, I
really doubt how far you can go if you still have current mind set
that 'low-quality' stuff should be filter out.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Concerning Keyboard Status Menu

[Bastien Nocera]

Em Thu, 2012-11-22 às 14:36 -0600, Ma Xiaojun escreveu:
> On Thu, Nov 22, 2012 at 3:22 AM, Bastien Nocera  wrote:
> > On Thu, 2012-11-22 at 03:01 -0600, Ma Xiaojun wrote:
> > 
> >> Stop destroying IBus by making it GNOME-proprietary, please.
> >
> > I don't think anyone will read your e-mails if you keep coming up with
> > statements like that.
> 
> I can understand if 3.6 has some glitches in IM integration, that's normal.
> But some of your unprecedented sh*t like engine list filtering and
> engine property filtering makes GNOME input system quite
> 'proprietary'.

It's free software. And half of the existing IBus engines are
low-quality, and badly integrated.

That's why they're not integrated.

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

Re: Concerning Keyboard Status Menu

[Ma Xiaojun]

On Thu, Nov 22, 2012 at 3:22 AM, Bastien Nocera  wrote:
> On Thu, 2012-11-22 at 03:01 -0600, Ma Xiaojun wrote:
> 
>> Stop destroying IBus by making it GNOME-proprietary, please.
>
> I don't think anyone will read your e-mails if you keep coming up with
> statements like that.

I can understand if 3.6 has some glitches in IM integration, that's normal.
But some of your unprecedented sh*t like engine list filtering and
engine property filtering makes GNOME input system quite
'proprietary'.
The way of doing things in IM aspect is fundamentally flawed.

IBus is a framework that allows people to develop engines in
(hopefully) friendly way. You can develop very fancy one as well as
very crappy one. User can install whatever engines they want. That's
open and non-proprietary.

Some 'third-party' engines I know:
http://code.google.com/p/rimeime/
http://code.google.com/p/libgooglepinyin/
http://code.google.com/p/ibus-cloud-pinyin/
(This one is a little outdated, I'm trying to port it to support
recent IBus version.)
http://code.google.com/p/ibus-t9/
(I haven't tried this one.)

For engine list filtering, the list itself is OK. But the way you
enforce it is fundamentally flawed. Your should recommend the list to
distributions and that's it. Don't think 'third-party' engines are
some geeky stuff. It's probably the case in Hong Kong. But not the
case in Mainland (and also Taiwan I believe). It may not be that easy
to find a single young, not so young, Mainland Chinese people using
Windows' built-in engines. We cannot change the fact that Linux is
lack of good engines, but please don't make the situation worse that
even existing 'third-party' IBus engines become harder to install.

For engine property filtering, it's completely non-sense. Are you
trying to become a steering committee that decide which property is
allowed and which is not allowed? What you should do is that polish
the supported engines and leave third-party engine as is. Even if you
argue that ibus-table has no upstream so it cannot be catered. What
about ibus-pinyin/ibus-libpinyin and ibus-chewing? Which are much more
popular and have known upstreams.

Chinese engines, in generally has the following properties need to on the fly.
Conversion (Chinese) or not (English).
(Some people prefer this switch rather than switch the engine altogether)
Half-width or full-width
( For example，。：； vs ,.:; )
( Chinese writing need full-width symbol but many computer related
place only accept half-width symbol, say Shell, Python, ...)
Simplified or Traditional
( For example 郁闷的乌龟 vs 鬱悶的烏龜 )
( You can think of it as lower/upper case, hiragana/katakana with both
set have thousands of *common* character. )
( In theory, one only needs either Simplified or Traditional, but
chances are that we communicating with different people so we
different variation. )

I'm not unwilling to hack code and submit patches. But what I would
like to do is eliminate the stupid filtering altogether. So related
the developer must understand why it is the case.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Concerning Keyboard Status Menu

[Ma Xiaojun]

On Thu, Nov 22, 2012 at 5:38 AM, anish patil  wrote:
> Ibus typing booster had similar problem, we moved IME menus into setup
> options
> http://git.fedorahosted.org/cgit/ibus-typing-booster.git/commit/?id=861a63af2a32aa4f9ed4e1d67c618b6777ee7d7d
> Hope this helps.

Well, that kind of solution is perfect example of an traditional
Chinese idiom: 削足適履 (to cut the feet to fit the shoes).

Anyway, this approach won't work for ibus-pinyin, ibus-chewing,
ibus-table, ... Because IBus.Property, by definition, is different
from IBus.Config. IBus.Property is meant for quick change during daily
use rather than some configuration once changed seldom change again.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Dropping fallback mode in 3.8

[Ma Xiaojun]

On Thu, Nov 22, 2012 at 8:51 AM, Alberto Ruiz  wrote:
> Ubuntu 10.04 is an LTS release, it is supported up to 5 years. EOL is 15.04.

5 year for server and 3 year for desktop.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Dropping fallback mode in 3.8

[Alberto Ruiz]

Ubuntu 10.04 is an LTS release, it is supported up to 5 years. EOL is 15.04.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Dropping fallback mode in 3.8

[Emmanuele Bassi]

hi;

On 22 November 2012 14:04, Simon McVittie
 wrote:

> Shell performance is not our only problem with modern GNOME and
> non-llvmpipe software rendering: there have been reports that
> applications using Clutter (e.g. Empathy with libchamplain) just don't
> start. ()

those are usually missing extensions and/or old versions of GLX
support in the swrast code paths in Mesa. Clutter (and Cogl) already
have feature negotiation through the GL API

admittedly, the non-llvmpipe rasterizer hasn't seen as much work as
the llvmpipe-based one, so I guess it's a matter of resources required
to be allocated towards fixing the old swrast code path.

ciao,
 Emmanuele.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Dropping fallback mode in 3.8

[Simon McVittie]

On 21/11/12 20:11, David King wrote:
> However llvmpipe doesn't currently work on some architectures (ppc,
> s390, arm?--ARM (hf) works-shawnl)

Debian is perhaps a useful source here, since we have more
architectures than most (any?) other distributions.

It seems we currently only build the llvmpipe driver on i386 and x86-64
(including non-Linux kernels on those architectures, though). I'm sure
the Debian Mesa maintainers would appreciate successful test reports for
other platforms: a comment in the packaging indicates that they're only
limiting llvmpipe to x86 because nobody has confirmed that it works
elsewhere.

I can confirm that under kvm virtualization on a modern laptop (Lenovo
X220, using spice to display graphics in virt-manager), GNOME 3.6 uses
fallback mode by default, but when forced to try Shell mode
(gnome.fallback=0 on kernel command line), performance is
fine (~ 15 fps). On the other hand, the Gallium swrast driver (not
llvmpipe) on the same setup is not really usable (~ 1 fps).

Shell performance is not our only problem with modern GNOME and
non-llvmpipe software rendering: there have been reports that
applications using Clutter (e.g. Empathy with libchamplain) just don't
start. ()

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

Re: Dropping fallback mode in 3.8

[Matej Cepl]

On 2012-11-21, 21:55 GMT, Alberto Ruiz wrote:
> Why did you upgrade her setup then? My mom still uses GNOME 2 (Ubuntu
> 10.04, have not touched that machine ever since I installed it), I just

It is not supported anymore (especially with security patches) ... if 
you want long-term support Debian/stable or CentOS are the ways to do, 
I guess.

Matěj

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

Re: Concerning Keyboard Status Menu

[anish patil]

Hi,

>The ability of changing state on the fly is an essential part of
>Chinese input experience.
>So we have both embedded menu and language panel in IBus 1.4 previously.

Ibus typing booster had similar problem, we moved IME menus into setup
options
http://git.fedorahosted.org/cgit/ibus-typing-booster.git/commit/?id=861a63af2a32aa4f9ed4e1d67c618b6777ee7d7d
Hope this helps.

Thanks,
Anish P.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Dropping fallback mode in 3.8

[Jasper St. Pierre]

On Thu, Nov 22, 2012 at 5:59 AM, Alan Cox  wrote:

> On Thu, 22 Nov 2012 05:47:30 -0500
> "Jasper St. Pierre"  wrote:
>
> > The hardware accelerated graphics API that the rest of the world has
> > depended upon is OpenGL, minus Direct3D for obvious reasons. It's
> > unfortunate, but if OpenGL isn't supported on these devices, a hardware
> > accelerated desktop isn't going to be possible. I don't think it's worth
> it
> > to write hardware acceleration code because the driver maintainers
> couldn't
> > give us the API that everybody else has.
>
> LLVMpipe gives you that API
>

Sure. It's not hardware-accelerated, though, which is the issue we're
discussing with PowerVR. If they implement what we need in terms of a
hardware-accelerated graphics rendering API (OpenGL, plus a few extensions
here and there), things should start to work.


> > The issue should be fixed at the driver level, not at the GNOME level.
>
> You can't fix it at the driver level or that easily at the Gl level. The
> problem you have is that Gl type rendering doesn't allow the stack
> sufficient ability to identify optimisations for what is basically for
> the most part 2D abuse of the 3D API. In addition it is more CPU
> intensive to do Gl emulation which in todays world means that it costs
> power and thus battery life.
>

Sure, we can argue about whether GL is a good API for what we're doing, and
design better APIs for rendering 2D graphics efficiently (XRender,
anyone?), but a simple fact remains: OpenGL is the API we have for doing
hardware-accelerated graphics rendering, like it or not.

Implementing a software renderer for gnome-shell / Clutter isn't on my list
of things to do in the near future.


> Hence you need to do it higher up the stack where you have the
> information needed. E does this and that is why E is very fast on just
> about any hardware.
>


> You also need to be aware of much of this higher up anyway even in the
> OpenGL world because you need to adjust your options and effects based on
> the timing and performance currently being received do that you can for
> example dynamically drop out some of the effects on a box under load, or
> perhaps on a low clock in battery mode.
>
> Alan
>



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

Re: Dropping fallback mode in 3.8

[Alan Cox]

On Thu, 22 Nov 2012 05:47:30 -0500
"Jasper St. Pierre"  wrote:

> The hardware accelerated graphics API that the rest of the world has
> depended upon is OpenGL, minus Direct3D for obvious reasons. It's
> unfortunate, but if OpenGL isn't supported on these devices, a hardware
> accelerated desktop isn't going to be possible. I don't think it's worth it
> to write hardware acceleration code because the driver maintainers couldn't
> give us the API that everybody else has.

LLVMpipe gives you that API

> The issue should be fixed at the driver level, not at the GNOME level.

You can't fix it at the driver level or that easily at the Gl level. The
problem you have is that Gl type rendering doesn't allow the stack
sufficient ability to identify optimisations for what is basically for
the most part 2D abuse of the 3D API. In addition it is more CPU
intensive to do Gl emulation which in todays world means that it costs
power and thus battery life.

Hence you need to do it higher up the stack where you have the
information needed. E does this and that is why E is very fast on just
about any hardware.

You also need to be aware of much of this higher up anyway even in the
OpenGL world because you need to adjust your options and effects based on
the timing and performance currently being received do that you can for
example dynamically drop out some of the effects on a box under load, or
perhaps on a low clock in battery mode.

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

Re: Dropping fallback mode in 3.8

[Jasper St. Pierre]

The hardware accelerated graphics API that the rest of the world has
depended upon is OpenGL, minus Direct3D for obvious reasons. It's
unfortunate, but if OpenGL isn't supported on these devices, a hardware
accelerated desktop isn't going to be possible. I don't think it's worth it
to write hardware acceleration code because the driver maintainers couldn't
give us the API that everybody else has.

The issue should be fixed at the driver level, not at the GNOME level.


On Thu, Nov 22, 2012 at 5:30 AM, Alan Cox  wrote:

> It's a series of chipsets involved
>
> GMA500 ('Poulsbo')
> GMA600 ('Oaktrail')
> GMA3600 ('Cedartrail')
> GMA3650 ('Cedartrail')
> E6xx ('Tunnel Creek')
>
> The unaccelerated driver is quite happy with 2D desktops but LLVMpipe and
> the paths used by the Gnome bling and compositing seem to hit it a lot
> harder.
>
> That probably points to it being at least partly solvable by de-blinging
> the Gnome3 desktop or optimising/changing how it renders. E for example
> has multiple rendering back ends.
>
> Alan
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>



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

Re: Dropping fallback mode in 3.8

[Alan Cox]

> How could GNOME encourage decent drivers? Have the GNOME foundation ask
> the company? Go via Linux Foundation? Maybe some kind of request? Would
> throwing money at it help (how much?)?

I am not that sure. The business and politics of graphics controllers is
a good deal bigger and more complicated than Gnome. I'm hoping
Valve/Steam has an impact.

There are obvious things like buying hardware that is properly
supported, and filing bug reports. However I think most people who care
enough are already doing that.

In addition telling people what hardware is known to work with free
drivers and is good is always going to be helpful. Especially as much of
the hardware which will do the job is very cheap anyway. On laptops and
tablets however you tend to be stuck with buying the right device.

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

Re: Dropping fallback mode in 3.8

[Alan Cox]

It's a series of chipsets involved

GMA500 ('Poulsbo')
GMA600 ('Oaktrail')
GMA3600 ('Cedartrail')
GMA3650 ('Cedartrail')
E6xx ('Tunnel Creek')

The unaccelerated driver is quite happy with 2D desktops but LLVMpipe and
the paths used by the Gnome bling and compositing seem to hit it a lot
harder.

That probably points to it being at least partly solvable by de-blinging
the Gnome3 desktop or optimising/changing how it renders. E for example
has multiple rendering back ends.

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

Re: Concerning Keyboard Status Menu

[Mathieu Bridon]

[Note: I'm not a GNOME developer, I don't have Git access, I'm not part 
of any conspiracy, but I'm actively working on improving the inputting 
experience for Traditional Chinese in Hong Kong]


On Thursday, November 22, 2012 05:01 PM, Ma Xiaojun wrote:

However, why the menu in keyboard status menu become something that
requires engine specific hacks?
I saw one for anthy.
https://bugzilla.gnome.org/show_bug.cgi?id=682314
http://git.gnome.org/browse/gnome-shell/commit/?id=9659d934ac190a6363fc5b59f3c62ef305f56c52

What about ibus-chewing, ibus-pinyin, ibus-table and probably other
engines especially 'third-party' ones then?
Without property menu they are much less useful in practice.

If you have concerns the property texts, other things about
'supported' engine, why don't you contact IBus upstream and request
for change?


ibus-table had no upstream for a very long time.

I know it, because I spent weeks trying to find who was the upstream 
maintainer (and IBus people didn't even know) until kaio recently took 
it over. (I can't be grateful enough to him for this)


How can GNOME (well, mostly one developer and one designer) track all 
the upstreams of all the engines, when some don't even have upstreams at 
all?


Also, and that's a more general observation, GNOME 3.6 is **the first 
time** there is any kind of integration of the input methods. Did you 
really think it would be perfect the first time?


There will be improvements in 3.8 and beyond, I'm sure Rui has a TODO 
list that extends to the next few years. :)


And part of these improvements is for people who actually use input 
methods to come and explain GNOME people what would be a great user 
experience for their language.


That's probably why Anthy has these integration points: because some 
Japanese people (users and developers) came together and gave feedback 
on what their inputting experience should look like.


That's what we've been doing in Hong Kong for the past few months too, 
both in discussing locally when we meet, and talking with Rui and Allan 
about what we needed. (and we're not as well off as Anthy users for 3.6 
because we're starting from a worse point, and we don't have as many 
knowledgeable people here).


And that's what people who care about the user experience for their 
languages should do. Because ultimately, only them can do it. There is 
no way a non-Chinese designer (as good as he is) can figure out on his 
own the perfect user experience to input Chinese. Chinese people have to 
help him design that user experience. And at least for Hong Kong, it's 
going on very well. (although slower than I would have hoped, but the 
ball is on our side)


It will take time, but it's going to work out eventually and provide a 
truly great user experience.


Now I know you have some solid programming skills as we've worked 
together on some changes to ibus-table in the past.


So please, let's write less emails, and more patches, to make IBus 
better, both inside and outside of GNOME. :)


Cheers,


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

Re: Dropping fallback mode in 3.8

[Bastien Nocera]

On Thu, 2012-11-22 at 10:18 +0100, Olav Vitters wrote:
> On Wed, Nov 21, 2012 at 09:00:56PM +, Alan Cox wrote:
> > Equally its near unusable on a brand new netbook which has Imagination
> > graphics and a relatively low end CPU.
> 
> How could GNOME encourage decent drivers? Have the GNOME foundation ask
> the company? Go via Linux Foundation? Maybe some kind of request? Would
> throwing money at it help (how much?)?

People have been banging their heads about this chipset:
http://en.wikipedia.org/wiki/Poulsbo_(chipset)#Poulsbo

There's nothing to be done about it, Intel wanted to save money and
bought a GPU core for their Atom CPU along with binary blobs for
drivers.

It's junk.

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

Re: Concerning Keyboard Status Menu

[Bastien Nocera]

On Thu, 2012-11-22 at 03:01 -0600, Ma Xiaojun wrote:

> Stop destroying IBus by making it GNOME-proprietary, please.

I don't think anyone will read your e-mails if you keep coming up with
statements like that.

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

Re: Dropping fallback mode in 3.8

[Olav Vitters]

On Wed, Nov 21, 2012 at 09:00:56PM +, Alan Cox wrote:
> Equally its near unusable on a brand new netbook which has Imagination
> graphics and a relatively low end CPU.

How could GNOME encourage decent drivers? Have the GNOME foundation ask
the company? Go via Linux Foundation? Maybe some kind of request? Would
throwing money at it help (how much?)?

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

Re: Dropping fallback mode in 3.8

[Olav Vitters]

On Wed, Nov 21, 2012 at 06:47:35PM -0600, Ma Xiaojun wrote:
> Though it seems hopeless to change the decision, I find some tendency 
> annoying.

You missed the obvious answer:
- Need to ensure that the driver supports what the hardware is capable
  of.

> 2. Folks can use LLVMpipe.

llvmpipe is not meant as a replacement. The solution is good drivers,
llvmpipe should be seen as a workaround to at least be able to use GNOME 3.

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

Concerning Keyboard Status Menu

[Ma Xiaojun]

The ability of changing state on the fly is an essential part of
Chinese input experience.
So we have both embedded menu and language panel in IBus 1.4 previously.

I used to believe that IBus 1.5 enforce the first form and and no
longer support second form.
That's fine for me, though some people may miss it.

However, why the menu in keyboard status menu become something that
requires engine specific hacks?
I saw one for anthy.
https://bugzilla.gnome.org/show_bug.cgi?id=682314
http://git.gnome.org/browse/gnome-shell/commit/?id=9659d934ac190a6363fc5b59f3c62ef305f56c52

What about ibus-chewing, ibus-pinyin, ibus-table and probably other
engines especially 'third-party' ones then?
Without property menu they are much less useful in practice.

If you have concerns the property texts, other things about
'supported' engine, why don't you contact IBus upstream and request
for change?
For third-party engines, they should have freedom to do whatever they
want, rather than blocked by some hard-coded filter.

Stop destroying IBus by making it GNOME-proprietary, please.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list