diff options
author | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
---|---|---|
committer | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
commit | 1be510f9529cb082f802408b472a77d074b394c0 (patch) | |
tree | b175f9d5fcb107576dabc768e7bd04d4a3e491a0 /zarb-ml/mageia-dev/2012-June/016147.html | |
parent | fa5098cf210b23ab4f419913e28af7b1b07dafb2 (diff) | |
download | archives-master.tar archives-master.tar.gz archives-master.tar.bz2 archives-master.tar.xz archives-master.zip |
Diffstat (limited to 'zarb-ml/mageia-dev/2012-June/016147.html')
-rw-r--r-- | zarb-ml/mageia-dev/2012-June/016147.html | 180 |
1 files changed, 180 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-June/016147.html b/zarb-ml/mageia-dev/2012-June/016147.html new file mode 100644 index 000000000..9ef51ca14 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-June/016147.html @@ -0,0 +1,180 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] GNOME plans + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20GNOME%20plans&In-Reply-To=%3Cop.wfdvezdtct0cxl%40kira-notebook.kirayao%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="016146.html"> + <LINK REL="Next" HREF="016154.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] GNOME plans</H1> + <B>Kira</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20GNOME%20plans&In-Reply-To=%3Cop.wfdvezdtct0cxl%40kira-notebook.kirayao%3E" + TITLE="[Mageia-dev] GNOME plans">elegant.pegasus at gmail.com + </A><BR> + <I>Mon Jun 4 16:48:25 CEST 2012</I> + <P><UL> + <LI>Previous message: <A HREF="016146.html">[Mageia-dev] GNOME plans +</A></li> + <LI>Next message: <A HREF="016154.html">[Mageia-dev] GNOME plans +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#16147">[ date ]</a> + <a href="thread.html#16147">[ thread ]</a> + <a href="subject.html#16147">[ subject ]</a> + <a href="author.html#16147">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>在 Mon, 04 Jun 2012 22:24:30 +0800, Olav Vitters <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">olav at vitters.nl</A>>寫道: +><i> On Mon, Jun 04, 2012 at 09:13:53PM +0800, Kira wrote: +</I>I hope this won't get some misunderstanding between you and me, + +since there's some obvious different viewpoint. :) + +>><i> 1. In MCC, we can set up the input method in localedrake, and this +</I>>><i> setting would be system-wide except GNOME about 3.6+. This should be +</I>>><i> mentioned, because it would destroy the unified user experience. +</I>><i> +</I>><i> As said, I don't code. And unified experience I care for GNOME, that it +</I>><i> works consistently. I care about freedesktop.org standards. I don't care +</I>><i> for differences between distributions. E.g. MCC is great, but I prefer +</I>><i> if it didn't exist. MCC is only Mageia/Mandriva, another distro has +</I>><i> other things, etc. +</I>><i> I prefer something in gnome-control-center. +</I>><i> +</I>Well, I think this should be proposed to more upper level... + +Because this affect the Mageia distribution, though. + +I believe Mageia still keeps the faith to achieve better unified + +user experience than other distribution. + +>><i> 2. For users who want other input method, is there a easy way to do it? +</I>>><i> I must remind here: I think most developer in GNOME don't really know +</I>>><i> the +</I>>><i> pain for our CJK user here. Whether iBus or other input method all +</I>>><i> don't meet the completeness that most people need. iBus continuously +</I>>><i> lost the word typed, Hime/GCIN, and others more don't have easy way to +</I>>><i> add up other input module, and scim/oxim... and more are even out of +</I>>><i> maintenance. +</I>><i> +</I>><i> iBus losing words sounds like something fixable. Fairly strange that it +</I>><i> does that though. +</I>><i> +</I>><i> And that most developers don't know much about CJK, agreed. That's why +</I>><i> it is important to figure it out. I even have less of a grasp, as not a +</I>><i> coder/developer. +</I>><i> +</I>Here I just want to point out the problem of each input method existed... + + +>><i> The main point of issue is that we hope to have the freedom and have +</I>>><i> the input method that fit each other's need( There's at least 10+ +</I>>><i> input modules exist), and the way GNOME implement the unified input +</I>>><i> method had very bad impression for us. +</I>><i> +</I>><i> GNOME is not about being able to change loads of things since +</I>><i> development of 2.0 began. You say you need the freedom to ensure the +</I>><i> input method does what you want. +</I>><i> +</I>><i> So why not ensure the default input method does what you want? +</I>><i> +</I>><i> I get the impression that each time a new input method is abandoned, +</I>><i> some new project is started, gets abandoned again, etc. Resulting in a +</I>><i> wish for the ability to always being able to change the input method. +</I>><i> +</I>So that's the problem of hard code iBus as the main player. SCIM had been + +once the major input method in major distribution, but ever since it's + +out of maintenance, iBus kicks in and gradually take the major for +"global". + +But that's not the case here in Taiwan or in China. We got about 50-50 in + +Hime/GCIN vs iBus as far as I know, and most people would like fcitx in +China. + +Sure you could force people to use iBus instead, but that really bad +impression + +and does no good to others since Hime/GCIN/fcitx works great and many +efforts are + +put into them, and these effort can't be transplant to iBus since they +works differently. + +The problem of selecting single input method is that: what if, iBus dies, + +then GNOME would have to rewrite the whole structure, or GNOME would jump + +in and make sure it won't die? Isn't it better to do it like KDE or other +DE + +to have the possibility of choosing? + +>><i> You guys do a good job, but the decision of easily bundle up a single +</I>>><i> input method is really a bad idea, because not all people want to +</I>>><i> contribute to iBus project, and they already have effort on other +</I>>><i> input methods. +</I>><i> +</I>><i> Of course there are developers involved in other input methods. But +</I>><i> not doing something because they might get offended.. this is not really +</I>><i> how a decision would be taken. Focus is on what gives a nice experience. +</I>><i> +</I>><i> +</I>Well, I think the point is this decision won't brought nice experience to +CJK users, or even more. + +I know you are not the decision maker, but I hope, at least here, + +we could find a way to do better, not just follow the upstream. +</PRE> + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="016146.html">[Mageia-dev] GNOME plans +</A></li> + <LI>Next message: <A HREF="016154.html">[Mageia-dev] GNOME plans +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#16147">[ date ]</a> + <a href="thread.html#16147">[ thread ]</a> + <a href="subject.html#16147">[ subject ]</a> + <a href="author.html#16147">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |