date:20120515

On Tue, May 15, 2012 at 1:42 PM, Tommy He tommy...@linux.com wrote:
 I'm just start catching the whole story and find where the discussion is now.

 On Tue, May 15, 2012 at 1:07 PM, Weng Xuetian wen...@gmail.com wrote:
 On Tue, May 15, 2012 at 12:52 PM, Germán Póo-Caamaño g...@gnome.org wrote:

 Is it possible you can enumerate all those special needs and why are
 compulsory?

 Just stating the options are important does not help to understand why,
 neither gives the opportunity to think or determine which approach would
 fit better.

 Well, since we already agreed on option complex but necessary is
 required, we need not to continue on this question.

 But if you want I could explain it. (Note that both fcitx and ibus
 have such option, so it's not about functionality but about UI.)

 Pinyin is an input method based on Pronunciation of Chinese character.
 But Chinese people have quite different accent in different place, so
 they might not be able to distinguish some pronunciation, for example
 si or shi. So they are option to let input method think si and shi
 is the same string to lookup. Number of similar options is nearly 20,
 I think we could think this as Complex. For the number of people who
 need it, it is much lesser than people who don't need it. But we
 cannot remove them since it's necessary for those people.

 Now we're back to a specific input method, again.
 From my perspective, these options should be considered as input
 method engine options.

 I assume that proposed IM configuration module in gnome-control-center
 will ONLY presents the options for input method *framework*. Correct
 me if I'm wrong.
 As long as it have a button to launch the input method engine
 preference window AND doesn't shut the door from engine developer to
 customize, I don't see it as an issue.

You totally get my meaning wrong, I mean shutdown down the door for
other IMF, and the code is mostly in gnome-settings-daemon since it
looks like gnome want to force gtk-im-module settings.


 If so, I'm curious on how many tweaks in a certain input method
 *framework* are available to end users in runtime. How many are there
 in iBus and FCITX respectively?

Fcitx have more, but that's for Global configuration, which ibus
usually provide them for each input method engine.

The most difference of philosophy of ibus and fcitx is, for ibus, the
only type of plugin is just engine, and standalone with each other.
For fcitx, plugin is not only engine and they should cooperate to
provides better input feeling.


 Otherwise, I'm afraid that we may never consolidate a unified UX for
 IM configuration module since the input method engine options vary
 vastly.


 __
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list



 --
 Take a Deep Breath out of Windows
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

2012-05-15 Thread Tommy He

I'm kind of worry about the echoing sound that CJK user bases
represents all the needs for a input method *framework*. It's NOT.

Take a look at these:
http://fedoraproject.org/wiki/Features/IndicTypingBooster
http://fedoraproject.org/wiki/Features/english-typing-booster

Also here are the packaging situation for iBus on Fedora:
https://apps.fedoraproject.org/packages/s/ibus
It seems to be better than that on openSUSE but I don't see anything
significant other than the additional typing boosters.

Another worrying trend I feel while reading this thread is that
comparing input method based on the availability and quality of
engines. As Fujiwara suggests, focusing each IM engine would not be
good to pick up the default IM framework.

From my experience on project management and evaluation, I would like
to initialize a few questions to head to this direction:
1. What are the essential features for a input method *framework*?
2. How good/buggy the iBus and FCITX are on above essential features
respectively?
3. The availability of input method engines supported by iBus and FCITX.
4. The quality of each input method picked from the above.

We may continue to ask ourselves more questions like above until the
evaluation form is created. It would a bit harsh to say which input
method *framework* is better if we don't have a clear standard.

Tommy

On Tue, May 15, 2012 at 1:46 PM, Marguerite Su i...@marguerite.su wrote:
 On Mon, May 14, 2012 at 8:34 PM, Christophe Fergeau t...@gnome.org wrote:
 Hey,

 I just read the whole thread, and had a few questions, I'm more or
 less arbitrarily answering to this email in the thread.

 2012/5/13 Marguerite Su i...@marguerite.su:
 and another background knowledge:

 fcitx is capable of inputing in Traditional Chinese( IBus don't make
 it even work), Simplified Chinese(as I said, top choice if user has
 choices), Korean( korean Ubuntu users is discussing it in their forums
 just right now.), Vietnamese.

 and Japanese is starting in two months after Weng finished his
 graduation paper. it's for GNOME 3.6 right? he invent fcitx-keyboard
 in just two days but solid. can't you wait  two month and work on
 other parts of fcitx?

 Did I understand correctly that fcitx does *not* have japanese support
 today but that it should be implemented in the coming months? This
 would mean that fcitx is not a suitable CJK method now as has been
 said throughout the thread, but just a CK input method until Weng does
 his magic ;)


 Hi, Christophe,

 I was a little mix up this thread with the thread on our distribution channel.

 here are some background in our thread ( not this one ):

 at first, answer your question:

 FCITX has J support, mozc.

 and fcitx has a experimental anthy.

 so you may ask: why doesn't finish anthy then start mozc?

 mozc is actually like Linux version of Google Japanese IM.

 and anthy/canna/skk/wnn are all IM engines in SICM era.

 so Japanese is like us Chinese, prefer to use mozc as a better
 choice.(so Chinese nowadays even know mozc.)

 since FCITX takes users choice as the first priority. they do mozc
 first. that's something development schedule.

 then I proposed to select MOZC as Japanese default IM in openSUSE DVD
 since it's the users' choice.

 but then maintainers of MOZC told me although mozc is FOSS, it's close
 development. so it's hard for us(I'm one of mozc maintainer too) to
 maintain it as a distribution's default IM.

 that's why we temporarily kept ibus-anthy as default IM in DVD, until
 Weng finished fcitx-anthy (as you know, J community is tired of
 IBus-anthy too, too old, too buggy. and they're actively involved in
 testing now).

 so it's not FCITX doesn't has J support. but is J community decides
 not to choose mozc as default IM although they use it on a daily basis
 and prefer it as better choice. they calls for
 fcitx-anthy/canna/skk/wnn as default IM, although they'll use mozc as
 their actually default IM.

 :)

 This leads to my next question, this thread so far has been focused on
 CJK (and Vietnamese in this email). Are they the only languages that
 needs input methods? Or are they needed too for arabic, hebrew,
 thailandese, ... ? If yes, is fcitx the IM framework to use for these
 too?


 to be honest, CJK developers build IM framework, others build local
 engines.(but there are still many much more engines in CJK than
 others) that's why we focus on CJK here. because as IM, if you can't
 support CJK to input with hobby and pleasure, even if you success in
 all other areas, it's hard for you to call yourself as a framework.

 and if framework is good, engines catch up more quickly than you think.


 CNS11643, Compose, Emoji, Ipx-x-sampa, Latex, Rustrad,
 Thai, Translit-ua, Translit, Viqr, Yawerty.

 these're all other non-CJK engines IBUS and FCITX both support. is
 there any engine IBUS supports but FCITX not? no. at least for
 openSUSE. because I almost package and maintain every IM in openSUSE,
 SCIM/IBUS/FCITX. and I think

Re: 3.6 Feature: IBus/XKB integration

On Tue, May 15, 2012 at 12:32 AM, Sergey Udaltsov
sergey.udalt...@gmail.com wrote:
 I do not want to see iBus integration becomes another Power Off Button on
 GNOME Shell.
 IMHO the useful discussion should be from two directions.

 One direction - from the user POV. Here, the goal is to define the
 experience that would make CJK (and other) users happy. To collect the
 requirements to the perfect IM integrated into GNOME. That task
 needs a lot of input from the people of those nations. But that
 discussion, ideally, should not mention existing IM frameworks.
 Functionality, not names. Otherwise it will be endless IM1 is better
 than IM2 for language L1, while IM2 is better than IM1 for language
 L2 flamewar.


yes, no more flame war, please, everyone.

and we have debate between perfect IM integrated into GNOME and

3 sides invents perfect IM protocol for GNOME. 3 sides join hands to
make both IBUS/FCITX/OTHER FUTURE IMs good with GNOME.

if only one IM, certianly it comes to a flame war.

IBUS developers are unhappy, or FCITX ones, or GNOME ones.

I thinks all of you are already unhappy now.


 The second direction - from the architectural POV: what would be the
 interface that could allow any slightly less than perfect IM (or
 multiple IMs - if it is possible) to be integrated into GNOME.
 Perhaps, that part can be discussed even by people without immediate
 IM experience - just knowing what Gtk/Gnome-control-center/... can and
 cannot do. And looking at the requirements and ideas expressed by the
 first table.

 After that, there could be fair competition among IM solutions.


yes, competition is good. collaboration is good. standard to
freedesktop.org is good.

or a deep-GNOME-intregrated IBus will also harm IBUS too.

because it's not GBUS.

so if it goes into GNOME side. other sides will take bad results.

and that's where GNOME developers can not fix.

 Yes, there can be another approach, which I guess is the worst of all
 (but still some people like it, I know) - pick one existing IM
 framework, make it hard dependency, and start fixing its bugs, without
 giving alternatives any chance...

yes, the worst case. but it's what GNOME developers want before.

they're now facing this problem directly and wish to change, maybe a
little bit,

maybe BIG progress.

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

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

Re: 3.6 Feature: IBus/XKB integration

On Tue, May 15, 2012 at 11:11 AM, Takao Fujiwara tfuji...@redhat.com wrote:
 Hi,

 I'm working on the ibus integration.


 (05/13/12 13:31), Justin Wong-san wrote:

 Well this is how ibus is done, as u can see, ugly.

 but i should say  users would never see this long long menu, because this
 menu provides 13 kinds of input methods for users, where normal users use
 less than 3 input methods, this screenshot is just to show ibus can
 provide so many IMs


 The long menu has been enhanced in the latest ibus-gjs gtk3-vala branch. But
 it still do not work in other distros because we're discussing how the
 internal patches are resolved.
 Probably the latest will be available for other distros soon.
 We're still discussing the better UI.

      https://extensions.gnome.org/extension/261/kimpanel/
     
 https://extensions.gnome.org/extension/68/input-method-status-indicator/


 Sorry, it's a bit old as I explained above.
 It would miss some important features against the last ibus-gjs. E.g. using
 libgnomekbd and preloaded xkb engines.
 Yes, ibus-gjs does not support fcitx because upstream suggests to pick up
 one input method as the implementation itself would be possible.


Welcome! fujuwara, as IBus developer!

I'm glad to see this thread diversified.

that sounds a little sad to me actually.

then others really have to reinvent the wheels...and if deep
integrated, to reinvent the wheels really hard.

 fujiwara

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

Re: 3.6 Feature: IBus/XKB integration

On Tue, May 15, 2012 at 11:38 AM, Takao Fujiwara tfuji...@redhat.com wrote:
 (05/14/12 21:34), Christophe Fergeau-san wrote:

 This leads to my next question, this thread so far has been focused on
 CJK (and Vietnamese in this email). Are they the only languages that
 needs input methods? Or are they needed too for arabic, hebrew,
 thailandese, ... ? If yes, is fcitx the IM framework to use for these
 too?


 I think all IM framework should support the available languages.
 Maybe I need to check some status but I don't see any critical problems.


yes. both IMs now supports.



 Having an IM abstraction framework has been one recommended by some
 people in this thread. One concern I have with that is that the
 fragmentation we have now will stay, and we'll have the foo IM
 framework which will be favoured by people who want to input language
 A, the bar IM framework will be the best for language B. In such a
 situation, people who want to input both A and B (think A speaker
 learning the B language) will not get a satisfying user experience.

 Finally, please correct me if I misunderstood, but after reading the
 thread, I'm under the impression that ibus and fcitx work equally well
 to input CJK characters (except for a few ibus bugs that I guess
 could be fixed?). What makes fcitx better is that it provides advanced
 functionalities such as word autocompletion (+ highly customizable
 autocompletion window and online autocompletion lists), macros
 (short key sequences that will get replaced by a full word), ... My
 feeling about these advanced functionalities is that they are not
 really CJK-specific, and that this could be useful too when typing
 English or French texts, in which case this may be worth integrating
 at a higher level instead of having this in the input method? I guess
 the answer is that they are different things, but asking does not hurt
 ;)


 The implementation design would be more important for me.
 Actually I didn't think the autocompletion is so important but it would be
 an each IM engine's issue while ibus-european-table provide that feature.
 Probably I don't think focusing each IM engine would be good to pick up the
 default IM framework since it would be engines' issues.


see, that's the design conflicts.

autocompletion directly matters to user on issue if they can input really fast.

so it should be a framework's work instead of engines.

if framework's good at it, every engine can benefit. like if GTK's
good at drawing windows fast, every gtk application will benefit.

yes, focusing on engines won't help, because we're discussing IMF.

 fujiwara


 Christophe

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


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

Re: Some points about IM integration

2012-05-15 Thread Tommy He

On Tue, May 15, 2012 at 2:05 PM, Weng Xuetian wen...@gmail.com wrote:
 On Tue, May 15, 2012 at 1:42 PM, Tommy He tommy...@linux.com wrote:
 I'm just start catching the whole story and find where the discussion is now.

 On Tue, May 15, 2012 at 1:07 PM, Weng Xuetian wen...@gmail.com wrote:
 On Tue, May 15, 2012 at 12:52 PM, Germán Póo-Caamaño g...@gnome.org wrote:

 Is it possible you can enumerate all those special needs and why are
 compulsory?

 Just stating the options are important does not help to understand why,
 neither gives the opportunity to think or determine which approach would
 fit better.

 Well, since we already agreed on option complex but necessary is
 required, we need not to continue on this question.

 But if you want I could explain it. (Note that both fcitx and ibus
 have such option, so it's not about functionality but about UI.)

 Pinyin is an input method based on Pronunciation of Chinese character.
 But Chinese people have quite different accent in different place, so
 they might not be able to distinguish some pronunciation, for example
 si or shi. So they are option to let input method think si and shi
 is the same string to lookup. Number of similar options is nearly 20,
 I think we could think this as Complex. For the number of people who
 need it, it is much lesser than people who don't need it. But we
 cannot remove them since it's necessary for those people.

 Now we're back to a specific input method, again.
 From my perspective, these options should be considered as input
 method engine options.

 I assume that proposed IM configuration module in gnome-control-center
 will ONLY presents the options for input method *framework*. Correct
 me if I'm wrong.
 As long as it have a button to launch the input method engine
 preference window AND doesn't shut the door from engine developer to
 customize, I don't see it as an issue.

 You totally get my meaning wrong, I mean shutdown down the door for
 other IMF, and the code is mostly in gnome-settings-daemon since it
 looks like gnome want to force gtk-im-module settings.

Nope, I was not talking about this one. Sorry to mention that I'm kind
of agree that there should be a single default IMF, not multiple.

There needs to be a default IMF integrated into GNOME. It's the way I
believe to bring i18n users to same level as others.
This default IMF should have tightly correspond with a single UI
module in gnome-control-centre, which presents all IMF level tweaks.

However the Preference window for a given input method engine should
not and can not be unified. It had better to be left to the hands of
input method engine developers.

What I am NOT suggesting is that this default IMF would be iBus nor
FCITX. Maybe neither of them.
After reading this long thread, there's still no concrete proof on how
supreme FCITX is on the core feature sets of IMF. BTW please don't
hesitate to list them here.

The reason I am asking is that in practice we need to figure out which
one is more suitable to choose as the reference IMF. There has to be a
referenced one, either slightly modified iBus, slightly modified
FCITX, or even a complete new one written from scratch. Just one, not
two or multiple.

Another thing I am NOT suggesting is that shutting the door for other
IMFs. During the development of the reference IMF, we should declare
what kind of behaviors GNOME would expect from a IMF so that a thin
wrapper could be developed later for other non-default IMFs.
The non-default IMF should be allowed to add its own configuration
module into gnome-control-centre while disabling the default one.


 If so, I'm curious on how many tweaks in a certain input method
 *framework* are available to end users in runtime. How many are there
 in iBus and FCITX respectively?

 Fcitx have more, but that's for Global configuration, which ibus
 usually provide them for each input method engine.

I see your point. FCITX seems to pull more common options from input
method engines than iBus and listed them as Global configuration.
It might be good, but might also increase the coupling, if I'm allowed to say.

 The most difference of philosophy of ibus and fcitx is, for ibus, the
 only type of plugin is just engine, and standalone with each other.
 For fcitx, plugin is not only engine and they should cooperate to
 provides better input feeling.

I'm afraid it's still a bit vague. Are you saying that in FCITX by
enabling plugin A AND plugin B, there will be more options than
combining enabling plugin A and enabling plugin B individually?


 Otherwise, I'm afraid that we may never consolidate a unified UX for
 IM configuration module since the input method engine options vary
 vastly.


 __
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list



 --
 Take a Deep Breath out of Windows



-- 
Take a Deep Breath out of Windows

Re: Some points about IM integration

Hi, all.

This thread is not that long, so I've read it all. I'm yet another
native Chinese user.

I agree with the idea of Taylor's origin post.

Some people want framework of frameworks. I appreciate their efforts.
However, I don't think this make sense if we consider long-term.

If someone is trying to make thing simpler and more elegant, go ahead.

I like the Mac OS X way of language settings. I'm happy to see GNOME
is catching up.

I don't know how much integration is done in code. But I think you
should examine both IBus and Fcitx carefully before hardcode anything.
I think the internally more elegant one should be picked.

From various discussion I've seen, many experienced user would see
Fcitx to IBus migration as a serious regression. So be careful.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

What's wrong with GBus? Except that some people think it should be GFcitx?

I haven't seen any single IMF being continually active over the years.
But GNOME is always active. Even if GNOME 3 changed many things. I can
still recognize Apps like Gedit and File-Roller.

If would be if a carefully selected IMF goes into freedesktop.org
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Tue, May 15, 2012 at 7:27 AM, Owen Taylor otay...@redhat.com 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.

 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.


no offense, but if Chinese or CJK Community is a small group(I think
I've already be clear about what CJK users are doing today. they'are
the nowadays tweakers you called. why? because you didn't ship what
they want. you know, IM is the most famous workaround in i18n world),
GNOME Asia can be shutdown.

so is Chinese or CJK Community a small group or second class? say
that in public in Hong Kong.

so do not make any hypothesis you don't even know about.

I've heard enough of this and feel great disrespect.

assume: if world factory think, oh, english users has little
feedback in Chinese. so they're a small group. then ship any kind of
clothes, shoes they like to Europe market. will you buy it?
absolutely and apparently no.

then that's the case GNOME will face.

I've also heard enough of oh, then the only solution is to drop
GNOME in Chinese Community about this affair.

I'm okay about it. they're users, I as a packager can't force they
choose what they like.

and today they still, although the choice range is becoming narrower
but still, have choices. KDE/xfce.

I'm okay about it. no matter what they will use, they're still my
target as a packager.

but can you be okay about it?

can you even dare a little bit to say CJK is not important? no.

then pretty much GNOME developers will leave GNOME tomorrow.

that's the worst case we both never want to see it ever happens.

if no users/local developers, who will you develop an IM for?

sorry for my wording, but it really drives me crazy.

I think mutual respect is the basis for multi-culture communication.

 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.


yes and no. your will is good and respectful.

but have you ever discussed it with downstream distributions?

I cc-ed openSUSE GNOME Community leader, Vincent, to see what he will
think on this.

yes, I agree and thanks for, some of GNOME applications are god-like
good, but GNOME itself is not GOD to make decisions for
users/distributions/others.

or maybe tomorrow you would like to say oh, we should take
responsibility to write a new kernel, we should take responsibility to
reinvent YaST2? that's what you think arrogantly and will certainly
do if you find upstream doesn't accept you proposal.

want to take responsibility is under the hypothesis that the ones
who nowadays had already taken responsibility want to share. but have
you ever asked?

no. at least Vincent will feel surprised on this.

who will judge the right experience? users themselves.

so what if they do not even ever want/like your
over-responsibility-driven product?

that's the case right now.

oh, we should take responsibility to ship an IM we think users like,
while actually a large  group of its users are using and will use a
totally different tool.

what you think, does not, and will not, even ever matters.

 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.


that's what distributions nowadays are doing. and users said, say and
will say, I like it.

they enjoy this freedom feeling.

I think tomorrow I will be a millionaire doesn't make any sense.

do respect reality.

 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

Re: 3.6 Feature: IBus/XKB integration

On Tue, May 15, 2012 at 3:47 PM, Ma Xiaojun damage3...@gmail.com wrote:
 What's wrong with GBus? Except that some people think it should be GFcitx?


are you mad?

do you ever know there's a desktop environment called KDE?

 I haven't seen any single IMF being continually active over the years.
 But GNOME is always active. Even if GNOME 3 changed many things. I can
 still recognize Apps like Gedit and File-Roller.

 If would be if a carefully selected IMF goes into freedesktop.org

you self-explained why IBUS/FCITX themselves  can't be a standard.


btw, I'll never reply your to argue because I just want to argue
email any more, and will clean all your non-sense replies on my
personal blog.

we developers/maintainers certainly will not feed the troll.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

On Tue, May 15, 2012 at 4:45 PM, Marguerite Su i...@marguerite.su wrote:
 do you ever know there's a desktop environment called KDE?
I know KDE from day one. GNOME can do things differently. And I
support what I feel right.

 you self-explained why IBUS/FCITX themselves  can't be a standard.
I'm sorry. I cannot figure out your reasons.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration


(05/15/12 15:28), Marguerite Su-san wrote:

On Tue, May 15, 2012 at 11:11 AM, Takao Fujiwaratfuji...@redhat.com  wrote:

Hi,

I'm working on the ibus integration.


(05/13/12 13:31), Justin Wong-san wrote:


Well this is how ibus is done, as u can see, ugly.

but i should say  users would never see this long long menu, because this
menu provides 13 kinds of input methods for users, where normal users use
less than 3 input methods, this screenshot is just to show ibus can
provide so many IMs



The long menu has been enhanced in the latest ibus-gjs gtk3-vala branch. But
it still do not work in other distros because we're discussing how the
internal patches are resolved.
Probably the latest will be available for other distros soon.
We're still discussing the better UI.


   https://extensions.gnome.org/extension/261/kimpanel/
 
https://extensions.gnome.org/extension/68/input-method-status-indicator/



Sorry, it's a bit old as I explained above.
It would miss some important features against the last ibus-gjs. E.g. using
libgnomekbd and preloaded xkb engines.
Yes, ibus-gjs does not support fcitx because upstream suggests to pick up
one input method as the implementation itself would be possible.



Welcome! fujuwara, as IBus developer!

I'm glad to see this thread diversified.

that sounds a little sad to me actually.

then others really have to reinvent the wheels...and if deep
integrated, to reinvent the wheels really hard.


Currently I suggest an option to check ibus-1.0.pc in configure.ac whether 
gnome-shell enables ibus or not.
So probably I think the default recommended IMF would be ibus but it can be 
configured by each distros.
I'm also thinking ibus-gjs provides the same UI with keyboard indicator when 
ibus-daemon is not running.




fujiwara

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





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

Re: Some points about IM integration

2012-05-15 Thread Sergey Udaltsov

 I've heard enough of this and feel great disrespect.
Please Marguerite, let's not get personal (or even national) on this
thread. You should know better than occusing people who sincerelly
want GNOME to provide the best - and do not mean any nationalism or
disrespect.

But really there is another side to it. The worst thing that happened
to GNOME3 comparing to GNOME2 is that for nearly every aspect GNOME3
is trying to find THE solution (for the valid reason of polished UX) -
and without specifying managed interfaces, all other solutions just
have zero chance to compete (so THE solution immediately becomes THE
ONLY POSSIBLE solution). I am really excited to see that this approach
demonstrates its fundamental weakness in case of IMs - that gives
another chance to everyone to think about general GNOME strategy, to
start thinking in terms of interfaces, not particular implementations.

I understand that GNOME devs would be happy to choose IBus as the
default solution, since it is most GNOME-oriented and the integration
can be as tight as GNOME high UX standards would require. Quite
possible that is sane. But it was told here that IBus (fundamentally?)
lacks some substantial features that other IM frameworks have - so why
IBus should be the only possible option?

Let's have defaul solution - the best point of compromise between
language support, UX, developers attitude to GNOME etc etc. But let's
not make it the only possible solution.

I hope noone is going to fallback to the worst possible argument it
is FOSS, you can always patch it - I would consider it as some kind
of Godwin law for FOSS architectures.

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

Re: 3.6 Feature: IBus/XKB integration

On Tue, May 15, 2012 at 5:07 PM, Takao Fujiwara tfuji...@redhat.com wrote:
(05/15/12 15:28), Marguerite Su-san wrote:

On Tue, May 15, 2012 at 11:11 AM, Takao Fujiwaratfuji...@redhat.com
wrote:

Hi,

I'm working on the ibus integration.

(05/13/12 13:31), Justin Wong-san wrote:

Well this is how ibus is done, as u can see, ugly.

but i should say users would never see this long long menu, because
this
menu provides 13 kinds of input methods for users, where normal users
use
less than 3 input methods, this screenshot is just to show ibus can
provide so many IMs

The long menu has been enhanced in the latest ibus-gjs gtk3-vala branch.
But
it still do not work in other distros because we're discussing how the
internal patches are resolved.
Probably the latest will be available for other distros soon.
We're still discussing the better UI.

https://extensions.gnome.org/extension/261/kimpanel/
https://extensions.gnome.org/extension/68/input-method-status-indicator/

Sorry, it's a bit old as I explained above.
It would miss some important features against the last ibus-gjs. E.g.
using
libgnomekbd and preloaded xkb engines.
Yes, ibus-gjs does not support fcitx because upstream suggests to pick up
one input method as the implementation itself would be possible.

Welcome! fujuwara, as IBus developer!

I'm glad to see this thread diversified.

that sounds a little sad to me actually.

then others really have to reinvent the wheels...and if deep
integrated, to reinvent the wheels really hard.

Currently I suggest an option to check ibus-1.0.pc in configure.ac whether
gnome-shell enables ibus or not.
So probably I think the default recommended IMF would be ibus but it can be
configured by each distros.
I'm also thinking ibus-gjs provides the same UI with keyboard indicator when
ibus-daemon is not running.

Hi, thank you for your understanding. Well actually I'm worry about this commit

http://git.gnome.org/browse/gnome-settings-daemon/commit/?h=wip/input-sourcesid=fbdac0e6dc39b32fc386f391f227e31a05a39670

Which might make gtk im module being set and maybe not easy to override.

As far as I read gnome-shell code, seems it can work without ibus.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Tue, May 15, 2012 at 4:40 PM, Marguerite Su i...@marguerite.su wrote:
 no offense, but if Chinese or CJK Community is a small group(I think
 I've already be clear about what CJK users are doing today. they'are
 the nowadays tweakers you called. why? because you didn't ship what
 they want. you know, IM is the most famous workaround in i18n world),
 GNOME Asia can be shutdown.
AFAIK, GNOME never maintained a distro. Some distros don't maintain
CJK input well. That's why some people tweaks. So why not solve the
CJK input problem in GNOME and you packagers can have a rest?

 so is Chinese or CJK Community a small group or second class? say
 that in public in Hong Kong.
 so do not make any hypothesis you don't even know about.
 I've heard enough of this and feel great disrespect.
 assume: if world factory think, oh, english users has little
 feedback in Chinese. so they're a small group. then ship any kind of
 clothes, shoes they like to Europe market. will you buy it?
 absolutely and apparently no.
 then that's the case GNOME will face.
I haven't seen any FOSS projects have this kind of mindsets.
Complaint is not always bad.
Please show people a link or something so motivated people can help
solving problems.

 I've also heard enough of oh, then the only solution is to drop
 GNOME in Chinese Community about this affair.
 I'm okay about it. they're users, I as a packager can't force they
 choose what they like.
 and today they still, although the choice range is becoming narrower
 but still, have choices. KDE/xfce.
 I'm okay about it. no matter what they will use, they're still my
 target as a packager.
 but can you be okay about it?
 can you even dare a little bit to say CJK is not important? no.
 then pretty much GNOME developers will leave GNOME tomorrow.
 that's the worst case we both never want to see it ever happens.
 if no users/local developers, who will you develop an IM for?
 sorry for my wording, but it really drives me crazy.
 I think mutual respect is the basis for multi-culture communication.
I'm tired of this kind of arguments. When some people see
regression/breakage, they just switch to other things without think
twice. I don't this is the way any local or global FOSS community
should work. I try to report a bug for FOSS whenever I'm sure there is
a problem.

 yes and no. your will is good and respectful.
 but have you ever discussed it with downstream distributions?
 I cc-ed openSUSE GNOME Community leader, Vincent, to see what he will
 think on this.
 yes, I agree and thanks for, some of GNOME applications are god-like
 good, but GNOME itself is not GOD to make decisions for
 users/distributions/others.
 or maybe tomorrow you would like to say oh, we should take
 responsibility to write a new kernel, we should take responsibility to
 reinvent YaST2? that's what you think arrogantly and will certainly
 do if you find upstream doesn't accept you proposal.
 want to take responsibility is under the hypothesis that the ones
 who nowadays had already taken responsibility want to share. but have
 you ever asked?
 no. at least Vincent will feel surprised on this.
 who will judge the right experience? users themselves.
 so what if they do not even ever want/like your
 over-responsibility-driven product?
 that's the case right now.
 oh, we should take responsibility to ship an IM we think users like,
 while actually a large  group of its users are using and will use a
 totally different tool.
 what you think, does not, and will not, even ever matters.
 that's what distributions nowadays are doing. and users said, say and
 will say, I like it.
 they enjoy this freedom feeling.
 I think tomorrow I will be a millionaire doesn't make any sense.
 do respect reality.
Whether GNOME, as an international FOSS project, can make CJK input
better or worse in this integration process is highly dependent on
whether there is effective participation of native CJK users. This
need efforts from both sides. But I'm enthusiastic about that.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

(05/15/12 18:12), Weng Xuetian-san wrote:

On Tue, May 15, 2012 at 5:07 PM, Takao Fujiwaratfuji...@redhat.com wrote:

(05/15/12 15:28), Marguerite Su-san wrote:

On Tue, May 15, 2012 at 11:11 AM, Takao Fujiwaratfuji...@redhat.com
wrote:

Hi,

I'm working on the ibus integration.

(05/13/12 13:31), Justin Wong-san wrote:

Well this is how ibus is done, as u can see, ugly.

https://extensions.gnome.org/extension/261/kimpanel/

https://extensions.gnome.org/extension/68/input-method-status-indicator/

Welcome! fujuwara, as IBus developer!

I'm glad to see this thread diversified.

that sounds a little sad to me actually.

then others really have to reinvent the wheels...and if deep
integrated, to reinvent the wheels really hard.

Hi, thank you for your understanding. Well actually I'm worry about this commit

http://git.gnome.org/browse/gnome-settings-daemon/commit/?h=wip/input-sourcesid=fbdac0e6dc39b32fc386f391f227e31a05a39670

Which might make gtk im module being set and maybe not easy to override.

As far as I read gnome-shell code, seems it can work without ibus.

Ah, I didn't test the part of g-s-d yet in fact.
Personally I'd like to talk with desktop team later if a module could be
acceptable likes /usr/lib*/gnome-settings-daemon-*/libibus.so .

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

Re: Some points about IM integration

2012-05-15 Thread Vincent Untz

Marguerite,

(First, no need to cc me, I'm obviously subscribed to desktop-devel-list
:-))

Le mardi 15 mai 2012, à 16:40 +0800, Marguerite Su a écrit :
 On Tue, May 15, 2012 at 7:27 AM, Owen Taylor otay...@redhat.com 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.
 
  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.
 
 
 no offense, but if Chinese or CJK Community is a small group(I think
 I've already be clear about what CJK users are doing today. they'are
 the nowadays tweakers you called. why? because you didn't ship what
 they want. you know, IM is the most famous workaround in i18n world),
 GNOME Asia can be shutdown.
 
 so is Chinese or CJK Community a small group or second class? say
 that in public in Hong Kong.

I feel you misunderstood what Owen wrote. My understanding is that when
Owen is talking about a small group here, it would only be a small group
because our goal is to have GNOME work well by default for most people,
including most users of the CJK community. If we manage to do that, then
only a small number of people would need to do some changes (like using
a different input method framework).

Now, there's obviously the question of whether this goal is achievable:
can we cover the needs of most users (including most users of the CJK
community) with one input method framework? Some people in this thread
seems to think it's possible, while others believe it's not. I can't
answer this as I've no background on input methods in general.

It would surely help to have some simple wiki page summarizing the
current state of ibus and fctix, both as frameworks in general as well
as for the availability and state of their plugins. People have been
trying to tell the pros and cons of both in various mails, but I don't
think anybody really managed to get a global view because of the number
of mails.

[...]

  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.
 
 yes and no. your will is good and respectful.
 
 but have you ever discussed it with downstream distributions?
 
 I cc-ed openSUSE GNOME Community leader, Vincent, to see what he will
 think on this.

Hrm, I'm not sure what you expect me to say here :-) This is the way
GNOME has been working for a while. For instance, this is why GNOME has
tight integration with NetworkManager and PulseAudio. Of course, this
raises challenges for integrators downstream (as well as for some
advanced users) and I'm very well aware of this. But we feel (where we
= GNOME) it helps us build a better user experience.

Cheers,

Vincent

-- 
Les gens heureux ne sont pas pressés.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

On Tue, May 15, 2012 at 5:07 PM, Takao Fujiwara tfuji...@redhat.com wrote:
 (05/15/12 15:28), Marguerite Su-san wrote:

 On Tue, May 15, 2012 at 11:11 AM, Takao Fujiwaratfuji...@redhat.com
  wrote:

 Hi,

 I'm working on the ibus integration.


 (05/13/12 13:31), Justin Wong-san wrote:


 Well this is how ibus is done, as u can see, ugly.

 but i should say  users would never see this long long menu, because
 this
 menu provides 13 kinds of input methods for users, where normal users
 use
 less than 3 input methods, this screenshot is just to show ibus can
 provide so many IMs



 The long menu has been enhanced in the latest ibus-gjs gtk3-vala branch.
 But
 it still do not work in other distros because we're discussing how the
 internal patches are resolved.
 Probably the latest will be available for other distros soon.
 We're still discussing the better UI.

       https://extensions.gnome.org/extension/261/kimpanel/
     
 https://extensions.gnome.org/extension/68/input-method-status-indicator/



 Sorry, it's a bit old as I explained above.
 It would miss some important features against the last ibus-gjs. E.g.
 using
 libgnomekbd and preloaded xkb engines.
 Yes, ibus-gjs does not support fcitx because upstream suggests to pick up
 one input method as the implementation itself would be possible.


 Welcome! fujuwara, as IBus developer!

 I'm glad to see this thread diversified.

 that sounds a little sad to me actually.

 then others really have to reinvent the wheels...and if deep
 integrated, to reinvent the wheels really hard.


 Currently I suggest an option to check ibus-1.0.pc in configure.ac whether
 gnome-shell enables ibus or not.
 So probably I think the default recommended IMF would be ibus but it can be
 configured by each distros.
 I'm also thinking ibus-gjs provides the same UI with keyboard indicator when
 ibus-daemon is not running.



 fujiwara

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





Hi, fujiwara!

hugs and thanks with all my heart!

it's totally acceptable to me and distribution.

you saved the world again!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Tue, May 15, 2012 at 5:45 PM, Vincent Untz vu...@gnome.org wrote:
 It would surely help to have some simple wiki page summarizing the
 current state of ibus and fctix, both as frameworks in general as well
 as for the availability and state of their plugins. People have been
 trying to tell the pros and cons of both in various mails, but I don't
 think anybody really managed to get a global view because of the number
 of mails.
I cannot agree more.
I just registered a Wikia page for you guys.
http://cjkinput.wikia.com/wiki/CJK_Input_Wiki
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

XOXO, Vuntz,

at first I want to declare a big progress Weng and Takao made in the
other thread.

IBUS won't be compulsory. it will be optional. distribution can customize it.

it's enough for me.

actually I started my thread because I thought IBus will be compulsory
for my openSUSE distro who is planning to rely on Fcitx gradually.

now I got my answer.

then this thread will turn to be a developers' talk about how to make
it better in tech details. in which field I have no idea to express
and no knowledge thus no word to say.

so it's my time to say, Goodbye.

(of course as a Foss distro maintainer, I'll watch this.)

On Tue, May 15, 2012 at 5:45 PM, Vincent Untz vu...@gnome.org wrote:
 Marguerite,

 (First, no need to cc me, I'm obviously subscribed to desktop-devel-list
 :-))

 Le mardi 15 mai 2012, à 16:40 +0800, Marguerite Su a écrit :
 On Tue, May 15, 2012 at 7:27 AM, Owen Taylor otay...@redhat.com 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.
 
  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.
 

 no offense, but if Chinese or CJK Community is a small group(I think
 I've already be clear about what CJK users are doing today. they'are
 the nowadays tweakers you called. why? because you didn't ship what
 they want. you know, IM is the most famous workaround in i18n world),
 GNOME Asia can be shutdown.

 so is Chinese or CJK Community a small group or second class? say
 that in public in Hong Kong.

 I feel you misunderstood what Owen wrote. My understanding is that when
 Owen is talking about a small group here, it would only be a small group
 because our goal is to have GNOME work well by default for most people,
 including most users of the CJK community. If we manage to do that, then
 only a small number of people would need to do some changes (like using
 a different input method framework).

 Now, there's obviously the question of whether this goal is achievable:
 can we cover the needs of most users (including most users of the CJK
 community) with one input method framework? Some people in this thread
 seems to think it's possible, while others believe it's not. I can't
 answer this as I've no background on input methods in general.

 It would surely help to have some simple wiki page summarizing the
 current state of ibus and fctix, both as frameworks in general as well
 as for the availability and state of their plugins. People have been
 trying to tell the pros and cons of both in various mails, but I don't
 think anybody really managed to get a global view because of the number
 of mails.


Vuntz, I have a detailed blog about this in tech details I know.

so maybe I can post it on our EN WIKI or lizards.opensuse.org (BTW,
I'm a Member!)

they're just some basic points of IM. it won't help much on IM development.

but it'll be pretty much easy for maintainers to catch up.

(like I said, after James Su left SuSE, no one can understand his work any more)

 [...]

  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.

 yes and no. your will is good and respectful.

 but have you ever discussed it with downstream distributions?

 I cc-ed openSUSE GNOME Community leader, Vincent, to see what he will
 think on this.

 Hrm, I'm not sure what you expect me to say here :-) This is the way
 GNOME has been working for a while. For instance, this is why GNOME has
 tight integration with NetworkManager and PulseAudio. Of course, this
 raises challenges for integrators downstream (as well as for some
 advanced users) and I'm very well aware of this. But we feel (where we
 = GNOME) it helps us build a better user experience.


I at first thought GNOME is planning to grab free options from users
and distros.

like we openSUSE choose fcitx as default IM, but we can do nothing on
IBUS then. then we won't choose fcitx any more. because we don't like
to act fool. the we have no freedom to choose our distros default IM.

but apparently not.

I got promise from Takao.

so Vincent, maybe you can say, Congrats? XD.

Marguerite

 Cheers,

 Vincent

 --
 Les gens heureux

Re: 3.6 Feature: IBus/XKB integration

(05/15/12 15:37), Marguerite Su-san wrote:

On Tue, May 15, 2012 at 11:38 AM, Takao Fujiwaratfuji...@redhat.com wrote:

(05/14/12 21:34), Christophe Fergeau-san wrote:

This leads to my next question, this thread so far has been focused on
CJK (and Vietnamese in this email). Are they the only languages that
needs input methods? Or are they needed too for arabic, hebrew,
thailandese, ... ? If yes, is fcitx the IM framework to use for these
too?

I think all IM framework should support the available languages.
Maybe I need to check some status but I don't see any critical problems.

yes. both IMs now supports.

Having an IM abstraction framework has been one recommended by some
people in this thread. One concern I have with that is that the
fragmentation we have now will stay, and we'll have the foo IM
framework which will be favoured by people who want to input language
A, the bar IM framework will be the best for language B. In such a
situation, people who want to input both A and B (think A speaker
learning the B language) will not get a satisfying user experience.

Finally, please correct me if I misunderstood, but after reading the
thread, I'm under the impression that ibus and fcitx work equally well
to input CJK characters (except for a few ibus bugs that I guess
could be fixed?). What makes fcitx better is that it provides advanced
functionalities such as word autocompletion (+ highly customizable
autocompletion window and online autocompletion lists), macros
(short key sequences that will get replaced by a full word), ... My
feeling about these advanced functionalities is that they are not
really CJK-specific, and that this could be useful too when typing
English or French texts, in which case this may be worth integrating
at a higher level instead of having this in the input method? I guess
the answer is that they are different things, but asking does not hurt
;)

The implementation design would be more important for me.
Actually I didn't think the autocompletion is so important but it would be
an each IM engine's issue while ibus-european-table provide that feature.
Probably I don't think focusing each IM engine would be good to pick up the
default IM framework since it would be engines' issues.

see, that's the design conflicts.

autocompletion directly matters to user on issue if they can input really fast.

so it should be a framework's work instead of engines.

if framework's good at it, every engine can benefit. like if GTK's
good at drawing windows fast, every gtk application will benefit.

yes, focusing on engines won't help, because we're discussing IMF.

Probably I'd like to disable the autocompletion when Japanese input method is enabled so I'm thinking it's better to handle it by each engine or out
of ibus likes GtkEntry.

BTW, auto-completion could unveil the passwords:
https://bugzilla.redhat.com/show_bug.cgi?id=803646

fujiwara

Christophe

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

Re: Some points about IM integration

2012-05-15 Thread Florian Müllner

On Tue, May 15, 2012 at 10:40 AM, Marguerite Su i...@marguerite.su wrote:

 On Tue, May 15, 2012 at 7:27 AM, Owen Taylor otay...@redhat.com wrote:
  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.

 no offense, but if Chinese or CJK Community is a small group(I think
 I've already be clear about what CJK users are doing today. they'are
 the nowadays tweakers you called. why? because you didn't ship what
 they want.



Please, no reason to get offended - assume well and everything. I'm sure
what Owen meant is the following:

The group of CJK users who tweak / replace the IM (because the
out-of-the-box experience sucks) is small compared to the group of CJK
users who don't use free software / GNOME at all (because the
out-of-the-box experience sucks).

Introducing another level of abstraction (IM framework framework) may
make the first group happy, but it doesn't help the second group at all.
Making the out-off-the-box experience not suck on the other hand should
benefit *all* CJK users.


so is Chinese or CJK Community a small group or second class? say
 that in public in Hong Kong.


Well, according to your own words, GNOME does not ship what [CJK users]
want - I guess you can call that second class. The whole idea of
integrating IM into the core desktop rather than keeping it as an
after-thought is to make CJK users *first* class citizens. So again, please
don't feel offended.


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

Re: 3.6 Feature: IBus/XKB integration

On Tue, May 15, 2012 at 6:18 PM, Takao Fujiwara tfuji...@redhat.com wrote:
 (05/15/12 15:37), Marguerite Su-san wrote:

 On Tue, May 15, 2012 at 11:38 AM, Takao Fujiwaratfuji...@redhat.com
  wrote:

 (05/14/12 21:34), Christophe Fergeau-san wrote:


 This leads to my next question, this thread so far has been focused on
 CJK (and Vietnamese in this email). Are they the only languages that
 needs input methods? Or are they needed too for arabic, hebrew,
 thailandese, ... ? If yes, is fcitx the IM framework to use for these
 too?



 I think all IM framework should support the available languages.
 Maybe I need to check some status but I don't see any critical problems.


 yes. both IMs now supports.



 Having an IM abstraction framework has been one recommended by some
 people in this thread. One concern I have with that is that the
 fragmentation we have now will stay, and we'll have the foo IM
 framework which will be favoured by people who want to input language
 A, the bar IM framework will be the best for language B. In such a
 situation, people who want to input both A and B (think A speaker
 learning the B language) will not get a satisfying user experience.

 Finally, please correct me if I misunderstood, but after reading the
 thread, I'm under the impression that ibus and fcitx work equally well
 to input CJK characters (except for a few ibus bugs that I guess
 could be fixed?). What makes fcitx better is that it provides advanced
 functionalities such as word autocompletion (+ highly customizable
 autocompletion window and online autocompletion lists), macros
 (short key sequences that will get replaced by a full word), ... My
 feeling about these advanced functionalities is that they are not
 really CJK-specific, and that this could be useful too when typing
 English or French texts, in which case this may be worth integrating
 at a higher level instead of having this in the input method? I guess
 the answer is that they are different things, but asking does not hurt
 ;)



 The implementation design would be more important for me.
 Actually I didn't think the autocompletion is so important but it would
 be
 an each IM engine's issue while ibus-european-table provide that feature.
 Probably I don't think focusing each IM engine would be good to pick up
 the
 default IM framework since it would be engines' issues.


 see, that's the design conflicts.

 autocompletion directly matters to user on issue if they can input really
 fast.

 so it should be a framework's work instead of engines.

 if framework's good at it, every engine can benefit. like if GTK's
 good at drawing windows fast, every gtk application will benefit.

 yes, focusing on engines won't help, because we're discussing IMF.


 Probably I'd like to disable the autocompletion when Japanese input method
 is enabled so I'm thinking it's better to handle it by each engine or out of
 ibus likes GtkEntry.

 BTW, auto-completion could unveil the passwords:
 https://bugzilla.redhat.com/show_bug.cgi?id=803646



 fujiwara


 Christophe

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


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




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

Hope this feature can be implemented in gtk and clutter in near future
https://bugzilla.gnome.org/show_bug.cgi?id=651244

Thus the input widget is password or not can be easily know by input method.

My implementation for im module of gtk/qt in fcitx is to send a flag and
indicate it's password, if so input method will pass by the key.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

another 3.6 feature: harfbuzz

2012-05-15 Thread Matthias Clasen

After talking to Behdad last weekend, I've filed another 3.6 feature
page for the long-awaited move to harfbuzz 1.0.
It took a long time, but it is finally going to happen this cycle.

For more details, see https://live.gnome.org/ThreePointFive/Features/Harfbuzz
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration


On (05/15/2012 07:37 PM), Weng Xuetian-san wrote:

BTW, auto-completion could unveil the passwords:
https://bugzilla.redhat.com/show_bug.cgi?id=803646


Hope this feature can be implemented in gtk and clutter in near future
https://bugzilla.gnome.org/show_bug.cgi?id=651244

Thus the input widget is password or not can be easily know by input method.

My implementation for im module of gtk/qt in fcitx is to send a flag and
indicate it's password, if so input method will pass by the key.


It's not a GtkEntry problem and ibus already resolves the GtkEntry.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

2012-05-15 Thread Matthias Clasen

On Tue, May 15, 2012 at 6:37 AM, Weng Xuetian wen...@gmail.com wrote:

 Hope this feature can be implemented in gtk and clutter in near future
 https://bugzilla.gnome.org/show_bug.cgi?id=651244

If you think this is an important feature, please help getting it
landed by commenting on some of the open questions in the bug.

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

Re: Some points about IM integration

独裁无胆，民主无量，打着为民着想的旗号强奸民意，一句资源有限就可以免于全部责任

去吧，发展葛弄姆特色的自由软件

Go on your work, hurt more fans and lose more users

sent from android
On May 15, 2012 7:28 AM, Owen Taylor otay...@redhat.com 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.

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.

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.

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.

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!

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.

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*.

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.

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.

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.

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.

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

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

Re: gnome goals for 3.6

2012-05-15 Thread Joanmarie Diggs

Hey Matthias.

On 05/15/2012 12:31 AM, Matthias Clasen wrote:
 At the release team meeting last weekend, we've discussed that we want
 to revitalize the Gnome Goals [1] effort by adopting a few goals for
 this cycle. We've chosen the following goals:
 
 GSettingsMigration
 XDGConfigFolders
 PortToGtkApplication
 PortToGMenu
 RemoveMarkupInMessages

[...]

 The last one was included because we want to include our translators,
 and make their life easier by improving the quality of our strings.

+1 I'm doing Orca's right now.

I suspect, however, what would make the lives of our translators even
easier than the elimination of markup is NoUnexplainedStrings. :) In
other words, all strings which we expect translated should have a
translator note explaining what that string is and means. Whether or not
that can be done in time for 3.6 is not for me to say. But I think it is
worthy of consideration as a GNOME Goal.

Take care.
--joanie
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Xu Pengfei

hi, guys

I saw this bad news from
http://linuxtoy.org/archives/gnome-and-cjk-community-debates-about-ibus-integration-of-gnome-3-6.html

It's a chinese linux news blog, Do you know how to input those characters?
I think the input is the most important things of a desktop.
If i can't input,no mater how beautiful or powerful the desktop is, it is a
rubbish.

To the BOSS,

If Mr. Linus said the kernel will only support KDE, and KDE will be the
standard UI, what will you do?
I don't care which one is the default IM, i just care about that i can
choose the best one i like.

BTW:I like Gnome2 but not 3. i feel Gnome 3 is terrible on my pc.

2012/5/15 Justin Wong justin.w...@gmail.com

独裁无胆，民主无量，打着为民着想的旗号强奸民意，一句资源有限就可以免于全部责任

去吧，发展葛弄姆特色的自由软件

Go on your work, hurt more fans and lose more users

sent from android
On May 15, 2012 7:28 AM, Owen Taylor otay...@redhat.com 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.

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.

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.

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.

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*.

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

Re: Some points about IM integration

Imagine, just imagine one day a desktop environment named the Kernel
Desktop Environment (KDE), would be integrated to linux kernel for better
user experience. U guys argue for kernel should not integrate a DE, then
Linus Torvalds come out and say:

On May 15, 2012 7:28 AM, Owen Taylor otay...@redhat.com 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.


If we choose KDE as defualt and unchangable DE of linux, it doesn't make
linux like proprietary software from micro$oft, because linux will still be
100% free software, and will still be developed in the open by the linux
community.

 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.


Linux is not an OS for tweakers and enthusiastics, it's an OS for users, we
want to give the choice of using free software to everybodym this is much
more fundamental form of choice than giving a small groups of users the
ability to swap out a different DE underneath linux.

 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.


 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.


So we cannot leave it up to one linux distributor to combine linux with
gnome to make a linux distribution that works well for gtk softwares or
lxde to make it works well for lightweight lovers and so on...

Mac OS X and Windows both have *only one* DE in there OSs, and I'm happy
that Linux is catching on.

We are developing a Desktop *Enviroment*, users can still choose Dektop
Softwares to meet their needs, the point is , we should use *one single
enviroment* for better experience, better bug reports and so on.

The KDE team has been engaged to integrate with linux since linux 3.42,
because the lack of resource, we can not both integrate KDE and GNOME, we
cannot integrate 2 different Desktop *Environments*.

Because of your arguments, I think gnome users should not be ignored, so
which do u think is better and be qualified to integrate with linux kernel?
KDE or GNOME?

 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!

 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.

 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*.

 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.

 Finally, using a single input method framework is pretty much essential to
 the goal of allowing users to configure

Re: Some points about IM integration

2012-05-15 Thread Yu Shao

I want to add more background on ibus as I watched Huang Peng developed 
it from scratch back to few years ago in Beijing.


One of the main ideas behind ibus was to implement The Specification of 
the IM engine Service Provider Interface which was jointly developed by 
CJK(China, Japan, Korea) IM developers/experts through Northeast Asia 
OSS Forum[1]. You might still find the specification online, otherwise I 
could help to find the doc and post it here. The specification itself 
was coming from about 2 years discussion among the best IM developers 
from China Japan and Korea at the time.


Ibus was firstly written in python initially as the proof of the concept 
of the CJK IM specification, later on rewritten in C to provide the 
necessary performance, mostly following the ideas from the 
specification. So, ibus had inherited all of the best practice coming 
from all CJK countries.


So, I am here want to purpose, it is probably a time for all of the 
input method developer to concentrate on a unified input method 
framework, CJK IM specification is a very good starting point, then 
let's focus more on the input engines(such as pinyin or wubi).


Shao

[1] http://www.neaossforum.org/

On 05/15/2012 07:27 AM, Owen Taylor 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.

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.

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.

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.

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!

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.

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*.

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.

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.

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

Re: Some points about IM integration

On Wed, May 16, 2012 at 12:05 AM, Justin Wong justin.w...@gmail.com wrote:
 Imagine, just imagine one day a desktop environment named the Kernel Desktop
 Environment (KDE), would be integrated to linux kernel for better user
 experience. U guys argue for kernel should not integrate a DE, then Linus
 Torvalds come out and say:
 If we choose KDE as defualt and unchangable DE of linux, it doesn't make
 linux like proprietary software from micro$oft, because linux will still be
 100% free software, and will still be developed in the open by the linux
 community.
 Linux is not an OS for tweakers and enthusiastics, it's an OS for users, we
 want to give the choice of using free software to everybodym this is much
 more fundamental form of choice than giving a small groups of users the
 ability to swap out a different DE underneath linux.
 So we cannot leave it up to one linux distributor to combine linux with
 gnome to make a linux distribution that works well for gtk softwares or lxde
 to make it works well for lightweight lovers and so on...
 Mac OS X and Windows both have *only one* DE in there OSs, and I'm happy
 that Linux is catching on.
 We are developing a Desktop *Enviroment*, users can still choose Dektop
 Softwares to meet their needs, the point is , we should use *one single
 enviroment* for better experience, better bug reports and so on.
 The KDE team has been engaged to integrate with linux since linux 3.42,
 because the lack of resource, we can not both integrate KDE and GNOME, we
 cannot integrate 2 different Desktop *Environments*.
Sounds like ReactOS or Haiku?
http://www.reactos.org/
http://www.haiku-os.org/
Linux being the most flexible kernel doesn't imply that every FOSS
kernel should be that flexible. It's free software, you can always
switch or fork.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Tue, May 15, 2012 at 10:40:03AM +0800, Aron Xu wrote:
 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.

Cool that you have that idea, but raising things like this is *not*
related at all to the subject. Either be specific, or don't post.

I have zero interest to see things about how GNOME might be viewed as
well as your thoughts on GNOME OS.

You mentioned not wanting to start a flame war. Please also don't start
one yourself.

-- 
Regards,
Olav (moderator)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Juanjo Marín



 De: Justin Wong justin.w...@gmail.com
CC: desktop-devel-list@gnome.org 
Enviado: Martes 15 de Mayo de 2012 18:05
Asunto: Re: Some points about IM integration
 

Imagine, just imagine one day a desktop environment named the Kernel Desktop 
Environment (KDE), would be integrated to linux kernel for better user 
experience. U guys argue for kernel should not integrate a DE, then Linus 
Torvalds come out and say:

On May 15, 2012 7:28 AM, Owen Taylor otay...@redhat.com 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.

If we choose KDE as defualt and unchangable DE of linux, it doesn't make linux 
like proprietary software from micro$oft, because linux will still be 100% 
free software, and will still be developed in the open by the linux community.





Please, keep the focus on the problem: Providing a good input method support in 
GNOME.
The election of a single IM framework, or not, is a matter of implementation, 
that users 

don't care as long as problem is solved and the solution can be maintained by 
the 

community.


Cheers,

 -- Juanjo Marin

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

Re: Some points about IM integration

On Wed, May 16, 2012 at 12:05:40AM +0800, Justin Wong wrote:
 If we choose KDE as defualt and unchangable DE of linux, it doesn't make
 linux like proprietary software from micro$oft, because linux will still be
 100% free software, and will still be developed in the open by the linux
 community.

This is completely offtopic. Please be specific in your argumentation.

The topic is how IM can be integrated.

-- 
Regards,
Olav (moderator)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Tue, May 15, 2012 at 11:04:06PM +0800, Xu Pengfei wrote:
 hi, guys
 
 I saw this bad news from
 http://linuxtoy.org/archives/gnome-and-cjk-community-debates-about-ibus-integration-of-gnome-3-6.html
 
 It's a chinese linux news blog, Do you know how to input those characters?
 I think the input is the most important things of a desktop.
 If i can't input,no mater how beautiful or powerful the desktop is, it is a
 rubbish.
 
 To the BOSS,
 
 If Mr. Linus said the kernel will only support KDE, and KDE will be the
 standard UI, what will you do?
 I don't care which one is the default IM, i just care about that i can
 choose the best one i like.
 
 BTW:I like Gnome2 but not 3. i feel Gnome 3 is terrible on my pc.

Hi,

Trolling is not acceptable. You've been banned.


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

Re: Some points about IM integration

All what I want to say is gnome should NOT use one single IMF, just like
linux should NOT use only one DE !

There IS a solution to integrate multiple IMFs! And u just ignore ignore
and ignore this solution because of your laziness!

It's not the question which imf is better, it's the question u are doing a
abusolutely and completely WRONG thing!

No matter which imf you choose, fcitx or ibus, that means tens of
developers' work will be worth nonthing!

*STOP this WRONG work and prevent gnome from RETROGRESSING!!*

sent from android
On May 16, 2012 12:55 AM, Juanjo Marín juanjomari...@yahoo.es wrote:



  De: Justin Wong justin.w...@gmail.com
 CC: desktop-devel-list@gnome.org
 Enviado: Martes 15 de Mayo de 2012 18:05
 Asunto: Re: Some points about IM integration
 
 
 Imagine, just imagine one day a desktop environment named the Kernel
Desktop Environment (KDE), would be integrated to linux kernel for better
user experience. U guys argue for kernel should not integrate a DE, then
Linus Torvalds come out and say:
 
 On May 15, 2012 7:28 AM, Owen Taylor otay...@redhat.com 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.
 
 If we choose KDE as defualt and unchangable DE of linux, it doesn't make
linux like proprietary software from micro$oft, because linux will still be
100% free software, and will still be developed in the open by the linux
community.
 
 
 


 Please, keep the focus on the problem: Providing a good input method
support in GNOME.
 The election of a single IM framework, or not, is a matter of
implementation, that users

 don't care as long as problem is solved and the solution can be
maintained by the

 community.


 Cheers,

  -- Juanjo Marin

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

Re: Some points about IM integration

On Wed, May 16, 2012 at 1:05 AM, Justin Wong justin.w...@gmail.com wrote:
 All what I want to say is gnome should NOT use one single IMF, just like
 linux should NOT use only one DE !
False Analogy.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

For newcomers / IBus/IM users: RULES FOR THIS LIST

Just as a short introduction:

You can discuss pretty much anything on this list as long as it follows
a few rules (from https://live.gnome.org/CodeOfConduct):
* be constructive
  Weird comparisons and so on are not constructive (KDE, GNOME 2,
  dictators, etc).
  Stating that something is bad *not* constructive (explain *why* it is
  bad).
* be polite
* assume people mean well
  nobody is out to make your life difficult. Explain what you need out
  of an IM, what it should do. That'll result in developers making a
  better decision.
* be respectful and considerate
  Even if the other person is not. Contact me if you dislike a certain
  message. I have the abilities to act.
* try to be concise
  sending loads of emails or very long ones (needlessly so) will just
  result in people ignoring or missing what you mean
* be patient and generous


I'm the person who can administrate the list. I highly enjoy
discussions. People can disagree all they want. Always interesting to
learn more.

However, if above rules aren't followed I *will* step in. Again, this
won't be related to your opinion.

-- 
Regards,
Olav (moderator)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Tue, May 15, 2012 at 09:43:41PM +0800, Justin Wong wrote:
 独裁无胆，民主无量，打着为民着想的旗号强奸民意，一句资源有限就可以免于全部责任
 
 去吧，发展葛弄姆特色的自由软件
 
 Go on your work, hurt more fans and lose more users

Trolling is not acceptable. Disagree all you want but be specific. Else
I'll ban you.

-- 
Regards,
Olav (moderator)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Wed, May 16, 2012 at 01:05:46AM +0800, Justin Wong wrote:
 There IS a solution to integrate multiple IMFs! And u just ignore ignore
 and ignore this solution because of your laziness!

Your tone is not acceptable. Consider yourself banned.

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

Re: Some points about IM integration

2012-05-15 Thread Alan Cox

On Wed, 16 May 2012 00:05:40 +0800
Justin Wong justin.w...@gmail.com wrote:

 Imagine, just imagine one day a desktop environment named the Kernel
 Desktop Environment (KDE), would be integrated to linux kernel for better
 user experience.

We've got one .. it's called the console. It has an assorted set of
problems with Chinese fonts, and no input method support.

There is a difficult balance between integration and flexibility. DRI and
X is a good example of how tricky that can be.

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

Re: 3.6 Feature: IBus/XKB integration

On Tue, May 15, 2012 at 04:45:36PM +0800, Marguerite Su wrote:
 On Tue, May 15, 2012 at 3:47 PM, Ma Xiaojun damage3...@gmail.com wrote:
  What's wrong with GBus? Except that some people think it should be GFcitx?
 
 
 are you mad?

Getting personal is not acceptable on this list.

 do you ever know there's a desktop environment called KDE?

Be specific in your argumentation or don't make the argument.


The topic is the integration within *GNOME*. It doesn't matter if
something also works for KDE or not.

-- 
Regards,
Olav (moderator)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Bastien Nocera

On Tue, 2012-05-15 at 17:55 +0800, Ma Xiaojun wrote:
 On Tue, May 15, 2012 at 5:45 PM, Vincent Untz vu...@gnome.org wrote:
  It would surely help to have some simple wiki page summarizing the
  current state of ibus and fctix, both as frameworks in general as well
  as for the availability and state of their plugins. People have been
  trying to tell the pros and cons of both in various mails, but I don't
  think anybody really managed to get a global view because of the number
  of mails.
 I cannot agree more.
 I just registered a Wikia page for you guys.
 http://cjkinput.wikia.com/wiki/CJK_Input_Wiki

For GNOME related wiki pages, it's better to use the Wiki at
http://live.gnome.org/

All the GNOME contributors have access to it, and it's better to
integrate it with other design pages.

Could you move the page you created to live.gnome.org? Post the name of
the page afterwards, and we'll make sure somebody puts it in the right
place.

Cheers

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

Re: Some points about IM integration

2012-05-15 Thread Aron Xu

On Wed, May 16, 2012 at 12:54 AM, Olav Vitters o...@vitters.nl wrote:
 On Tue, May 15, 2012 at 10:40:03AM +0800, Aron Xu wrote:
 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.

 Cool that you have that idea, but raising things like this is *not*
 related at all to the subject. Either be specific, or don't post.

 I have zero interest to see things about how GNOME might be viewed as
 well as your thoughts on GNOME OS.

 You mentioned not wanting to start a flame war. Please also don't start
 one yourself.


As you are one of the moderators, please don't try to blame someone
based on your very first impression, read the whole post and you'll
find whether it's related. What you have just quoted is rumor, but
it is something that happens right away as far as I can see for IMF
related issue here:

1.GNOME is trying to have IMF integration - cool stuff.
2.But it is warned by specialized people that the plan is broken - can
lead to poor implementation and breakage.
3.People insist on having it right now for 3.6 - then must work hard
on fix-ups in the future.
4.As said before, if IBus is getting replaced - then re-work the whole thing.

I sincerely would like to see both the thread and all the people calm
down and think more about it, then come around it some time later.

I believe everyone who would like to be involved in the implementation
wants to see something constructive, not tempered, not trollish, and
not rushing. Then I'd like to propose all the IBus related work in
wip/input-sources branch of the following components being suspended
at once:
  gnome-control-center
  gnome-shell
  gnome-settings-daemon
  gsettings-desktop-schemas
This feature should postponed at least for GNOME 3.6, even if we have
agreed on something, six months is too short for producing an almost
good release for users according to the current situation.

For future discussions, we will try to make GNOME developers
understand what input method really is and know about user's
requirements. Then we, including GNOME people, IBus developers and
Fcitx developers sit down together to figure out what's the right way
to do, as re-implementing things is painful at least for users, who
really suffer from the result.

--
Regards,
Aron Xu
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

Sorry for being mad, no offence to u.

First I would say I approve GNOME to integrate with an IMF, and even choose
one IMF as defualt.

BUT, IMF must be switchable.

As I have said for several times, provide a interface that IMFs can be well
integrated with GNOME.

There is a solution too satisfy multipul IMFs, but our points' are just
Ignored , even though Wen Xuetian has said he can prove it with code!

GNOME provide machanism, IMFs provide implementation.

It's not time to discuss WHICH IMF should be integrated, it's time to
discuss HOW IMF can be integrated.

I know it will not be a easy job, but it's something that should be done.

Whichever IMF u now choose as the only IMF for gnome, u are KILLING othe
IMFs, so do u think other IMFs' developers work worth nothing?

PLEASE, calm down, slow down, and discuss about how to provide a machanism,
and how IMFs can be integrated.

P.S. Ma said u can switch and fork, yes, surely I can do, but GNOME user
will suffer an dirty hacked input system, that's too selfish.

sent from android
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Jasper St. Pierre

Is there any reason that picking one input method framework is bad, if
we do it right? If the experience sucks and users have to switch to
another input method framework, yes, we've done it wrong, as Owen says
in the original email. But if it works pretty much out of the box for
all cases, what's wrong with tight integration?

We already have several hard requirements, out of practicality. GNOME
chose GTK+ as our main toolkit. GNOME chose PulseAudio as our main
sound server. We do this because we don't have the resources to
support Qt or EFL or Motif or Xaw. Nor do we have the resources to
support ESD or OSS.

I doubt we have the resources to support both IBus and FCITX, and
provide a good experience for both. Individual distributions may, but
that's their call, not GNOME's.

As for the prove it with code argument, it's not a data point until
it happens. When it happens, I may switch my opinion.

On Tue, May 15, 2012 at 2:41 PM, Justin Wong bigea...@xdlinux.info wrote:
 Sorry for being mad, no offence to u.

 First I would say I approve GNOME to integrate with an IMF, and even choose
 one IMF as defualt.

 BUT, IMF must be switchable.

 As I have said for several times, provide a interface that IMFs can be well
 integrated with GNOME.

 There is a solution too satisfy multipul IMFs, but our points' are just
 Ignored , even though Wen Xuetian has said he can prove it with code!

 GNOME provide machanism, IMFs provide implementation.

 It's not time to discuss WHICH IMF should be integrated, it's time to
 discuss HOW IMF can be integrated.

 I know it will not be a easy job, but it's something that should be done.

 Whichever IMF u now choose as the only IMF for gnome, u are KILLING othe
 IMFs, so do u think other IMFs' developers work worth nothing?

 PLEASE, calm down, slow down, and discuss about how to provide a machanism,
 and how IMFs can be integrated.

 P.S. Ma said u can switch and fork, yes, surely I can do, but GNOME user
 will suffer an dirty hacked input system, that's too selfish.

 sent from android


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



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

Re: Some points about IM integration

On Wed, May 16, 2012 at 1:39 AM, Aron Xu aro...@gnome.org wrote:
 1.GNOME is trying to have IMF integration - cool stuff.
 2.But it is warned by specialized people that the plan is broken - can
 lead to poor implementation and breakage.
 3.People insist on having it right now for 3.6 - then must work hard
 on fix-ups in the future.
 4.As said before, if IBus is getting replaced - then re-work the whole thing.
Such bad cycle can happen in any software projects.

 I sincerely would like to see both the thread and all the people calm
 down and think more about it, then come around it some time later.
 I believe everyone who would like to be involved in the implementation
 wants to see something constructive, not tempered, not trollish, and
 not rushing. Then I'd like to propose all the IBus related work in
 wip/input-sources branch of the following components being suspended
 at once:
  gnome-control-center
  gnome-shell
  gnome-settings-daemon
  gsettings-desktop-schemas
 This feature should postponed at least for GNOME 3.6, even if we have
 agreed on something, six months is too short for producing an almost
 good release for users according to the current situation.
 For future discussions, we will try to make GNOME developers
 understand what input method really is and know about user's
 requirements. Then we, including GNOME people, IBus developers and
 Fcitx developers sit down together to figure out what's the right way
 to do, as re-implementing things is painful at least for users, who
 really suffer from the result.
Would the situation change if we suspend the work now?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Bastien Nocera

On Wed, 2012-05-16 at 01:41 +0800, Justin Wong wrote:
 Sorry for being mad, no offence to u.
 
 First I would say I approve GNOME to integrate with an IMF, and even
 choose one IMF as defualt.
 
 BUT, IMF must be switchable.

We already mentioned that we want the features to be in the engines from
each framework, if there needs to be multiple engines. Swappable IMFs
just means more unreproduceable bugs, more moving parts so more bugs in
general and a bad out-of-the-box experience.

 As I have said for several times, provide a interface that IMFs can be
 well integrated with GNOME.

Whether IMFs or something, you cannot add more options, have more moving
parts and have less bugs. In fact, you'd end up with the bugs from all
the IMFs.

 There is a solution too satisfy multipul IMFs, but our points' are
 just Ignored , even though Wen Xuetian has said he can prove it with
 code!

Your points aren't ignored. We already explained why we don't want
multiple IMFs for GNOME.

 GNOME provide machanism, IMFs provide implementation.
 
 It's not time to discuss WHICH IMF should be integrated, it's time to
 discuss HOW IMF can be integrated.
 
 I know it will not be a easy job, but it's something that should be
 done.
 
 Whichever IMF u now choose as the only IMF for gnome, u are KILLING
 othe IMFs, so do u think other IMFs' developers work worth nothing?

The other IMFs will likely continue to exist. They will require users to
make changes to their systems to use them (just like right now if you're
not using the default IMF for your distribution), and you won't have
integrated preferences (just like right now).

 PLEASE, calm down, slow down, and discuss about how to provide a
 machanism, and how IMFs can be integrated.

If we choose to merge integration based on IBus (because of a variety of
reasons), then two things can happen:
- Developers of other Input Frameworks can start creating patches to the
upstream GNOME to provide a better integration than the default choice.
- They choose to start working on the selected IMF because it's the
selected IMF
- They choose to concentrate on other desktops

In all cases, the implementation will evolve, and the integration will
get better. I don't want to have the choice between 2 equally badly
integrated IMFs for GNOME.

Cheers

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

Re: Some points about IM integration

On Wed, May 16, 2012 at 1:41 AM, Justin Wong bigea...@xdlinux.info wrote:
 There is a solution too satisfy multipul IMFs, but our points' are just
 Ignored , even though Wen Xuetian has said he can prove it with code!
Should be Weng Xuetian :)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Bastien Nocera

On Wed, 2012-05-16 at 01:39 +0800, Aron Xu wrote:
 On Wed, May 16, 2012 at 12:54 AM, Olav Vitters o...@vitters.nl wrote:
  On Tue, May 15, 2012 at 10:40:03AM +0800, Aron Xu wrote:
  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.
 
  Cool that you have that idea, but raising things like this is *not*
  related at all to the subject. Either be specific, or don't post.
 
  I have zero interest to see things about how GNOME might be viewed as
  well as your thoughts on GNOME OS.
 
  You mentioned not wanting to start a flame war. Please also don't start
  one yourself.
 
 
 As you are one of the moderators, please don't try to blame someone
 based on your very first impression, read the whole post and you'll
 find whether it's related. What you have just quoted is rumor, but
 it is something that happens right away as far as I can see for IMF
 related issue here:
 
 1.GNOME is trying to have IMF integration - cool stuff.
 2.But it is warned by specialized people that the plan is broken - can
 lead to poor implementation and breakage.
 3.People insist on having it right now for 3.6 - then must work hard
 on fix-ups in the future.
 4.As said before, if IBus is getting replaced - then re-work the whole thing.

If IBus gets replaced, then it gets replaced. Code doesn't just
disappear and I'm pretty sure that code can be adapted rather than
completely trashed and having to restart from scratch.

 I sincerely would like to see both the thread and all the people calm
 down and think more about it, then come around it some time later.
 
 I believe everyone who would like to be involved in the implementation
 wants to see something constructive, not tempered, not trollish, and
 not rushing. Then I'd like to propose all the IBus related work in
 wip/input-sources branch of the following components being suspended
 at once:
   gnome-control-center
   gnome-shell
   gnome-settings-daemon
   gsettings-desktop-schemas

Why should the work be suspended? People are working on this, and
actually making progress. Where are the better implementations for
fcitx integration in GNOME? See below as well.

 This feature should postponed at least for GNOME 3.6, even if we have
 agreed on something, six months is too short for producing an almost
 good release for users according to the current situation.
 
 For future discussions, we will try to make GNOME developers
 understand what input method really is and know about user's
 requirements. Then we, including GNOME people, IBus developers and
 Fcitx developers sit down together to figure out what's the right way
 to do, as re-implementing things is painful at least for users, who
 really suffer from the result.

The only reason one would make noise in this thread would be if they
wanted to have either
1. fcitx integrated (rather than IBus)
or
2. thought that we should make Input Method frameworks swappable

2. isn't an option, as already discussed. For 1., we should in fact
merge the IBus support as soon as possible, and have fcitx developers
show us how they can do the integration better. A lot of the code should
be reusable, and you can show how much more awesome and complete your
favourite IMF is.

Cheers

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

Re: Some points about IM integration

On May 16, 2012 2:08 AM, Bastien Nocera had...@hadess.net wrote:

 On Wed, 2012-05-16 at 01:41 +0800, Justin Wong wrote:
  Sorry for being mad, no offence to u.
 
  First I would say I approve GNOME to integrate with an IMF, and even
  choose one IMF as defualt.
 
  BUT, IMF must be switchable.

 We already mentioned that we want the features to be in the engines from
 each framework, if there needs to be multiple engines. Swappable IMFs
 just means more unreproduceable bugs, more moving parts so more bugs in
 general and a bad out-of-the-box experience.

  As I have said for several times, provide a interface that IMFs can be
  well integrated with GNOME.

 Whether IMFs or something, you cannot add more options, have more moving
 parts and have less bugs. In fact, you'd end up with the bugs from all
 the IMFs.

  There is a solution too satisfy multipul IMFs, but our points' are
  just Ignored , even though Wen Xuetian has said he can prove it with
  code!

 Your points aren't ignored. We already explained why we don't want
 multiple IMFs for GNOME.

  GNOME provide machanism, IMFs provide implementation.
 
  It's not time to discuss WHICH IMF should be integrated, it's time to
  discuss HOW IMF can be integrated.
 
  I know it will not be a easy job, but it's something that should be
  done.
 
  Whichever IMF u now choose as the only IMF for gnome, u are KILLING
  othe IMFs, so do u think other IMFs' developers work worth nothing?

 The other IMFs will likely continue to exist. They will require users to
 make changes to their systems to use them (just like right now if you're
 not using the default IMF for your distribution), and you won't have
 integrated preferences (just like right now).


That's what I mean switchable, but I really doubt that, if even clutter
has been integrated to one specific IMF.

  PLEASE, calm down, slow down, and discuss about how to provide a
  machanism, and how IMFs can be integrated.

 If we choose to merge integration based on IBus (because of a variety of
 reasons), then two things can happen:
 - Developers of other Input Frameworks can start creating patches to the
 upstream GNOME to provide a better integration than the default choice.
 - They choose to start working on the selected IMF because it's the
 selected IMF
 - They choose to concentrate on other desktops

 In all cases, the implementation will evolve, and the integration will
 get better. I don't want to have the choice between 2 equally badly
 integrated IMFs for GNOME.

 Cheers

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

Re: Some points about IM integration

2012-05-15 Thread Aron Xu

On Wed, May 16, 2012 at 2:19 AM, Bastien Nocera had...@hadess.net wrote:
 On Wed, 2012-05-16 at 01:39 +0800, Aron Xu wrote:
 On Wed, May 16, 2012 at 12:54 AM, Olav Vitters o...@vitters.nl wrote:
  On Tue, May 15, 2012 at 10:40:03AM +0800, Aron Xu wrote:
  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.
 
  Cool that you have that idea, but raising things like this is *not*
  related at all to the subject. Either be specific, or don't post.
 
  I have zero interest to see things about how GNOME might be viewed as
  well as your thoughts on GNOME OS.
 
  You mentioned not wanting to start a flame war. Please also don't start
  one yourself.
 

 As you are one of the moderators, please don't try to blame someone
 based on your very first impression, read the whole post and you'll
 find whether it's related. What you have just quoted is rumor, but
 it is something that happens right away as far as I can see for IMF
 related issue here:

 1.GNOME is trying to have IMF integration - cool stuff.
 2.But it is warned by specialized people that the plan is broken - can
 lead to poor implementation and breakage.
 3.People insist on having it right now for 3.6 - then must work hard
 on fix-ups in the future.
 4.As said before, if IBus is getting replaced - then re-work the whole thing.

 If IBus gets replaced, then it gets replaced. Code doesn't just
 disappear and I'm pretty sure that code can be adapted rather than
 completely trashed and having to restart from scratch.


This is not a strong claim because you even don't have the basic ideas
about input methods right now, which is the reason for why I want all
the work get suspended at once.

 I sincerely would like to see both the thread and all the people calm
 down and think more about it, then come around it some time later.

 I believe everyone who would like to be involved in the implementation
 wants to see something constructive, not tempered, not trollish, and
 not rushing. Then I'd like to propose all the IBus related work in
 wip/input-sources branch of the following components being suspended
 at once:
   gnome-control-center
   gnome-shell
   gnome-settings-daemon
   gsettings-desktop-schemas

 Why should the work be suspended? People are working on this, and
 actually making progress. Where are the better implementations for
 fcitx integration in GNOME? See below as well.


Actually current experience with Fcitx's kimpanel plugin for
gnome-shell is much better than IBus already, the progress in those
branches are re-inventing things in IBus to catch up with Fcitx in the
first place.

 This feature should postponed at least for GNOME 3.6, even if we have
 agreed on something, six months is too short for producing an almost
 good release for users according to the current situation.

 For future discussions, we will try to make GNOME developers
 understand what input method really is and know about user's
 requirements. Then we, including GNOME people, IBus developers and
 Fcitx developers sit down together to figure out what's the right way
 to do, as re-implementing things is painful at least for users, who
 really suffer from the result.

 The only reason one would make noise in this thread would be if they
 wanted to have either
 1. fcitx integrated (rather than IBus)
 or
 2. thought that we should make Input Method frameworks swappable


This is not true. The valid one should be something like the following points:

1.We want to have better input experience for input method users of
GNOME, as the already integrated XKB stuff.

2.Forcibly choose between IBus and Fcitx is not a good idea because
most people around still doesn't have the concept of what is IMF and
why foo can be better than bar.

3.Whether it will be a hard dependency is subject to discussion among
related developers, and it is very likely to be not necessary if you
understand the current design of Fcitx.

4.If it is feasible to not hardcode, why do that? Having a recommended
implementation in GNOME is something good, but only hardcode when
necessary and being agreed by related people.

5.GNOME need listen to CJK developers before trying to assume things on IMF.

 2. isn't an option, as already discussed. For 1., we should in fact
 merge the IBus support as soon as possible, and have fcitx developers
 show us how they can do the integration better. A lot of the code should
 be reusable, and you can show how much more awesome and complete your
 favourite IMF is.

 Cheers


See above. It isn't something absolute, so please suspend right now,
listen and discuss first.

--
Regards,
Aron Xu
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

On Wed, May 16, 2012 at 2:19 AM, Bastien Nocera had...@hadess.net wrote:
 On Wed, 2012-05-16 at 01:39 +0800, Aron Xu wrote:
 On Wed, May 16, 2012 at 12:54 AM, Olav Vitters o...@vitters.nl wrote:
  On Tue, May 15, 2012 at 10:40:03AM +0800, Aron Xu wrote:
  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.
 
  Cool that you have that idea, but raising things like this is *not*
  related at all to the subject. Either be specific, or don't post.
 
  I have zero interest to see things about how GNOME might be viewed as
  well as your thoughts on GNOME OS.
 
  You mentioned not wanting to start a flame war. Please also don't start
  one yourself.
 

 As you are one of the moderators, please don't try to blame someone
 based on your very first impression, read the whole post and you'll
 find whether it's related. What you have just quoted is rumor, but
 it is something that happens right away as far as I can see for IMF
 related issue here:

 1.GNOME is trying to have IMF integration - cool stuff.
 2.But it is warned by specialized people that the plan is broken - can
 lead to poor implementation and breakage.
 3.People insist on having it right now for 3.6 - then must work hard
 on fix-ups in the future.
 4.As said before, if IBus is getting replaced - then re-work the whole thing.

 If IBus gets replaced, then it gets replaced. Code doesn't just
 disappear and I'm pretty sure that code can be adapted rather than
 completely trashed and having to restart from scratch.

 I sincerely would like to see both the thread and all the people calm
 down and think more about it, then come around it some time later.

 I believe everyone who would like to be involved in the implementation
 wants to see something constructive, not tempered, not trollish, and
 not rushing. Then I'd like to propose all the IBus related work in
 wip/input-sources branch of the following components being suspended
 at once:
   gnome-control-center
   gnome-shell
   gnome-settings-daemon
   gsettings-desktop-schemas

 Why should the work be suspended? People are working on this, and
 actually making progress. Where are the better implementations for
 fcitx integration in GNOME? See below as well.

 This feature should postponed at least for GNOME 3.6, even if we have
 agreed on something, six months is too short for producing an almost
 good release for users according to the current situation.

 For future discussions, we will try to make GNOME developers
 understand what input method really is and know about user's
 requirements. Then we, including GNOME people, IBus developers and
 Fcitx developers sit down together to figure out what's the right way
 to do, as re-implementing things is painful at least for users, who
 really suffer from the result.

 The only reason one would make noise in this thread would be if they
 wanted to have either
 1. fcitx integrated (rather than IBus)
 or
 2. thought that we should make Input Method frameworks swappable

 2. isn't an option, as already discussed. For 1., we should in fact
 merge the IBus support as soon as possible, and have fcitx developers
 show us how they can do the integration better. A lot of the code should
 be reusable, and you can show how much more awesome and complete your
 favourite IMF is.


Actually I don't quite favor continue this discussion, part of my
object is actually accomplished.
Thank for your guys support, though some of speech is not quite acceptable.

As being developer one of my point is to provide better experience for
user, this has never conflicted with Gnome nor IBus. And actually I
really prefer the way to talk with what we have done, but not we
will done.

Understood other project requirement is also important for me.

For hackers like me, they will always be way :).

Actually I'd say, to others, even if, even if only ibus available
gnome, and I can still make my way for fcitx in gnome.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

Hi, all.

I've started the documentation process of CJK Input.
https://live.gnome.org/InputCJK

It just contains trivial information currently. But I will add content
from time to time.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Aron Xu

On Wed, May 16, 2012 at 3:20 AM, Ma Xiaojun damage3...@gmail.com wrote:
 Hi, all.

 I've started the documentation process of CJK Input.
 https://live.gnome.org/InputCJK

 It just contains trivial information currently. But I will add content
 from time to time.

Looks great, thanks for bringing us a good start!

--
Regards,
Aron Xu
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Jasper St. Pierre

On Tue, May 15, 2012 at 4:20 PM, Ma Xiaojun damage3...@gmail.com wrote:
 Hi, all.

 I've started the documentation process of CJK Input.
 https://live.gnome.org/InputCJK

Thanks, this looks like a good start!

 It just contains trivial information currently. But I will add content
 from time to time.
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

Re: Some points about IM integration

2012-05-15 Thread Rovanion Luckey

Greetings all,

This fall I and three other students did an accessibility study in which
Dasher was a part. One of the issues we encountered was that the user after
having typed it's sentence or any other text into Dasher had to copy and
paste it into the application they were actually using. And if they later
discovered an issue in the text they'd have to copy it back to Dasher, edit
it and then copy and paste it to the application again.

If this hasn't changed since then and without having any knowledge of the
input management code or the Dasher code I would like to ask a question:
Wouldn't it be great to have Dasher appear when a text field is activated
in Gnome much like it does on Android[1]?

The Input Manager is called when the text area is activated. It then puts
characters in the field. This has been a great success on Android with the
most popular keyboard in the store being installed on about 100.000
devices. Couldn't something of the sorts be done in Gnome for on screen
keyboards, accessibility tools and other input managers like the one
discussed in this thread? They all seem to do the same thing, just in
different ways.

Now forgive me if these topics aren't related and thank you for your time.

[1]http://i.imgur.com/LAY1s.png
-- 
www.twitter.com/Rovanion
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: Initial setup

2012-05-15 Thread Krzysztof Walo

On Thu, 2012-05-03 at 10:49 -0400, Colin Walters wrote:
 On Mon, 2012-04-23 at 22:41 +0200, Krzysztof Walo wrote:
 
  Wouldn't it be better if it looked like this:
  1. Ask user necessary questions (language, name, time zone?)
  2. Launch desktop session
  3. Let user configure it
  4. Install system
  
  4th step would only require to setup partitions and copy user
  configuration to hard drive - as few questions, as possible.
 
 I agree with this - it's tricky though.  What we would need is a
 way to track the configuration made during the live phase and apply
 it after installation.  It's like the Sabayon problem.


I think if user's home directory is created before start of livecd
session, all is needed is to just copy it to hard drive, if user chooses
to install the system.

Step 1 creates user's home on livecd (squashfs). Step 4 copies it to
hard drive, including changes made in step 3. There might be few global
settings that need to be copied as well ie. NetworkManager.

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

Re: Please check your sources for strings not marked for translation before release

2012-05-15 Thread Jorge González

Hello,

On Mon, May 7, 2012 at 1:59 PM, Kenneth Nielsen k.nielse...@gmail.com wrote:
 Hallo developers.

 Since the release of GNOME 3.4 we have received a steady stream of emails
 saying This is not a string freeze break, we just forgot to mark the
 strings for translation. So much so, that the statistics e.g. for my
 language (which has not been touched since release) now counts 63*
 untranslated or fuzzy strings in a source that was at 0 at release time,
 three weeks ago.

 I understand the reason for not counting marking existing strings as a
 string freeze break. But please understand that even though you are in your
 right to fix things like this post release, and even though it off course
 makes sense to do it, it does not mean that it is not annoying and a burden
 for translators.

 The reason for this is that we concentrate large amounts of work in the
 period just before release (where string changes are relatively quiet), so
 therefore it is also an advantage for us if we can finish as much of it as
 possible in that period (of course also because a lot of us has an extra hat
 as distribution translators for distributions that follow within a month or
 so of the gnome release). On top of that, small updates are
 uncharacteristically expensive in a work/string-sense because they involve
 the same amount of emails back and forth for proofreading and git work.

 So please... If you could make a bit more of an effort of checking your
 sources for non-internationalized strings before release that would be
 great. IMHO 63 is just a bit on the high side of where this number should be
Can't this be half-automatized? like with a bash script that checks
the strings, which are marked and which not?
It could be helpful.


 Regards Kenneth
Kind regards.


 * These 63 off course also include genuinely new strings due e.g. to bug
 fixes.
 ___
 gnome-i18n mailing list
 gnome-i...@gnome.org
 http://mail.gnome.org/mailman/listinfo/gnome-i18n



-- 
Jorge González González alor...@gmail.com
Weblog: http://aloriel.turismogoogle.net
Weblog: http://turismogoogle.net
Fotolog: http://www.flickr.com/photos/aloriel
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Please check your sources for strings not marked for translation before release

2012-05-15 Thread F Wolff

Op Ma, 2012-05-07 om 13:59 +0200 skryf Kenneth Nielsen:
 Hallo developers.
 
 Since the release of GNOME 3.4 we have received a steady stream of 
 emails saying This is not a string freeze break, we just forgot to mark 
 the strings for translation. So much so, that the statistics e.g. for 
 my language (which has not been touched since release) now counts 63* 
 untranslated or fuzzy strings in a source that was at 0 at release time, 
 three weeks ago.
 
 I understand the reason for not counting marking existing strings as a 
 string freeze break. But please understand that even though you are in 
 your right to fix things like this post release, and even though it off 
 course makes sense to do it, it does not mean that it is not annoying 
 and a burden for translators.
 
 The reason for this is that we concentrate large amounts of work in the 
 period just before release (where string changes are relatively quiet), 
 so therefore it is also an advantage for us if we can finish as much of 
 it as possible in that period (of course also because a lot of us has an 
 extra hat as distribution translators for distributions that follow 
 within a month or so of the gnome release). On top of that, small 
 updates are uncharacteristically expensive in a work/string-sense 
 because they involve the same amount of emails back and forth for 
 proofreading and git work.
 
 So please... If you could make a bit more of an effort of checking your 
 sources for non-internationalized strings before release that would be 
 great. IMHO 63 is just a bit on the high side of where this number should be
 
 Regards Kenneth
 
 * These 63 off course also include genuinely new strings due e.g. to bug 
 fixes.

I tried to write some notes a while ago that might help a bit: 
https://live.gnome.org/TranslationProject/DevGuidelines/Test%20internationalization

Keep well
Friedel


-- 
Recently on my blog:
http://translate.org.za/blogs/friedel/en/content/survey-about-usability-virtaal

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

Re: Please check your sources for strings not marked for translation before release

2012-05-15 Thread Daniel Mustieles García

I think it should be a small shell-script that would detect strings
nos marked for translation, using the _ function.

For example, in gnome-packagekit/src folder, I've ran the following command:

 egrep -i label.*\(\ * |grep -v _(

To detect all the «gtk_label_new» without a translatable string. Here
is the output:

gpk-distro-upgrade.c:   priv-status_label = gtk_label_new (This is
where the status goes);
gpk-update-viewer.c:info_mobile_label = gtk_label_new ();

In this case... is the first line a bug? Should that string be translatable?

Using grep with the appropiate patterns (gtk_label_new is just an
example, it should also detect print, printf, etc functions) would
detect most of the non marked for translation strings. Also, it should
be easy to add it to git command, so it could show a warning it ther
user is commiting a source code file with strings not marked for
translation.

My 2 cents ;-)

2012/5/7 F Wolff frie...@translate.org.za:
 Op Ma, 2012-05-07 om 13:59 +0200 skryf Kenneth Nielsen:
 Hallo developers.

 Since the release of GNOME 3.4 we have received a steady stream of
 emails saying This is not a string freeze break, we just forgot to mark
 the strings for translation. So much so, that the statistics e.g. for
 my language (which has not been touched since release) now counts 63*
 untranslated or fuzzy strings in a source that was at 0 at release time,
 three weeks ago.

 I understand the reason for not counting marking existing strings as a
 string freeze break. But please understand that even though you are in
 your right to fix things like this post release, and even though it off
 course makes sense to do it, it does not mean that it is not annoying
 and a burden for translators.

 The reason for this is that we concentrate large amounts of work in the
 period just before release (where string changes are relatively quiet),
 so therefore it is also an advantage for us if we can finish as much of
 it as possible in that period (of course also because a lot of us has an
 extra hat as distribution translators for distributions that follow
 within a month or so of the gnome release). On top of that, small
 updates are uncharacteristically expensive in a work/string-sense
 because they involve the same amount of emails back and forth for
 proofreading and git work.

 So please... If you could make a bit more of an effort of checking your
 sources for non-internationalized strings before release that would be
 great. IMHO 63 is just a bit on the high side of where this number should be

 Regards Kenneth

 * These 63 off course also include genuinely new strings due e.g. to bug
 fixes.

 I tried to write some notes a while ago that might help a bit:
 https://live.gnome.org/TranslationProject/DevGuidelines/Test%20internationalization

 Keep well
 Friedel


 --
 Recently on my blog:
 http://translate.org.za/blogs/friedel/en/content/survey-about-usability-virtaal

 ___
 gnome-i18n mailing list
 gnome-i...@gnome.org
 http://mail.gnome.org/mailman/listinfo/gnome-i18n
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

application menu design - contributing to the wiki on live.gnome.org

2012-05-15 Thread Pigeon Lips

Hi All,  a very friendly person on the gnome IRC put me on this mailing
list.

Long story short i wanted to add an article to your design wiki
https://live.gnome.org/Design/Playground but thought it best to run it by
someone first.

after reading this https://live.gnome.org/Design/Whiteboards/Menus i was
inspired by the mega menu. I would like to try a mock up of extending this
concept further and wanted a place to post my thoughts, mock ups and
suggestions on how a nice mega menu could be extended via search and
context driven actions.

Is this an ok thing to do, or do i need to flesh out the idea here first ?

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

Re: Some points about IM integration

民主无量，独裁无胆
一句 资源有限 就试图为自己托则，简直就是共产党

Go on your work, ignore and lose more users!

sent from android
On May 15, 2012 7:28 AM, Owen Taylor otay...@redhat.com 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.

 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.

 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.

 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.

 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!

 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.

 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*.

 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.

 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.

 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.

 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.

 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


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

Re: Some points about IM integration

Sorry for being mad, no offence to u.

As I have said for sevral times, provide a interface that IMFs can be well
integrated with GNOME

but our points' are just ignored , even though Wen Xuetian has said he can
prove it with code!  ( even code cannot convince u, i am disappointed)

GNOME provide machanism, IMFs provide implementation, that's my point.

I know it will not be a easy job, but it's something that should be done.

Whichever IMF u now choose as the only IMF for gnome, u are KILLING othe
IMFs, so do u think other IMFs' developers work worth nothing?

PLEASE, calm down, slow down, and discuss about how to provide a machanism,
and how IMFs can be integrated.

sent from android
On May 16, 2012 12:58 AM, Olav Vitters o...@vitters.nl wrote:
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

Sorry for being mad, no offence to u.

As I have said for sevral times, provide a interface that IMFs can be well
integrated with GNOME, but our points' are just
Ignored by u, even though Wen Xuetian has said he can prove it with code!

GNOME provide machanism, IMFs provide implementation.

I know it will not be a easy job, but it's something that should be done.

Whichever IMF u now choose as the only IMF for gnome, u are KILLING othe
IMFs, so do u think other IMFs' developers work worth nothing?

PLEASE, calm down, slow down, and discuss about how to provide a machanism,
and how IMFs can be integrated.

sent from android
On May 16, 2012 12:58 AM, Olav Vitters o...@vitters.nl wrote:

 On Wed, May 16, 2012 at 12:05:40AM +0800, Justin Wong wrote:
  If we choose KDE as defualt and unchangable DE of linux, it doesn't make
  linux like proprietary software from micro$oft, because linux will still
 be
  100% free software, and will still be developed in the open by the linux
  community.

 This is completely offtopic. Please be specific in your argumentation.

 The topic is how IM can be integrated.

 --
 Regards,
 Olav (moderator)
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

Re: Some points about IM integration

Sorry for being mad, no offence to u.

First I would say I approve  GNOME to integrate with an IMF, and even
choose one IMF as defualt.

BUT, IMF must be switchable.

As I have said for several times, provide a interface that IMFs can be well
integrated with GNOME.

There is a solution too satisfy multipul IMFs,  but our points' are just
Ignored , even though Wen Xuetian has said he can prove it with code!

GNOME provide machanism, IMFs provide implementation.

It's not time to discuss WHICH IMF should be integrated, it's time to
discuss HOW IMF can be integrated.

I know it will not be a easy job, but it's something that should be done.

Whichever IMF u now choose as the only IMF for gnome, u are KILLING othe
IMFs, so do u think other IMFs' developers work worth nothing?

PLEASE, calm down, slow down, and discuss about how to provide a machanism,
and how IMFs can be integrated.

P.S.   Ma said u can switch and fork, yes, surely I can do,  but GNOME
user will suffer an dirty hacked input system, that's too selfish.
On May 16, 2012 12:58 AM, Olav Vitters o...@vitters.nl wrote:

 On Wed, May 16, 2012 at 12:05:40AM +0800, Justin Wong wrote:
  If we choose KDE as defualt and unchangable DE of linux, it doesn't make
  linux like proprietary software from micro$oft, because linux will still
 be
  100% free software, and will still be developed in the open by the linux
  community.

 This is completely offtopic. Please be specific in your argumentation.

 The topic is how IM can be integrated.

 --
 Regards,
 Olav (moderator)
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

Re: gnome goals for 3.6

2012-05-15 Thread Piotr Drąg

2012/5/15 Joanmarie Diggs jdi...@igalia.com:
 On 05/15/2012 12:31 AM, Matthias Clasen wrote:
 At the release team meeting last weekend, we've discussed that we want
 to revitalize the Gnome Goals [1] effort by adopting a few goals for
 this cycle. We've chosen the following goals:

 GSettingsMigration
 XDGConfigFolders
 PortToGtkApplication
 PortToGMenu
 RemoveMarkupInMessages

 [...]

 The last one was included because we want to include our translators,
 and make their life easier by improving the quality of our strings.


What about strings with embedded markup, like this one: Unfortunately
GNOME 3 failed to start properly and started in the ifallback
mode/i? Are they also supposed to be changed in some way?

-- 
Piotr Drąg
http://raven.fedorapeople.org/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Tomboy Replacement???

2012-05-15 Thread Adam Lechowicz

Hello GNOME Developers,

I would like to ask you if you are in need of a Tomboy Notes
replacement. As you may know, many large distros have stopped using
Tomboy Notes because of the large amount of dependencies needed to run
it. To be exact, here is a terminal output from Debian's apt-get

Reading package lists... Done
Building dependency tree  
Reading state information... Done
The following extra packages will be installed:
  binfmt-support cli-common libappindicator0.1-cil libdbus-glib1.0-cil
  libdbus1.0-cil libgconf2.0-cil libgdiplus libglib2.0-cil libgmime2.6-cil
  libgtk2.0-cil liblaunchpad-integration1.0-cil libmono-addins-gui0.2-cil
  libmono-addins0.2-cil libmono-cairo4.0-cil libmono-corlib4.0-cil
  libmono-i18n-west4.0-cil libmono-i18n4.0-cil libmono-posix4.0-cil
  libmono-security4.0-cil libmono-sharpzip4.84-cil
  libmono-system-configuration4.0-cil libmono-system-core4.0-cil
  libmono-system-drawing4.0-cil libmono-system-security4.0-cil
  libmono-system-xml4.0-cil libmono-system4.0-cil mono-4.0-gac mono-gac
  mono-runtime
Suggested packages:
  monodoc-gtk2.0-manual libmono-i18n4.0-all libgamin0 evolution tasque
The following NEW packages will be installed:
  binfmt-support cli-common libappindicator0.1-cil libdbus-glib1.0-cil
  libdbus1.0-cil libgconf2.0-cil libgdiplus libglib2.0-cil libgmime2.6-cil
  libgtk2.0-cil liblaunchpad-integration1.0-cil libmono-addins-gui0.2-cil
  libmono-addins0.2-cil libmono-cairo4.0-cil libmono-corlib4.0-cil
  libmono-i18n-west4.0-cil libmono-i18n4.0-cil libmono-posix4.0-cil
  libmono-security4.0-cil libmono-sharpzip4.84-cil
  libmono-system-configuration4.0-cil libmono-system-core4.0-cil
  libmono-system-drawing4.0-cil libmono-system-security4.0-cil
  libmono-system-xml4.0-cil libmono-system4.0-cil mono-4.0-gac mono-gac
  mono-runtime tomboy

As you can see, Tomboy needs an obscene amount of packages simply to
run. 28 packages to be exact, most of them mono libraries. I have a
solution. My application, Notey, only needs GTK 3 and
python-quickly.widgets to run without a problem on most systems. Notey
is fast, simple, and cutting edge. It uses PyGTK as a backend, and has
been submitted to the Ubuntu Software Center as a free app. Notey is
currently in beta, however the app is completely stable, free of bugs
(As far as I know) and only includes a few menu items that don't work.
You can check it out at:

http://nextgennotetaking.webs.com/


~Adam Lechowicz,
   
Developer, Notey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Tomboy Replacement???

2012-05-15 Thread Hubert Figuière

On 15/05/12 01:43 PM, Adam Lechowicz wrote:
 I would like to ask you if you are in need of a Tomboy Notes
 replacement. 

Gnote?
http://live.gnome.org/Gnote

Hub

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

Re: gnome goals for 3.6

2012-05-15 Thread Matthias Clasen

On Tue, May 15, 2012 at 2:07 PM, Piotr Drąg piotrd...@gmail.com wrote:

 What about strings with embedded markup, like this one: Unfortunately
 GNOME 3 failed to start properly and started in the ifallback
 mode/i? Are they also supposed to be changed in some way?

These cases are tricky.
Sometimes you can eliminate the markup by doing something like

s = g_strdup_printf (i%s/i, _(fallback mode));
/* Translators, %s stands for 'fallback mode' here */
msg = g_strdup_printf _(Unfortunately GNOME 3 failed to start
properly and started in the %s), s);

But this is considerably more clumsy than the embedded markup version,
and you may well introduce memory leaks and new 'split string'
translation issues this way.

Use your judgement.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

2012-05-15 Thread Nguyen Thai Ngoc Duy

On Wed, May 16, 2012 at 12:53 AM, Jasper St. Pierre
jstpie...@mecheye.net wrote:
 Is there any reason that picking one input method framework is bad, if
 we do it right? If the experience sucks and users have to switch to
 another input method framework, yes, we've done it wrong, as Owen says
 in the original email. But if it works pretty much out of the box for
 all cases, what's wrong with tight integration?

There is resistance to changes after some support is in. Someone
already mentioned the power off button case, which took several cycles
to finally get fixed. I _think_ designers/developers moved their focus
to other stuff because it sort of works already.

So if there are strong opposing opinions from the beginning. I'd
rather see the discussion settled down than just go with one and see
what (likely never) happens next.

 We already have several hard requirements, out of practicality. GNOME
 chose GTK+ as our main toolkit. GNOME chose PulseAudio as our main
 sound server. We do this because we don't have the resources to
 support Qt or EFL or Motif or Xaw. Nor do we have the resources to
 support ESD or OSS.

 I doubt we have the resources to support both IBus and FCITX, and
 provide a good experience for both. Individual distributions may, but
 that's their call, not GNOME's.

 As for the prove it with code argument, it's not a data point until
 it happens. When it happens, I may switch my opinion.

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

Travel assistance applications to attend GNOME.Asia 2012

2012-05-15 Thread Bharath Acharya

Hello All,

The GNOME Foundation provides travel sponsorships to individuals who want
to attend GNOME.Asia 2012 and need financial assistance.

GNOME.Asia, 2012 is being held in City University of Hong Kong (
http://2012.gnome.asia/location/), from Friday 8th June, until Sunday 10th
June.

The instructions are detailed at http://live.gnome.org/Travel
Please read them carefully.

How to apply for sponsorship
(Things to keep in mind during the process)

   - Be patient, we are volunteers
   - If it's taking too long and you see prices could significantly raise
   -or something similar- please ping a member of the committee.
   - DO NOT BUY ANYTHING UNTIL YOU GET A VERY CLEAR CONFIRMATION, applying
   does not mean you are approved, and silence does not mean approval.
   - Try to get the best fares for tickets and lodging, look at various
   airlines and routes and try to avoid agencies since they usually charge 10%
   or 20% extra in every ticket. (Sites like Kayak can help find reasonable
   fares.)
   - Please find a roommate to save on lodging costs where possible.
   - Ask for only what you need. If you can afford to pay for some of your
   ticket or lodging, we would really appreciate it as that means we can help
   more people.
   - Be responsible, the money you save is the money we will use to fund
   someone else or even yourself again.


The process

   - First, make sure the conference or event is relevant for GNOME. If
   it's not an announced one like GNOME.Asia or a Hackfest, please explain us
   why would you like to go and what are the benefits you think we would all
   get from your presence there (promotion, contacts, etc)
   - Now, fill the application form form with the relevant information. (
   
https://live.gnome.org/Travel?action=AttachFiledo=viewtarget=gnome_travel_subsidy.odt
   )
   - Send the filled form to travel-commit...@gnome.org, this is a private
   list that will be visible only to the Travel Committee members and possibly
   GNOME's Board of Directors
   - Wait patiently to get questions or suggestions about your request
   - Expect a confirmation of your approval soon, or if it's taking too
   long, feel free to ask in IRC to any member of the committee
   - Now that you GOT COMPLETE CONFIRMATION buy your tickets and/or make
   your reservation
   - After the event, you have 2 weeks to mail us the appropriate receipts
   for tickets, lodging, etc; if they are not in English or the receipt has a
   lot of information, please clearly mark the total and the purpose.
   - Your reimbursement will be ready no more than 4 weeks after the
   receipts deadline


You can find us in the #travel channel at irc.gnome.org

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

Re: Some points about IM integration