Not implemented. I'll think about how it fits best with the new design. Also, not sure how to expose it in the UI.

I think *anywhere* (like gconftool) would be a good start. Then it would be nice to expose it in GUI, meanwhile thinking about making it a radio-button or dropdown list.

One goal of the new design was to simplify the mental model to have a single, current input source. Adding back this kind of toggle back would very much go against that.

So, I'm not sure that it fits in the new design at all.

It is certainly possible that an application has special needs, and may want to offer a way to switch to a different input source inside the application. But I'm not convinced that a global toggle is desirable.

In any case: design review needed.

Why do you keep tearing features off release after release and saying that it's all about design. What about usability and what people are used to? Why is it bad to have options? And why is it good to silently remove them? (The last thing remembers me Apple BTW).

You say that a lot of work has been done on how to work with input sources.
But you just broke layout switcher (https://bugzilla.gnome.org/show_bug.cgi?id=681685). Now it's placed in a very design pleasing way but doesn't work. So I don't buy it when you say about working on gnome for non-latin typing people and showing great pictures in blogs :(

(In reply to comment #3)
> One goal of the new design was to simplify the mental model to have a single,
> current input source. Adding back this kind of toggle back would very much go
> against that.
> 
> So, I'm not sure that it fits in the new design at all.
> 
> It is certainly possible that an application has special needs, and may want to
> offer a way to switch to a different input source inside the application. But
> I'm not convinced that a global toggle is desirable.
> 
> In any case: design review needed.

"Simplifying the mental model" sometimes makes things more complicated, and sometimes ruins user experience completely.

Imagine typical workflow involving instant messaging, word processing, writing emails, authoring code, doing things in terminal, surfing the web, and switching between these activities. For non-English users (and without individual layouts) it becomes a nightmare of constant layout switching, forgetting to switch, typing blindly some phrase, discovering that you've just typed abracadabra, erasing text, switching and typing again. For years, this issue was being successfully solved by a "window-remembering-its-keyboard-layout" paradigm, one that has been adopted since early versions of GNOME and KDE and has become a de facto standard. This is the current "mental model" for most non-English users, and this is what one might expect from a modern, productivity-focused DE. It is quite natural to have windows (applications) maintaining their state, including keyboard layout. I'm afraid that some day we will "simplify the mental model to have a single, current" window state for all applications, for example, maximized.

Please understand me right, I'm not demanding anything, just shedding some light. This issue has to be further reviewed by domain experts. In case of negative decision, please make sure that GNOME Shell provides enough APIs to give an ability for implementing the above as shell extension.

Thanks!

If you are working in the terminal, or the code is written, it always uses the English layout. And even when writing a message in the IM, mail, or text in a word processor uses the layout of the native language. And always switch the layout, follow it by using different applications (IDE, terminal, mail client, etc.) are very uncomfortable.

I'll add to support Comment #5.

This is indeed typical workflow to have english layout in the text processor(one of the text processor windows), in the terminal, and native _and_ english language in different IM windows. And the choice of language is important in the browser and also in the gnome-shell Activities search menu. So this is not the setting, which should be ruled by the one particular application.


This is the feature of high importance. You can see, for example, how people try the strange workarounds to get the default search in Activities to work in english: https://extensions.gnome.org/extension/34/layout-swicher-seach-ru-en/ 

The approach used there has several major issues, while setting the default search layout would help a lot. See related https://bugzilla.gnome.org/show_bug.cgi?id=647362

(In reply to comment #3)
> One goal of the new design was to simplify the mental model to have a single,
> current input source. Adding back this kind of toggle back would very much go
> against that.
> 
> So, I'm not sure that it fits in the new design at all.
> 
> It is certainly possible that an application has special needs, and may want to
> offer a way to switch to a different input source inside the application. But
> I'm not convinced that a global toggle is desirable.
> 
> In any case: design review needed.

> mental model

Sorry, man, are you junkie? Or hippie? This has nothing to do with GNOME, Linux, OSS or tech side AT ALL. It has no sense. UI is least priority now. Usability should be first priority, ALWAYS.

(In reply to comment #8)
> Sorry, man, are you junkie? Or hippie? This has nothing to do with GNOME,
> Linux, OSS or tech side AT ALL. It has no sense. UI is least priority now.
> Usability should be first priority, ALWAYS.

If you want to namecall, you can do so somewhere else. It's not helpful.

The problem is understood, but it won't be fixed or worked on for GNOME 3.6 (and for good reasons, GNOME 3.6 is already out). Input welcome into your uses of the old functionality are appreciated.

So far, I gathered that the main use is having all the windows in one non-latin layout, and only your terminal or code editor in another. We also need to see how common this use is, and how other OSes have solved this problem.

Bastien, does the one who decided to throw this function away uses multiple layouts on a day to day basis?

IIRC, MacOS X has this (separate layout) option as well as Windows.

(In reply to comment #10)
> Bastien, does the one who decided to throw this function away uses multiple
> layouts on a day to day basis?

Nobody decided to "throw this out". It broke because nobody noticed it didn't get into the designs, and the framework changed in a way that meant it needs to be reimplemented in a different part of the stack.

And drop the "us vs. them" thing, we already got it from a vocal portion of the CJK community on desktop-devel-list, and it's really not helpful.

> IIRC, MacOS X has this (separate layout) option as well as Windows.

Feel free to point us to screenshots of their configuration and explanations of the behaviour.

We discussed this during the design process for the input methods work. I don't remember all the specifics, but one point that was raised was that it doesn't make sense for system properties to dynamically update in this manner - system state should be stable and independent of application window changes.

While I recognise the utility of this option for some users, I'm not sure that many people will be able to understand it.

I know that OS X provides this option, but I'm not sure about Windows. Specifics on the behaviour of other operating systems would be appreciated.

Screencast, how it works in windows: https://dl.dropbox.com/u/14428873/ScreenShots/Screencast%20from%2003.10.2012%2011%3A12%3A18.webm

> While I recognise the utility of this option for some users, I'm not sure that
many people will be able to understand it.

Sorry, but this kind of arguments looks really strange for me. I understand the wish of Gnome Devs to target the "simple" audience. This might be reasonable in the perspective and so on. But aren't you scared of loosing all the others? Shouldn't you care about more experienced users also? You know, in fact it is us who provides you with testing, and us, who could have become the future Gnome Devs. See the topic starter as an example.

We are current users of Gnome, who already have based a lot of the typical daily tasks on this useful feature. And it is not "one particular window with layout different from all the others", it is "different tasks need different languages" concept. Including writing the mails and messages to different coworkers, from different parts of the world, writing the code and simultaneously searching for the documentation in your native language on Google, and so on.

And we don't ask for the making the option the default one, so this feature will not bother people, who don't know about it. So there is no conflict of interests between different user groups.

+1 To Aleksandra Bookwar.
Making it simple and polished is ok, but you make it useless. You are loosing you community that you have for the market of Apple funs, but they do not know about you or despise you.

If you think users can not handle it just make simple-mod check box.

(In reply to comment #14)
> > While I recognise the utility of this option for some users, I'm not sure that
> many people will be able to understand it.
> 
> Sorry, but this kind of arguments looks really strange for me. I understand the
> wish of Gnome Devs to target the "simple" audience. This might be reasonable in
> the perspective and so on. But aren't you scared of loosing all the others?
> Shouldn't you care about more experienced users also?

Are you guys trying to tick boxes about falsehoods? Are you going to tell me that GNOME is about choice next?

> You know, in fact it is
> us who provides you with testing, and us, who could have become the future
> Gnome Devs. See the topic starter as an example.

Given that the functionality can be written and implemented without the desktop itself having to know anything about it (devilspie + a few scripts? a gnome-shell  extension? a libwcnk using python script?), it's time to show that you can become those GNOME devs.

You only need to switch the value of org.gnome.desktop.input-sources current based on the window selected.

(In reply to comment #15)
> +1 To Aleksandra Bookwar.
> Making it simple and polished is ok, but you make it useless. You are loosing
> you community that you have for the market of Apple funs, but they do not know
> about you or despise you.

Seriously, I'm going to start barring people that spout out that sort of rubbish in Bugzilla. This isn't a forum, and I've made it clear in comment 11 what sort of contributions we were interested in.

Bastien, sorry again, but it is you, devs, not the users, who make the Gnome bugzilla to be a discussion forum.

The comment #16 is why we are posting bugs here. Not the Comment #3 mental simplicity ideas, we are all rather tired already.

So instead of speaking what users could understand, let's go back to the topic, and discuss, why the functionality has been broken, where, and what needs to be done to reimplement it.

> So far, I gathered that the main use is having all the windows 
> in one non-latin layout, and only your terminal or code editor 
> in another.

Not really.

What you seem to be implying is mapping apps to layout use cases. This is simply incorrect.

There are tons of cases when users need to maintain layout for a specific window. The kind of application doesn't matter all that much.

I can talk to someone in Russian in xchat, while exchanging emails in German or English in Gmail@Chrome. Next minute I will move to a different channel in xchat to start talking in English, and then start writing a blog post in Russian. I can also have several documents in two languages opened in Gedit (OK, it's actually Sublime Edit 2, but who cares?) and switch between them and the browser. Those documents can be source code, articles or just notes in different languages.

See? Suggesting that English layout is for code editing is wrong.

(In reply to comment #19)
> > So far, I gathered that the main use is having all the windows 
> > in one non-latin layout, and only your terminal or code editor 
> > in another.
> 
> Not really.
> 
> What you seem to be implying is mapping apps to layout use cases. This is
> simply incorrect.

I imply nothing. I try to gather information from the use cases that were put forward.

> There are tons of cases when users need to maintain layout for a specific
> window. The kind of application doesn't matter all that much.
> 
> I can talk to someone in Russian in xchat, while exchanging emails in German or
> English in Gmail@Chrome. Next minute I will move to a different channel in
> xchat to start talking in English, and then start writing a blog post in
> Russian. I can also have several documents in two languages opened in Gedit
> (OK, it's actually Sublime Edit 2, but who cares?) and switch between them and
> the browser. Those documents can be source code, articles or just notes in
> different languages.
> 
> See? Suggesting that English layout is for code editing is wrong.

Suggesting I suggested that is wrong :)

Now the question is why, when you have multiple documents within an application, those can't have separate layouts, so you could write one document in one language, and the other in the other language, without having to switch layouts in between, just document.

This is starting to feel like something that should be fixed at a different level, with an API provided by gnome-settings-daemon to make it possible to switch between 2 layouts rather than poking at GSettings.

For the info, the temporary solution in a form of gnome-shell extension is now available here: https://github.com/rat4/layoutperwindow 

Made by ratvier.

This is funny to watch how developers, who do not use different layouts, are trying to convince users, who do use the layouts, that they do not need this feature.

Dear devs, please understand, the lack of this feature makes gnome unusable for people who use several layouts. Not unconvenient or not-simple-enough, but simply UNUSABLE. Do you really want to sacrifice all your non-latin users to the mythical god of "mental model"?

Let's not descend into an us-and-them mentality. We're all GNOME users, and everyone can raise points in this discussion. Also, let me remind you the current design isn't fixed, and that the new input sources work is still young. We're finding our way as best we can, and we're listening to everything that people have to say.

Please stick to the issues.

Having layouts (or input sources) for different windows is obviously a common situation, and we absolutely want to provide a good solution here.

Right now I have a few reservations about the layout per window functionality. These include:

 * It is a rather complex feature, which makes it hard to describe to people who haven't used it.
 * It either:
  - relies on switching through a fixed list of layouts, which is rather inefficient and laborious, or
  - muddles the switching order, making it hard to track the switching sequence.
 * It is not the default. Given that having different layouts associated with different windows is a common situation, I would really like to have default functionality that is effective in this case, rather than having an alternative behaviour that is only available to people who decide to use it.
 * It might conflict with plans that we have for improving input sources (maybe a developer can clarify this?) One thing that has been in the input sources designs for some time is a change in the behaviour of input source switching (and also to provide an OSD for switching layouts). Right now we have a static list that you switch though; I would prefer it if we made the order update according to order used (like Alt+Tab does). This way it would be a much easier to switch between two sources, if you have quite a few of them, and would follow a pattern that most users are familiar with.

So the question is: is the layout per window behaviour is the best approach? And if not: what are the alternatives?

An idea (just an idea!): could we introduce a key combination that would lock a window on to the current layout? This would have the advantage of being available to everyone, not just those using a particular setting. It could also (?) be accomodated within the cycling behaviour that we want to add in the future.

Created attachment 225959 [details]
OS X Radio Button

IBus used to have an option on global or not.

In order to accommodate GNOME, IBus removed such feature in its 1.5 branch.
Users of Fedora 17 (which features pre-releases of IBus 1.5) already complain about this issue.
http://code.google.com/p/ibus/issues/detail?id=1477
( The above issue is in Chinese, you may also check the following English dup: )
http://code.google.com/p/ibus/issues/detail?id=1503

Local input state is indeed the default of IBus 1.4 or below. I think the default should remain the same and an option like Mac OS X should be provided.

Created attachment 225960 [details]
IBus Check Button

(In reply to comment #23)
[snip]
> An idea (just an idea!): could we introduce a key combination that would lock a
> window on to the current layout? This would have the advantage of being
> available to everyone, not just those using a particular setting. It could also
> (?) be accomodated within the cycling behaviour that we want to add in the
> future.

Hi; Mexican user here, so I'm always switching between English and Spanish layouts, in the use-cases mentioned by Alexandre Prokoudine and others.

I think I understand the points made by Allan and Matthias; we want a simple model for the layout switching, with sensible defaults. I really like the idea of an OSD when switching layouts, but it certainly clashes with the concept of per-window layout. It makes no sense to have an OSD when switching layouts, if said switching doesn't affect some windows.

I believe the problem is actually a conceptual one: It seems to me (correct me if I'm wrong) that in the current model (or at least as it is implemented right now), there is *ONE* layout for the system at one time. A user doesn't switch the layout of an application, it switches the layout of her whole desktop. Switching layouts hence becomes a conscious thing that it has to be thought, considered, and executed, and when executed the whole system switches.

It certainly doesn't get simpler than that (unless you completely disable the ability to switch layouts, which nobody in his right mind would suggest). Whatever the community chooses, if it chooses to change the model as currently implemented, is going to be more complex. I believe nobody would argue against that statement (again, correct me if I'm wrong).

That doesn't mean the model could be (and maybe should be) a little more complex. In my experience, when you are in a multilingual group, you don't think about switching languages, considered it, and execute the switch: You simply turn to some dude/dudette, remember what language both of you have in common, and start speaking in that language. Sure, at the beginning there are some mixups, and you speak to your English speaking friends in Spanish and to the local waiters in English (been there, done that), but after a little while is automatic: You speak the correct language depending on the person you are speaking with.

So, the conceptual problem (from my point of view) is: We want to think about the desktop as an entity more or less monolingual, and the layout switching as some not so often used feature that reconfigures the whole desktop for a particular layout, OR we think about the set of applications running in the desktop as a multilingual group, were we speak to an individual application in the language that makes the most sense.

I believe there is not an easy and obvious answer to that problem. If GNOME is used in a primary school, in Mexico that would mean that the children using it almost for sure only speak Spanish, and the applications-as-multilingual-group makes absolutely no sense in that case (almost all public primary schools in Mexico don't teach any foreign language). Even in middle school and high school the only foreign language is (almost always) English, and besides the assignments for that class, the student would be right to expect for her to use only one layout in the desktop.

Then again, in this globalized world the norm now is for educated people to speak at least one language besides the native, and there are a lot of countries with several official languages (Spain has at least four; in Mexico the indigenous populations have the right to only use its own language), and even without official recognition some countries actually speak several languages in their borders (it has not been difficult for me to find US citizens in Los Angeles who can speak Spanish better than English). In this cases, the idea of "my-desktop-speaks-only-one-language-at-the-time" sounds even quaint; and for sure is a PITA to use if the user needs to switch layouts every time it switches windows.

I agree with Allan in that it is "a rather complex feature, which makes it hard to describe to people who haven't used it". But I really don't know if "people who haven't used it" it's really the norm in this day and age.

About the technical problems of (again, quoting Allan):

> * It either:
>   - relies on switching through a fixed list of layouts, which is rather
inefficient and laborious, or
>   - muddles the switching order, making it hard to track the switching
sequence

Again using my "multilingual-group-of-friends" analogy: A user has a default layout (language), and THAT ONE is global. Every new application/window would use that one (if I'm in the States, I would speak in English to someone I don't know, if I'm in Mexico in Spanish). But if the user switches the layout for an application/window (I discover a tourist in my country, or a paisano in Los Angeles, and switch languages), the application/windows retains that layout.

This (as I said) completely clashes with the OSD when switching layouts. Since I don't know how to solve that, I would suggest to disable the OSD if there is an option "allow different layouts per window", and it is selected.

I love my GNOME desktop, and I believe the bumps we are facing are worth it. If the community chooses to stick with the "my-desktop-speaks-only-one-language-at-the-time", I can stick to finding (or writing) an extension for doing what I need (which in *my* case is different layouts per window).

I'm just not so sure how many are benefited by that model (which, I repeat, I agree it's the simpler of all).

> It is a rather complex feature, which makes it hard to describe 
> to people who haven't used it.

Why is it a rather complex feature? What research exactly does provide the insight that it's difficult to describe per-window layout to newbies?

> muddles the switching order, making it hard to track the 
> switching sequence

Why does it muddle the switching order? What is this observation based on?

> An idea (just an idea!): could we introduce a key combination that 
> would lock a window on to the current layout?

That would be just another annoying roadblock.

I understand and support your willingness to maintain a clean architecture and a clean workflow, but you are just making things difficult for people who use multiple layouts.

http://translate.google.com/translate?sl=ru&tl=en&u=http%3A%2F%2Fwww.linux.org.ru%2Fpolls%2Fpolls%2F8296478

*** Bug 686859 has been marked as a duplicate of this bug. ***

I can confirm that switching between layouts is must for Czech people, doing other stuff than surfing Facebook. Different layout for different windows always worked for windows since W3.1 as far as I remember and worked fine in all previous versions.

If Gnome wants to be better, it would be nice if the settings can be remembered per app, so for example I want to use english layout for terminal and vim, where I typically need czech layout for Browser and IM. That would rock.

*** Bug 689470 has been marked as a duplicate of this bug. ***

(In reply to comment #20)
> (In reply to comment #19)
> > > So far, I gathered that the main use is having all the windows 
> > > in one non-latin layout, and only your terminal or code editor 
> > > in another.
> > 
> > Not really.
> > 
> > What you seem to be implying is mapping apps to layout use cases. This is
> > simply incorrect.
> 
> I imply nothing. I try to gather information from the use cases that were put
> forward.

Hey, maybe you can take a look at bug 689470 as another use case.

(In reply to comment #31)
> I can confirm that switching between layouts is must for Czech people, doing
> other stuff than surfing Facebook. Different layout for different windows
> always worked for windows since W3.1 as far as I remember and worked fine in
> all previous versions.
> 
> If Gnome wants to be better, it would be nice if the settings can be remembered
> per app, so for example I want to use english layout for terminal and vim,
> where I typically need czech layout for Browser and IM. That would rock.

I would even say let's do this at input context level. When I'm talking with a English speaker, I never swtich to Chinese Input Method, but when I'm talking to a Chinese guy, I always turn the IM on. And the chat re in the same window with different tabs (see how empathy handle it.)

So, preserve the input state for different window is not a good way to solve the problem, the problem should be solved at the input context level.

That is rapidly moving into application-specific territory. Only the chat application can know whether it makes sense to offer a way to switch input language per tab or not - we can't really decide this on a system-wide level.

It's been working acceptably on system-wide level since day 1. And now suddenly it doesn't?

An attempt to move it to application territory is likely to isolate non-GNOME apps (please prove me wrong). I don't know about you, but I don't expect desktop users to always use GNOME software. Or even GTK+ based software.

The whole audio production stack is underrepresented with GTK+ based applications, for instance.

(In reply to comment #35)
> That is rapidly moving into application-specific territory. Only the chat
> application can know whether it makes sense to offer a way to switch input
> language per tab or not - we can't really decide this on a system-wide level.

Oh, it could. There will be a input context created -- on XIM, on SCIM, and on ibus. Previously, ibus is responsible to manage input contexts, now you just need to integrate that from gnome-shell into ibus, and ask what engine is ibus one currently when input context switch (I'm sure there is a signal for that.)

*** Bug 690597 has been marked as a duplicate of this bug. ***

"per window", more preciously, "per input context".

This should be done in ibus, which managers input contexts. Not gnome-shell, which managers windows.

ibus is not for GNOME only. It runs under KDE, Xfce, i3, wmii, dwm, openbox, etc. Its design even allows running without X. Decisions in GNOME alone should not affect other DEs. Users should be able to configure ibus as they like. I saw several settings removed from ibus source by GNOME developer already. Next time, please consider to add configure options, not hard-code GNOME's favor directly into ibus source.

(In reply to comment #16)
> You only need to switch the value of org.gnome.desktop.input-sources current
> based on the window selected.

I'd like to say input method is not just about switching, they have status per input context.

Switching input method by a window manager is WRONG.

Let me explain this by a resonable use case:

Consider an async(cloud-based) input method, for example, a voice recognition input method using Google voice API. The input method("input engine" in ibus) should keep all the status(connection status, what users said, etc.) for each input window using this input method("input context" in ibus).

If the user say something in window A using the async voice input method, then quickly switch to window B and switch to another input method. The voice input method should be still able to communicate to remote server in background and commit result text back to the input context (in a background window) in background.

With that being explained, a simple fact is:

The above async inputing process is possible and easy to implement prior to ibus 1.4.x with global engine disabled.

With "contributions" by GNOME, the latest situation is:

ibus 1.5's the global engine option is always enabled, which means the above async inputing process is technologically impossible any more. I have attempted to disable the global engine option directly from ibus source and then I was unable to switch input method, ibus became totally unusable.


If you guys believe the correct things to do next are:

1. keep ibus's global engine always enabled
2. use a window manager to switch input method when focused window changed

Then,

1. The async inputing process mentioned above is almost impossible or much complicated then before.
2. Other window managers are required to implement input method switching, which is ridiculous.

So, please reconsider your design.

... and, finally, I've installed Gnome 3.6 and all my faiths was broken by the fact that IBus doesn't more work so kb layout switching don't more work.

I've found that it's possible to get caps kb switch working with gnome-tweak-tool. But it works very ugly. One layout per system, no separate layouts.

So, WHAT should I do? I was attracted by gnome-shell, I like it. But it became unusable. Why don't just let IBus to work?

I think that it's shame that such bug is unconfirmed for months. It should be blocking priority.

(In reply to comment #41)
> ... and, finally, I've installed Gnome 3.6 and all my faiths was broken by the
> fact that IBus doesn't more work so kb layout switching don't more work.
> 
> I've found that it's possible to get caps kb switch working with
> gnome-tweak-tool. But it works very ugly. One layout per system, no separate
> layouts.
> 
> So, WHAT should I do? I was attracted by gnome-shell, I like it. But it became
> unusable. Why don't just let IBus to work?

As a workaround, you might use a GNOME Shell extension mentioned in Comment 21. Works great for me. Nevertheless, to me this is a very serious regression.

Moreover, system saves current layout when screen is locking, but CapsLock layout switch doesn't work on unlocking screen (so, layout can be only switched with mouse through top menu).

Holy shit. I've just faced to one more problem. 

I've used gnome-tweak-tool to set caps lock as kb switch hotkey. I've added two layouts (en-us, ru) in regional settings/typing.

So, for now first press on caps lock turns english layout on. Second press turns russian layout. Third press... does nothing. Keyboard indicator disappears from gnome-shell panel and keyboard layout remains set to russian. Next press will turn english layout again.

It's VERY, VERY annoying, you've not only broken per-window/per-context layout switching but also broken layout switching at all. 

What should I do?.. Switch to ugly KDE? Switch to ugly xfce? GTFO and buy windows?...

Can you please file a separate bug for that issue ? It is not related to per-window layouts.

1) https://bugzilla.gnome.org/show_bug.cgi?id=691396
2) https://bugzilla.gnome.org/show_bug.cgi?id=691397

Gnome 3.6 is SO disappointing.

Created attachment 233063 [details] [review]
region: Add a check button for the per-window input sources setting

Created attachment 233064 [details]
How it looks

Suggestions on visual design and label wording very welcome.

(In reply to comment #48)
> Created an attachment (id=233064) [details]
> How it looks
> 
> Suggestions on visual design and label wording very welcome.

AFAIK, this issue is not about UI. ibus-setup has the option, which was set to invisible by a commit of a GNOME developer. It is very easy to revert that change.

Prior to that, ibus's internal global engine logic(whether to enable input engine per input context) was massed up. That's the problem. See also https://code.google.com/p/ibus/issues/detail?id=1568 

BTW, this option and related logic should exist in ibus, which I explained in previous comments. If you need this option to be hidden from ibus setup, please make an autoconf option for ibus to hide the option for gnome, do not directly hardcode into ibus source.

For g-c-c UI itself, why not do something similar to that of GNOME 3.4 or that of OSX?

(In reply to comment #49)
> AFAIK, this issue is not about UI. ibus-setup has the option, which was set to
> invisible by a commit of a GNOME developer. It is very easy to revert that
> change.
> 
> Prior to that, ibus's internal global engine logic(whether to enable input
> engine per input context) was massed up. That's the problem. See also
> https://code.google.com/p/ibus/issues/detail?id=1568 
> 
> BTW, this option and related logic should exist in ibus, which I explained in
> previous comments. If you need this option to be hidden from ibus setup, please
> make an autoconf option for ibus to hide the option for gnome, do not directly
> hardcode into ibus source.

This bug here is about the GNOME implementation for input sources to be applied per window.

I know that IBus had (or had?) the option of switching engines per context but that feature is not exposed in GNOME and we don't use it. This doesn't mean that we removed that feature from IBus itself willingly. I certainly didn't. But that issue is off topic for this bug here.

Well, IBus engines are input sources too.

What I believe is that IBus removed per window support at certain point.
We need to add the IBus feature back and then let GNOME to support it.

ibus-setup should expose that option, it doesn't matter if it runs with GNOME since ibus-setup is not the right tool to use in GNOME environment anyway.

(In reply to comment #51)
> (In reply to comment #49)
> > AFAIK, this issue is not about UI. ibus-setup has the option, which was set to
> > invisible by a commit of a GNOME developer. It is very easy to revert that
> > change.
> > 
> > Prior to that, ibus's internal global engine logic(whether to enable input
> > engine per input context) was massed up. That's the problem. See also
> > https://code.google.com/p/ibus/issues/detail?id=1568 
> > 
> > BTW, this option and related logic should exist in ibus, which I explained in
> > previous comments. If you need this option to be hidden from ibus setup, please
> > make an autoconf option for ibus to hide the option for gnome, do not directly
> > hardcode into ibus source.
> 
> This bug here is about the GNOME implementation for input sources to be applied
> per window.
> 
> I know that IBus had (or had?) the option of switching engines per context but
> that feature is not exposed in GNOME and we don't use it.

This option is very useful and is working prior to ibus 1.5.
This option is (or can be very easily) exposed by ibus's dbus interface.
This option is broken currently. Since a GNOME developer commit a lot to latest ibus source, I guess it is broken by GNOME.

Although GNOME does not use it (I am totally disappointed and used to wrong decisions GNOME has made and now give up arguing you are doing things plain wrong. If you wonder why, think about async input enging I mentioned in previous comment), GNOME should not break it, because there are many other DEs using ibus.

I recommend trying to resume the feature in ibus and using ibus's interface. Stop designing GNOME's new immature non-portable (to other DEs) interface.

> This doesn't mean
> that we removed that feature from IBus itself willingly. I certainly didn't.
> But that issue is off topic for this bug here.

I don't think so. I have seen the ibus commit log. It is a GNOME developer who removed the option from ibus-setup UI. This issue can only be fix in a correct way after that issue being fixed, otherwise you are doing things wrong.

Well, it seems I wasted a lot of time here.

If you are unable or not willing to fix ibus, I suggest simply totally abandon it and invent a new input manager and port all input existing eninges into GNOME3, providing a consist interface for stupid users and make all things under control. That is exactly GNOME3's favor I knew. You do not know how mad ibus users got with GNOME developers.

> You do not know how mad ibus users got with GNOME developers.
I can only add XKB users to that list, with all due respect...

Сергей, скажите честно, сами-то вы как этим новым убожеством пользуетесь? Ну ведь работало все, много лет работало, зачем ломать-то все было?..

Wolfram: http://blogs.gnome.org/sudaltsov/2012/09/25/so-long/

Created attachment 233091 [details] [review]
region: Add UI for the per-window input sources setting

--

Updated the UI according to the mockup at
https://raw.github.com/gnome-design-team/gnome-mockups/e961634511e4b7a7e15b07267fd1520c7b8224d4/system-settings/region-and-language/png/input-sources.png

Review of attachment 233091 [details] [review]:

Looks good to me

::: panels/region/gnome-region-panel-input.c
@@ +1251,3 @@
+                            G_CALLBACK (g_settings_apply), input_sources_settings);
+  g_signal_connect_swapped (WID("per-window-radio-false"), "clicked",
+                            G_CALLBACK (g_settings_apply), input_sources_settings);

There might be a more elegant way to bind a radio group to a setting, but if this works, it is ok.

(In reply to comment #59)
> ::: panels/region/gnome-region-panel-input.c
> @@ +1251,3 @@
> +                            G_CALLBACK (g_settings_apply),
> input_sources_settings);
> +  g_signal_connect_swapped (WID("per-window-radio-false"), "clicked",
> +                            G_CALLBACK (g_settings_apply),
> input_sources_settings);
> 
> There might be a more elegant way to bind a radio group to a setting, but if
> this works, it is ok.

That's just because we are using GSettings in delay-apply mode here so that we could do changes to the sources list and the index in a single atomic operation for outside watchers.

Ah, I see. Looks good then

Review of attachment 233091 [details] [review]:

Might be worth a comment (this being due to delay)

::: panels/region/gnome-region-panel-input.c
@@ +1251,3 @@
+                            G_CALLBACK (g_settings_apply), input_sources_settings);
+  g_signal_connect_swapped (WID("per-window-radio-false"), "clicked",
+                            G_CALLBACK (g_settings_apply), input_sources_settings);

There might be a more elegant way to bind a radio group to a setting, but if this works, it is ok.

Pushed with a comment about g_settings_apply().

Attachment 233091 [details] pushed as 4f38c42 - region: Add UI for the per-window input sources setting