Re: Concerning Keyboard Status Menu
- From: Bastien Nocera <hadess hadess net>
- To: Ma Xiaojun <damage3025 gmail com>
- Cc: desktop-devel-list gnome org
- Subject: Re: Concerning Keyboard Status Menu
- Date: Thu, 22 Nov 2012 23:30:47 +0100
Em Thu, 2012-11-22 às 15:47 -0600, Ma Xiaojun escreveu:
> On Thu, Nov 22, 2012 at 2:40 PM, Bastien Nocera <hadess hadess net> 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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]