Support for providing IMEContext with Ozone.

Support for providing IMEContext  with  Ozone.

This patch adds support for Ozone implementations to provide
an IME context implementation.By default we use FakeInputMethodContext.

BUG=None

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=241442

[kalyank, 2013-12-09 12:54:36]

On 2013/12/03 08:46:13, kalyank wrote:

input_method_linux_x11 was renamed as input_method_auralinux here:
https://codereview.chromium.org/108143003/ 

@rjkroege Can you please take a look. Is it ok to add the dependency of
ui/base/ime in ui/ozone ?

[rjkroege, 2013-12-09 16:44:50]

On Monday, December 9, 2013, wrote:

> On 2013/12/03 08:46:13, kalyank wrote:
>
> input_method_linux_x11 was renamed as input_method_auralinux here:
> https://codereview.chromium.org/108143003/
>
> @rjkroege Can you please take a look. Is it ok to add the dependency of
> ui/base/ime in ui/ozone ?
>

what are you trying to add? ui/ozone should not depend on ui/base

ui/base is somewhat wrongly named as it is not "base".

Rob.


> https://codereview.chromium.org/100213003/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[kalyank, 2013-12-09 17:56:52]

> what are you trying to add? ui/ozone should not depend on ui/base
> 
> ui/base is somewhat wrongly named as it is not "base".
> 
> Rob.

Aura registers a views::corewm::InputMethodEventFilter as an event filter, and
the InputMethodEventFilter uses an implementation of ui::InputMethod.
InputMethodFactory is responsible for creating the respective InputMethod[1]. 

Currently with Ozone, we use InputMethodMinimal which provides basic support.
Ideally, we should be using InputMethodAuraLinux.
InputMethodAuraLinux uses LinuxInputMethodContextFactory to provide any native
input method contexts [2]. Idea, here was to add InputMethodContextFactoryOzone
which by default would create a FakeInputContext[3]. Any, Ozone implementation
should be able to extend this interface and provide it's own implementation of
LinuxInputMethodContext.

1)http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/ime/input_method_factory.cc?revision=239501
2)http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/ime/linux/linux_input_method_context_factory.h?revision=230760
3)http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/ime/linux/fake_input_method_context.cc?revision=238914

[kalyank, 2013-12-09 18:07:04]

On 2013/12/09 17:56:52, kalyank wrote:
> > what are you trying to add? ui/ozone should not depend on ui/base
>
1)http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/ime/input_method_factory.cc?revision=239501
>
2)http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/ime/linux/linux_input_method_context_factory.h?revision=230760
>
3)http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/ime/linux/fake_input_method_context.cc?revision=238914

LinuxInputMethodContext interface can be found here:
http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/ime/linux/linux_input...

[Yuki, 2013-12-10 07:01:58]

Please allow me to jump in.

If you guys want, I think we can create a new directory
  ui/ozone/ime
and make only this directory depends on ui/base/ime.

  ui/ozone/ime/DEPS
  ui/ozone/ime/subclass_of_LinuxInputMethodContext.{cc,h}
  ui/ozone/ime/other_ime_related_files...
and you have an entry +ui/base/ime in ui/ozone/ime/DEPS.

Then, other files in ui/ozone won't be contaminated with ui/base or anything.

Just my two cents,
Yuki Shiino

[kalyank, 2013-12-10 12:10:29]

On 2013/12/10 07:01:58, Yuki wrote:
> Please allow me to jump in.
> 
> If you guys want, I think we can create a new directory
>   ui/ozone/ime
> and make only this directory depends on ui/base/ime.
> 
>   ui/ozone/ime/DEPS
>   ui/ozone/ime/subclass_of_LinuxInputMethodContext.{cc,h}
>   ui/ozone/ime/other_ime_related_files...
> and you have an entry +ui/base/ime in ui/ozone/ime/DEPS.
> 
> Then, other files in ui/ozone won't be contaminated with ui/base or anything.
> 
> Just my two cents,
> Yuki Shiino

On that note, I am wondering if this is acceptable:
1)Create a new folder ui/ime -> This would contain the current Linux,Win and
ChromeOS folder found under ui/base/ime/
2)ui/base/ime and ui/ozone has a dependency on this ?

I see that ui/base already has dependencies like ui/events.

[Yuki, 2013-12-10 14:21:27]

On 2013/12/10 12:10:29, kalyank wrote:
> On 2013/12/10 07:01:58, Yuki wrote:
> > Please allow me to jump in.
> > 
> > If you guys want, I think we can create a new directory
> >   ui/ozone/ime
> > and make only this directory depends on ui/base/ime.
> > 
> >   ui/ozone/ime/DEPS
> >   ui/ozone/ime/subclass_of_LinuxInputMethodContext.{cc,h}
> >   ui/ozone/ime/other_ime_related_files...
> > and you have an entry +ui/base/ime in ui/ozone/ime/DEPS.
> > 
> > Then, other files in ui/ozone won't be contaminated with ui/base or
anything.
> > 
> > Just my two cents,
> > Yuki Shiino
> 
> On that note, I am wondering if this is acceptable:
> 1)Create a new folder ui/ime -> This would contain the current Linux,Win and
> ChromeOS folder found under ui/base/ime/
> 2)ui/base/ime and ui/ozone has a dependency on this ?
> 
> I see that ui/base already has dependencies like ui/events.

If you really want to do such big refactoring, please loop all the owners of
ui/base/ime in (and probably more).  There was a lot of effort to make code
structure clean.  http://crbug.com/103304 for example.  The idea of ui/ime
sounds very healthy.

Having said that, do you really want to take time for the refactoring?  If your
primary goal is to support IMEs on Ozone, it wouldn't be the shortest path.  I
wouldn't recommend it.  Instead, you can file an issue for ui/base/ime owners.

[kalyank, 2013-12-11 08:15:27]

> > On 2013/12/10 07:01:58, Yuki wrote:
> > > Please allow me to jump in.
> > > 
> > > If you guys want, I think we can create a new directory
> > >   ui/ozone/ime
> > > and make only this directory depends on ui/base/ime.
> > > 
> > >   ui/ozone/ime/DEPS
> > >   ui/ozone/ime/subclass_of_LinuxInputMethodContext.{cc,h}
> > >   ui/ozone/ime/other_ime_related_files...
> > > and you have an entry +ui/base/ime in ui/ozone/ime/DEPS.
> > > 
> > > Then, other files in ui/ozone won't be contaminated with ui/base or
> anything.
> > > 
> > > Just my two cents,
> > > Yuki Shiino
> > 

K, restructured code to as you suggested.

> If you really want to do such big refactoring, please loop all the owners of
> ui/base/ime in (and probably more).  There was a lot of effort to make code
> structure clean.  http://crbug.com/103304 for example.  The idea of ui/ime
> sounds very healthy.
> 
> Having said that, do you really want to take time for the refactoring?  If
your
> primary goal is to support IMEs on Ozone, it wouldn't be the shortest path.  I
> wouldn't recommend it.  Instead, you can file an issue for ui/base/ime owners.

I was thinking if we could divide the work to two phase: 
1)Do this re factoring for LinuxAura as the code is already structured properly
and might involve moving the classes to right place. This could happen along
with this.
2)Do the same for Chrome-OS and Windows.

I am fine to handle 1 here but also happy to create a issue and let the ime
owners handle both 1 and 2 together.

[Yuki, 2013-12-11 09:31:14]

Your strategy, moving ui::InputMethodAuraLinux to ui/ime first and later other
platform's files, sounds weird.  ui::InputMethodAuraLinux inherits
ui::InputMethodBase, and it's inherited by other platform's classes, too.  So
moving them at a time would be best.

Having said that, before discussing how to do it, you should get agreement on
the basic idea from other owners and related people.

https://codereview.chromium.org/100213003/diff/100001/ui/base/ime/ime.gypi
File ui/base/ime/ime.gypi (right):

https://codereview.chromium.org/100213003/diff/100001/ui/base/ime/ime.gypi#ne...
ui/base/ime/ime.gypi:112: ['use_aura==0 or (desktop_linux==0 and use_ozone==0)',
{
Is there any chance to be use_ozone==1 but desktop_linux==0 ?
I think ozone is desktop_linux-based.  So you don't need this change.

https://codereview.chromium.org/100213003/diff/100001/ui/base/ime/ime.gypi#ne...
ui/base/ime/ime.gypi:118: ['use_aura==0 or (desktop_linux==0 and use_ozone==0)',
{
Ditto.

https://codereview.chromium.org/100213003/diff/100001/ui/base/ime/input_metho...
File ui/base/ime/input_method_factory.cc (right):

https://codereview.chromium.org/100213003/diff/100001/ui/base/ime/input_metho...
ui/base/ime/input_method_factory.cc:17: #elif defined(USE_AURA)
Better to be defined(USE_AURA) && defined(OS_LINUX).
This shouldn't be applied to other Aura builds.

https://codereview.chromium.org/100213003/diff/100001/ui/base/ime/input_metho...
ui/base/ime/input_method_factory.cc:66: #elif defined(USE_AURA)
Ditto.

https://codereview.chromium.org/100213003/diff/100001/ui/base/ime/input_metho...
File ui/base/ime/input_method_initializer.cc (right):

https://codereview.chromium.org/100213003/diff/100001/ui/base/ime/input_metho...
ui/base/ime/input_method_initializer.cc:16: #elif defined(USE_AURA)
It's not a good idea to swap OS_WIN and USE_AURA.
Please use defined(USE_AURA) && defined(OS_LINUX) instead.

Remember Mac could use Aura in future.

https://codereview.chromium.org/100213003/diff/100001/ui/base/ime/input_metho...
ui/base/ime/input_method_initializer.cc:26: #elif defined(USE_AURA) &&
!defined(OS_WIN)
Better to be defined(OS_LINUX).

https://codereview.chromium.org/100213003/diff/100001/ui/base/ime/input_metho...
ui/base/ime/input_method_initializer.cc:40: #elif defined(USE_AURA)
Ditto.

https://codereview.chromium.org/100213003/diff/100001/ui/ozone/ime/input_meth...
File ui/ozone/ime/input_method_context_factory_ozone.h (right):

https://codereview.chromium.org/100213003/diff/100001/ui/ozone/ime/input_meth...
ui/ozone/ime/input_method_context_factory_ozone.h:13: class
LinuxInputMethodContextDelegate;
You don't need these two forward declarations.
It must be done in linux_input_method_context_factory.h.  Otherwise you don't
need these two classes.

[kondapallykalyan, 2013-12-11 10:21:35]

On 2013/12/11 09:31:14, Yuki wrote:
> Having said that, before discussing how to do it, you should get agreement on
> the basic idea from other owners and related people.

K, will create a new issue for this.

> Is there any chance to be use_ozone==1 but desktop_linux==0 ?
> I think ozone is desktop_linux-based.  So you don't need this change.


This is to fix linking issues when chromeos=1 and Ozone=1 (building chromium
browser on linux desktop)



>
https://codereview.chromium.org/100213003/diff/100001/ui/base/ime/input_metho...
> ui/base/ime/input_method_factory.cc:17: #elif defined(USE_AURA)
> Better to be defined(USE_AURA) && defined(OS_LINUX).
> This shouldn't be applied to other Aura builds.
> 
>
https://codereview.chromium.org/100213003/diff/100001/ui/base/ime/input_metho...
> ui/base/ime/input_method_factory.cc:66: #elif defined(USE_AURA)
> Ditto.
> 
>
https://codereview.chromium.org/100213003/diff/100001/ui/base/ime/input_metho...
> File ui/base/ime/input_method_initializer.cc (right):
> 
>
https://codereview.chromium.org/100213003/diff/100001/ui/base/ime/input_metho...
> ui/base/ime/input_method_initializer.cc:16: #elif defined(USE_AURA)
> It's not a good idea to swap OS_WIN and USE_AURA.
> Please use defined(USE_AURA) && defined(OS_LINUX) instead.
> 
> Remember Mac could use Aura in future.
> 
>
https://codereview.chromium.org/100213003/diff/100001/ui/base/ime/input_metho...
> ui/base/ime/input_method_initializer.cc:26: #elif defined(USE_AURA) &&
> !defined(OS_WIN)
> Better to be defined(OS_LINUX).
> 
>
https://codereview.chromium.org/100213003/diff/100001/ui/base/ime/input_metho...
> ui/base/ime/input_method_initializer.cc:40: #elif defined(USE_AURA)
> Ditto.
> 
>
https://codereview.chromium.org/100213003/diff/100001/ui/ozone/ime/input_meth...
> File ui/ozone/ime/input_method_context_factory_ozone.h (right):
> 
>
https://codereview.chromium.org/100213003/diff/100001/ui/ozone/ime/input_meth...
> ui/ozone/ime/input_method_context_factory_ozone.h:13: class
> LinuxInputMethodContextDelegate;
> You don't need these two forward declarations.
> It must be done in linux_input_method_context_factory.h.  Otherwise you don't
> need these two classes.

fixed.

[Yuki, 2013-12-11 13:41:57]

LGTM.

You'd better to respond to each review comment, so it's easy to track each
issue.  There is "done" button.

https://codereview.chromium.org/100213003/diff/120001/ui/ozone/ozone.gyp
File ui/ozone/ozone.gyp (right):

https://codereview.chromium.org/100213003/diff/120001/ui/ozone/ozone.gyp#newc...
ui/ozone/ozone.gyp:41: 'ime/input_method_context_factory_ozone.h',
nit: Sort files in alphabetical order.

[kalyank, 2013-12-11 18:17:57]

https://codereview.chromium.org/100213003/diff/120001/ui/ozone/ozone.gyp
File ui/ozone/ozone.gyp (right):

https://codereview.chromium.org/100213003/diff/120001/ui/ozone/ozone.gyp#newc...
ui/ozone/ozone.gyp:41: 'ime/input_method_context_factory_ozone.h',
On 2013/12/11 13:41:57, Yuki wrote:
> nit: Sort files in alphabetical order.

Done.

[kalyank, 2013-12-11 19:08:53]

On 2013/12/11 13:41:57, Yuki wrote:
> LGTM.
> 
> You'd better to respond to each review comment, so it's easy to track each
> issue.  There is "done" button.

Sorry about that.

[kalyank, 2013-12-11 19:19:01]

On 2013/12/11 18:17:57, kalyank wrote:
> https://codereview.chromium.org/100213003/diff/120001/ui/ozone/ozone.gyp
> File ui/ozone/ozone.gyp (right):
> 
>
https://codereview.chromium.org/100213003/diff/120001/ui/ozone/ozone.gyp#newc...
> ui/ozone/ozone.gyp:41: 'ime/input_method_context_factory_ozone.h',
> On 2013/12/11 13:41:57, Yuki wrote:
> > nit: Sort files in alphabetical order.
> 
> Done.

@rjkroege ping :)

[rjkroege, 2013-12-12 23:43:38]

This seems like a valid interim step until ui/base/ime is lifted out to ui/ime. 

Please add a TODO somewhere that you will fix this up once ui/base/ime has been
relocated appropriately.

spang@: can you double-check the platform changes please?

https://codereview.chromium.org/100213003/diff/140001/ui/base/ime/ime.gypi
File ui/base/ime/ime.gypi (right):

https://codereview.chromium.org/100213003/diff/140001/ui/base/ime/ime.gypi#ne...
ui/base/ime/ime.gypi:112: ['use_aura==0 or (desktop_linux==0 and use_ozone==0)',
{
These two blocks have the same condition and seem to do the same thing. They are
they separate?

https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
File ui/ozone/ime/fake_input_method_context_ozone.cc (right):

https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
ui/ozone/ime/fake_input_method_context_ozone.cc:15: // Overriden from
ui::LinuxInputMethodContext
nit: this comment is unnecessary.

https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
File ui/ozone/ime/fake_input_method_context_ozone.h (right):

https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
ui/ozone/ime/fake_input_method_context_ozone.h:9: #include
"ui/ozone/ozone_export.h"
Does this really need to be exported? Why?

[kalyank, 2013-12-13 10:35:27]

https://codereview.chromium.org/100213003/diff/140001/ui/base/ime/ime.gypi
File ui/base/ime/ime.gypi (right):

https://codereview.chromium.org/100213003/diff/140001/ui/base/ime/ime.gypi#ne...
ui/base/ime/ime.gypi:112: ['use_aura==0 or (desktop_linux==0 and use_ozone==0)',
{
On 2013/12/12 23:43:38, rjkroege wrote:
> These two blocks have the same condition and seem to do the same thing. They
are
> they separate?

desktop_linux is set to false when chromeos=1
This caused linking issues when building with chromeos=1 and ozone=1 options

https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
File ui/ozone/ime/fake_input_method_context_ozone.cc (right):

https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
ui/ozone/ime/fake_input_method_context_ozone.cc:15: // Overriden from
ui::LinuxInputMethodContext
On 2013/12/12 23:43:38, rjkroege wrote:
> nit: this comment is unnecessary.

Done.

https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
File ui/ozone/ime/fake_input_method_context_ozone.h (right):

https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
ui/ozone/ime/fake_input_method_context_ozone.h:9: #include
"ui/ozone/ozone_export.h"
On 2013/12/12 23:43:38, rjkroege wrote:
> Does this really need to be exported? Why?

Not needed, removed.

[spang, 2013-12-13 18:08:33]

lgtm

On 2013/12/13 10:35:27, kalyank wrote:
> https://codereview.chromium.org/100213003/diff/140001/ui/base/ime/ime.gypi
> File ui/base/ime/ime.gypi (right):
> 
>
https://codereview.chromium.org/100213003/diff/140001/ui/base/ime/ime.gypi#ne...
> ui/base/ime/ime.gypi:112: ['use_aura==0 or (desktop_linux==0 and
use_ozone==0)',
> {
> On 2013/12/12 23:43:38, rjkroege wrote:
> > These two blocks have the same condition and seem to do the same thing. They
> are
> > they separate?
> 
> desktop_linux is set to false when chromeos=1
> This caused linking issues when building with chromeos=1 and ozone=1 options

You can merge blocks with the same condition.

> 
>
https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
> File ui/ozone/ime/fake_input_method_context_ozone.cc (right):
> 
>
https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
> ui/ozone/ime/fake_input_method_context_ozone.cc:15: // Overriden from
> ui::LinuxInputMethodContext
> On 2013/12/12 23:43:38, rjkroege wrote:
> > nit: this comment is unnecessary.
> 
> Done.
> 
>
https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
> File ui/ozone/ime/fake_input_method_context_ozone.h (right):
> 
>
https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
> ui/ozone/ime/fake_input_method_context_ozone.h:9: #include
> "ui/ozone/ozone_export.h"
> On 2013/12/12 23:43:38, rjkroege wrote:
> > Does this really need to be exported? Why?
> 
> Not needed, removed.

[spang, 2013-12-13 18:12:13]

This is broken with chromeos==1 use_ozone==1 right?

I mean, it might build, but we'll take the chromeos path instead of the ozone
path. Right?

Michael

On 2013/12/13 18:08:33, spang wrote:
> lgtm
> 
> On 2013/12/13 10:35:27, kalyank wrote:
> > https://codereview.chromium.org/100213003/diff/140001/ui/base/ime/ime.gypi
> > File ui/base/ime/ime.gypi (right):
> > 
> >
>
https://codereview.chromium.org/100213003/diff/140001/ui/base/ime/ime.gypi#ne...
> > ui/base/ime/ime.gypi:112: ['use_aura==0 or (desktop_linux==0 and
> use_ozone==0)',
> > {
> > On 2013/12/12 23:43:38, rjkroege wrote:
> > > These two blocks have the same condition and seem to do the same thing.
They
> > are
> > > they separate?
> > 
> > desktop_linux is set to false when chromeos=1
> > This caused linking issues when building with chromeos=1 and ozone=1 options
> 
> You can merge blocks with the same condition.
> 
> > 
> >
>
https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
> > File ui/ozone/ime/fake_input_method_context_ozone.cc (right):
> > 
> >
>
https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
> > ui/ozone/ime/fake_input_method_context_ozone.cc:15: // Overriden from
> > ui::LinuxInputMethodContext
> > On 2013/12/12 23:43:38, rjkroege wrote:
> > > nit: this comment is unnecessary.
> > 
> > Done.
> > 
> >
>
https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
> > File ui/ozone/ime/fake_input_method_context_ozone.h (right):
> > 
> >
>
https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
> > ui/ozone/ime/fake_input_method_context_ozone.h:9: #include
> > "ui/ozone/ozone_export.h"
> > On 2013/12/12 23:43:38, rjkroege wrote:
> > > Does this really need to be exported? Why?
> > 
> > Not needed, removed.

[spang, 2013-12-13 18:17:20]

Actually, it might be alright since the chromeos test is

#if defined(OS_CHROMEOS) && defined(USE_X11)

On 2013/12/13 18:12:13, spang wrote:
> This is broken with chromeos==1 use_ozone==1 right?
> 
> I mean, it might build, but we'll take the chromeos path instead of the ozone
> path. Right?
> 
> Michael
> 
> On 2013/12/13 18:08:33, spang wrote:
> > lgtm
> > 
> > On 2013/12/13 10:35:27, kalyank wrote:
> > > https://codereview.chromium.org/100213003/diff/140001/ui/base/ime/ime.gypi
> > > File ui/base/ime/ime.gypi (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/100213003/diff/140001/ui/base/ime/ime.gypi#ne...
> > > ui/base/ime/ime.gypi:112: ['use_aura==0 or (desktop_linux==0 and
> > use_ozone==0)',
> > > {
> > > On 2013/12/12 23:43:38, rjkroege wrote:
> > > > These two blocks have the same condition and seem to do the same thing.
> They
> > > are
> > > > they separate?
> > > 
> > > desktop_linux is set to false when chromeos=1
> > > This caused linking issues when building with chromeos=1 and ozone=1
options
> > 
> > You can merge blocks with the same condition.
> > 
> > > 
> > >
> >
>
https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
> > > File ui/ozone/ime/fake_input_method_context_ozone.cc (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
> > > ui/ozone/ime/fake_input_method_context_ozone.cc:15: // Overriden from
> > > ui::LinuxInputMethodContext
> > > On 2013/12/12 23:43:38, rjkroege wrote:
> > > > nit: this comment is unnecessary.
> > > 
> > > Done.
> > > 
> > >
> >
>
https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
> > > File ui/ozone/ime/fake_input_method_context_ozone.h (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/100213003/diff/140001/ui/ozone/ime/fake_input...
> > > ui/ozone/ime/fake_input_method_context_ozone.h:9: #include
> > > "ui/ozone/ozone_export.h"
> > > On 2013/12/12 23:43:38, rjkroege wrote:
> > > > Does this really need to be exported? Why?
> > > 
> > > Not needed, removed.

[kalyank, 2013-12-13 18:34:24]

On 2013/12/13 18:17:20, spang wrote:
> Actually, it might be alright since the chromeos test is
> 
> #if defined(OS_CHROMEOS) && defined(USE_X11)
> 
> On 2013/12/13 18:12:13, spang wrote:
> > This is broken with chromeos==1 use_ozone==1 right?
> > 
> > I mean, it might build, but we'll take the chromeos path instead of the
ozone
> > path. Right?
> > 
> > Michael
> > 

Yes, we have all X11 checks for Chrome-OS. This path will be taken only for
Ozone(X11=0).

[kondapallykalyan, 2013-12-16 17:20:38]

@rjkroege can you have another look ?

[rjkroege, 2013-12-16 23:31:17]

*/ozone/* lgtm

[commit-bot: I haz the power, 2013-12-17 22:47:29]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/kalyan.kondapally@intel.com/100213003/...

[commit-bot: I haz the power, 2013-12-18 01:50:08]

Change committed as 241442