Hi Owen, I'm sorry to see that you are trying to drag us back to discuss about "which IMF is better", which is very likely to start a flame war on the list.
Please excuse me if some of my replies are _tooooooo_ direct and _seems_ to be unfriendly, the idea behind is that I *sincerely* wish to lead both sides to a happy result. On Tue, May 15, 2012 at 7:27 AM, Owen Taylor <[email protected]> wrote: > In general, choice of input method framework is not a goal in itself. > If we choose a single input method framework to integrate with GNOME - > that doesn't make GNOME like proprietary software from Apple and Microsoft, > because GNOME will still be 100% Free Software, and will still be developed > in the open by the GNOME community. > No. Given no choice is something wrong. GNOME3 is advertised to be design driven, but have you heard about some rumors like this one: Q: "What are GNOME people doing?" A: "1.Super-excellent ideas and design;" "2.Poor implementation;" "3.Working hard on fix-ups and finally it works;" "4.Immediately starting to re-invent wheels from Point 1." So, let's concentrate on the integration of IMF, and surely yes, we all know that integration can possibly bring users a better experience. But this will work if and *only* if we don't push people very hard to work in a way they don't think feasible. Given that GNOME cannot reinvent another IMF definitely, and given that GNOME is lacking specialized people on this particular item, please at least follow their advice and don't try to push them to fit schedule. Just emphasizing the good side of doing such will very probably bring a half-baked broken system to users. And I want to emphasize again that IMF is very important to their users, much more important than any other visible components including but not limited to music players, editors, etc. Because when the input system isn't working well or become confusing, the user is forced to stop using the whole environment or he/she cannot be producible. Think about your keyboard is not working properly and you are stopped away from inputting anything to Web, Gedit and any other applications, can you continue your work with it? So _don't be hurry_, _don't rush_. Let's sit down for a cup of tea and plan it _much more carefully_. > GNOME doesn't want to work well just for tweakers and enthusiasts - it's > very important to the project that GNOME works well for all users without > tweaking. We want to give the choice of using Free Software to > everybody - this is a much more fundamental form of choice than giving a small > group of users the ability to swap out a different input method framework > underneath GNOME. > Distributions are already trying their best to cook out the best recipe for their target users, and all of these efforts are based on the fact that the software they use is an open system with a free license. But GNOME is on its way of being a closed system, though it comes with a free and open source license, it has been actively taking away users and developers' choices in the _name_ of experience. What free software users are expecting is an open system with a free license, and I doubt what's for a closed system with a free license. Is this like using free software to build an DRM enabled system? Anyway users are not able to change the presets anymore because they are deliberately made to be deep dependency, in the name of "we can only concentrate on foo, so bar is totally ignored, use foo or go away". > GNOME isn't just a set of parts that a Linux distributor takes and uses > to create a working system - we also take responsibility for creating > a fully working system. This means deciding how GNOME interacts with > system components like sound and networking and printing and when necessary > enhancing those components to provide the right experience to the user. > Then please raise the proposal about GNOME OS again, so all others can stop making GNOME based distributions because all others are just making "a working system" but GNOME OS will possibly be "a fully working one". The difference in the given wording is obvious, I think. > So we can't leave it up to one Linux distributor to combine GNOME with > fcitx to make a version of GNOME that works well for zh_CN and another > Linux distributor to combine GNOME with RIME or hime to make a version > of GNOME that works well for zh_TW. We want GNOME to, without customization, > work well for zh_CN, zh_TW, hi_IN, ru_RU, en_US, and so forth. > Why GNOME can't? Why just stop other distributions to make a best recipe for their users? This means all GNOME users and distributors must accept ALL or NOTHING. This reminds something that truly bad in our mind, and think about who is pushing such changes. Just _thinking_ something is good is not the right approach, because GNOME is not a lord project that everyone must follow. Users of these languages are using all the different input method frameworks and engines for years, and GNOME is not able to change the fact _instantly_. So, again, _don't be hurry_, _don't rush_. > Of course, it would be a mistake to think that a small group of English > speaking developers could make GNOME work well in all these languages. That > would be impossible! But from experience, we know that simply leaving a > problem like this to external developers and hoping for the best doesn't > work out well. Instead we need to engage users and developers from these > language communities into the GNOME development community. > > I don't want to minimize how easy that is - I know there are very significant > barriers of language, timezone, and distance that make this hard. I know > that bugs get ignored and patches sit around unreviewed. But still, > active engagement is the only way forward. I think it's absolutely wonderful > how many people have gotten involved in the current discussion! > Sure because we love the project. Even here we have some hardcore KDE users/developers (not me) in the thread, we are so sure that we don't want CJK users suffer from a decision made by a small group of people who don't even have required concepts in their minds, and we want to see GNOME, a great free software project, isn't choosing a wrong way of doing things. We want to alarm that CJK inputting method system is complex and the situation is complicated. If we truly wants to work on sorting some mess out, then fixing bugs in GTK+ first is a very appealing start. > We also need to keep in mind that we aren't talking about the choice of input > method, we are talking about input method *frameworks*. The basics of passing > events from application to daemon, loading different input method backends, > handling hotkeys and displaying feedback are going to be very similar for > all East Asian languages. > All of our CJK developers are surely know what the discussion is about, but the situations for IMF aren't like Jackd and PulseAudio which has clearly different target users. > Things like displaying feedback may be a little different if we move further > afield to Thai or Hindi - but still, there is no fundamental reason that they > need a different *framework*. > CJK developers are the backbone of the input system about complex characters, so we believe we're much more clear about the problem - just like we know less about XKB than their users. > Using a single input framework for all GNOME users has many benefits. > GNOME developers can reproduce bugs that users run into. Bugs only have to > be fixed once, not in multiple frameworks. We can actually figure out how > to make input methods work with onscreen keyboards and accessibility. Our > designers can collaborate on making the configuration dialogs conform to > GNOME standards. > Yes and no, because if we really want a single input method framework, then we should make it freedesktop.org standard or at least X.org, just like what have happened with XKB[1]. Making GNOME specific assessment will eventually break more and more other things and make GNOME a more closed system. [1]http://www.x.org/wiki/XKB > Finally, using a single input method framework is pretty much essential to > the goal of allowing users to configure languages at runtime with a nice user > interface. If language A and language B require different input method > *frameworks*, there is no way that the user can switch between them with a > hotkey. > And it's pretty much essential to say again that _don't be hurry_, _don't rush_. Input method frameworks are using up all kinds of shortcuts and users are having their all kinds of preferences, so making assumptions on shortcuts without asking the real users is certainly bad. > In general, I don't see standardizing D-Bus interfaces so that GNOME can > work with multiple input method frameworks as being a useful activity. > If the D-Bus interfaces are carefully maintained and changed only with > agreement and advanced notice, then they will impede the progress of bug > fixing and making things better. If the interfaces are not carefully > maintained, then they aren't standards at all, and users will constantly > encounter breakage. > True. That is a proposal to try to make both side happy - and I still see it's the only way if we are rushing - though there are real difficulties. > And in any case, as described above, there has to be *one* framework that > works as well as we can possibly make it for all users. Multiple partially > working frameworks are not a substitute. > Not for now, not so urgent, surely. > All of the above is an argument only for picking a single input method > framework. It doesn't say anything about what input method framework we > should pick. The fact that the IBus developers have been engaged with > GNOME for quite some time and are willing to work with us to create a user > experience that is simple and consistent with the GNOME principles is > certainly a big plus, but we do need to make sure that the end result > works well as well as looking good. > > - Owen The fact behind GNOME and IBus's collaboration is because Redhat. Because currently IBus is maintained by the original author and several RH people (the latter are doing more in recent time), so communication can happen with RH designers and developers (who are pushing such an idea) when outsiders don't knowing anything. If not so, why the collaboration happened before now? -- Regards, Aron Xu _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
