Em Thu, 2012-11-22 às 15:47 -0600, Ma Xiaojun escreveu: > On Thu, Nov 22, 2012 at 2:40 PM, Bastien Nocera <[email protected]> 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 [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
