Use MessagePumpDefault for MessagePumpForUI for chromecast build as chromecast doesn't have/care us…

Use MessagePumpDefault for MessagePumpForUI for chromecast build as chromecast doesn't have/care user input events.

BUG=336640

[darin (slow to review), 2014-04-14 04:52:30]

https://codereview.chromium.org/223593002/diff/1/base/message_loop/message_lo...
File base/message_loop/message_loop.h (right):

https://codereview.chromium.org/223593002/diff/1/base/message_loop/message_lo...
base/message_loop/message_loop.h:41: #elif defined(CHROMECAST_BUILD)
For this CL, it seems sensible to instead draft behind the Ozone work. I
recommend reaching out to sadrul@. He's been very busy refactoring this code to
make it easier to dependency inject the right thing.

[lcwu1, 2014-04-15 06:32:33]

https://codereview.chromium.org/223593002/diff/1/base/message_loop/message_lo...
File base/message_loop/message_loop.h (right):

https://codereview.chromium.org/223593002/diff/1/base/message_loop/message_lo...
base/message_loop/message_loop.h:41: #elif defined(CHROMECAST_BUILD)
On 2014/04/14 04:52:30, darin wrote:
> For this CL, it seems sensible to instead draft behind the Ozone work. I
> recommend reaching out to sadrul@. He's been very busy refactoring this code
to
> make it easier to dependency inject the right thing.

Since Chromecast doesn't have or care user input events, we feel the code is
much simpler to use the existing stub MessagePumpDefault for UI than to create
another stub implementation behind the ozone port. We will reach out to sadrul@
on this.

[darin (slow to review), 2014-04-15 06:38:55]

From talking with the Ozone team, my understanding is that it is quite
trivial to use Ozone in a configuration that doesn't have input events. It
should be pretty simple. If not, it would be great to understand why since
we are recommending this approach for all new Linux-derived ports.

-Darin


On Mon, Apr 14, 2014 at 11:32 PM, <lcwu@chromium.org> wrote:

>
> https://codereview.chromium.org/223593002/diff/1/base/
> message_loop/message_loop.h
> File base/message_loop/message_loop.h (right):
>
> https://codereview.chromium.org/223593002/diff/1/base/
> message_loop/message_loop.h#newcode41
> base/message_loop/message_loop.h:41: #elif defined(CHROMECAST_BUILD)
> On 2014/04/14 04:52:30, darin wrote:
>
>> For this CL, it seems sensible to instead draft behind the Ozone work.
>>
> I
>
>> recommend reaching out to sadrul@. He's been very busy refactoring
>>
> this code to
>
>> make it easier to dependency inject the right thing.
>>
>
> Since Chromecast doesn't have or care user input events, we feel the
> code is much simpler to use the existing stub MessagePumpDefault for UI
> than to create another stub implementation behind the ozone port. We
> will reach out to sadrul@ on this.
>
> https://codereview.chromium.org/223593002/
>

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

[lcwu1, 2014-04-15 07:06:46]

Our initial thought is that Chromium already has a stub implementation
(MessagePumpDefault) for a configuration that doesn't have user inputs. So
instead of creating an indirect stub behind ozone, why not just use it. Also
enabling ozone (at the top level) means everything that ozone provides will be
picked up, including the gfx that we are not ready to use yet. I am not sure if
we will be able to set USE_OZONE only in base.gyp when chromecast=1. If that
works, we might be able to use ozone for hooking up the stub implementation.
Another approach is to modify the gyp file to pick up
base/message_loop/message_pump_default.h when chromecast=1 at build time, which
will require some code re-factoring.

Le-chun 

On 2014/04/15 06:38:55, darin wrote:
> From talking with the Ozone team, my understanding is that it is quite
> trivial to use Ozone in a configuration that doesn't have input events. It
> should be pretty simple. If not, it would be great to understand why since
> we are recommending this approach for all new Linux-derived ports.
> 
> -Darin
> 
> 
> On Mon, Apr 14, 2014 at 11:32 PM, <mailto:lcwu@chromium.org> wrote:
> 
> >
> > https://codereview.chromium.org/223593002/diff/1/base/
> > message_loop/message_loop.h
> > File base/message_loop/message_loop.h (right):
> >
> > https://codereview.chromium.org/223593002/diff/1/base/
> > message_loop/message_loop.h#newcode41
> > base/message_loop/message_loop.h:41: #elif defined(CHROMECAST_BUILD)
> > On 2014/04/14 04:52:30, darin wrote:
> >
> >> For this CL, it seems sensible to instead draft behind the Ozone work.
> >>
> > I
> >
> >> recommend reaching out to sadrul@. He's been very busy refactoring
> >>
> > this code to
> >
> >> make it easier to dependency inject the right thing.
> >>
> >
> > Since Chromecast doesn't have or care user input events, we feel the
> > code is much simpler to use the existing stub MessagePumpDefault for UI
> > than to create another stub implementation behind the ozone port. We
> > will reach out to sadrul@ on this.
> >
> > https://codereview.chromium.org/223593002/
> >
> 
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

[sadrul, 2014-04-15 10:49:56]

On 2014/04/15 07:06:46, lcwu1 wrote:
> Our initial thought is that Chromium already has a stub implementation
> (MessagePumpDefault) for a configuration that doesn't have user inputs. So
> instead of creating an indirect stub behind ozone, why not just use it. Also
> enabling ozone (at the top level) means everything that ozone provides will be
> picked up, including the gfx that we are not ready to use yet. I am not sure
if
> we will be able to set USE_OZONE only in base.gyp when chromecast=1. If that
> works, we might be able to use ozone for hooking up the stub implementation.
> Another approach is to modify the gyp file to pick up
> base/message_loop/message_pump_default.h when chromecast=1 at build time,
which
> will require some code re-factoring.

You should be able to use either the MessagePumpGlib (if you already depend on
glib) or MessagePumpLibevent. Neither message-pump directly deals with user
inputs anymore, and so should be suitable for your use. For OZONE, we use the
latter. On Linux and Chrome OS, we currently use MPGlib, although the plan is
that for Chrome OS, we would eventually switch to MPLibevent too:
http://crbug.com/240715.

> 
> Le-chun 
> 
> On 2014/04/15 06:38:55, darin wrote:
> > From talking with the Ozone team, my understanding is that it is quite
> > trivial to use Ozone in a configuration that doesn't have input events. It
> > should be pretty simple. If not, it would be great to understand why since
> > we are recommending this approach for all new Linux-derived ports.
> > 
> > -Darin
> > 
> > 
> > On Mon, Apr 14, 2014 at 11:32 PM, <mailto:lcwu@chromium.org> wrote:
> > 
> > >
> > > https://codereview.chromium.org/223593002/diff/1/base/
> > > message_loop/message_loop.h
> > > File base/message_loop/message_loop.h (right):
> > >
> > > https://codereview.chromium.org/223593002/diff/1/base/
> > > message_loop/message_loop.h#newcode41
> > > base/message_loop/message_loop.h:41: #elif defined(CHROMECAST_BUILD)
> > > On 2014/04/14 04:52:30, darin wrote:
> > >
> > >> For this CL, it seems sensible to instead draft behind the Ozone work.
> > >>
> > > I
> > >
> > >> recommend reaching out to sadrul@. He's been very busy refactoring
> > >>
> > > this code to
> > >
> > >> make it easier to dependency inject the right thing.
> > >>
> > >
> > > Since Chromecast doesn't have or care user input events, we feel the
> > > code is much simpler to use the existing stub MessagePumpDefault for UI
> > > than to create another stub implementation behind the ozone port. We
> > > will reach out to sadrul@ on this.
> > >
> > > https://codereview.chromium.org/223593002/
> > >
> > 
> > To unsubscribe from this group and stop receiving emails from it, send an
> email
> > to mailto:chromium-reviews+unsubscribe@chromium.org.

[lcwu1, 2014-06-24 22:42:18]

This CL is no longer needed and will be closed.