1. 09 7月, 2015 1 次提交
    • A
      Build skyx packages by default · a40fd86b
      Adam Barth 提交于
      Now that we have all the Dart packages we need in //third_party, we can build
      skyx bundles by default.
      
      As part of this change, I've made it possible to build skyx bundles on Linux
      and I've made the gn target names of the mojoms in //sky/services consistent
      with each other and with //mojo/services/public.
      
      TBR=eseidel@google.com
      
      Review URL: https://codereview.chromium.org/1227973002 .
      a40fd86b
  2. 08 7月, 2015 1 次提交
  3. 07 7月, 2015 4 次提交
  4. 03 7月, 2015 1 次提交
  5. 01 7月, 2015 1 次提交
    • A
      Build stocks.skyx · 2f4e404f
      Adam Barth 提交于
      This CL teaches the build system how to create the stocks.skyx application
      bundle. This bundle contains the stocks snapshot as well as the material design
      assets needed by the stocks app to run offline.
      
      R=eseidel@chromium.org, eseidel@google.com
      
      Review URL: https://codereview.chromium.org/1216273002.
      2f4e404f
  6. 27 6月, 2015 2 次提交
  7. 19 2月, 2015 1 次提交
  8. 18 2月, 2015 1 次提交
  9. 04 12月, 2014 1 次提交
    • J
      Simplify the thunk targets since we don't support apps as components · f6527512
      James Robinson 提交于
      Since we don't support using the component build to produce mojo apps,
      we can simplify the build targets in a few ways:
      
      *) every mojo_native_application must depend on the c system thunks,
      so just make that part of the template instead of requiring the dep
      *) there's no such thing as depending on gles2 headers from a component,
      so delete the forwarding group.
      
      Most targets that want to use the gles2 headers in a mojo context
      want to depend on an implementation through the thunks, so
      //mojo/public/c/gles2 does just that. A smaller number of targets (such
      as the implementation of the thunks) want to just depend on the headers
      but not an impl, so they can depend on //mojo/public/c/gles2:headers.
      The //mojo/public/gles target isn't that useful since the only thing we
      expose is a set of C entry points.
      
      We can probably also simplify the c system targets, but that's trickier
      due to more extensive use from the chromium side.
      
      BUG=438701
      R=viettrungluu@chromium.org
      
      Review URL: https://codereview.chromium.org/780733002
      f6527512
  10. 19 11月, 2014 1 次提交
    • J
      Use WeakBindingSet to manage inspector connections · b77b5624
      James Robinson 提交于
      The sky inspector service wants to implement a 1:N broadcast interface with whichever
      frontends want to connect. This manages the pipes using a WeakBindingSet, which is a set of
      bindings owned by the pipe combined with a list of weak pointers to those bindings allowing
      sending messages to all connected clients without having to explicitly keep track of
      which clients are connected at a particular point in time.
      
      R=eseidel@chromium.org
      
      Review URL: https://codereview.chromium.org/711413005
      b77b5624
  11. 15 11月, 2014 1 次提交
  12. 12 11月, 2014 1 次提交
    • E
      Make it possible to have multiple InspectorBackends · a1bf7bae
      Eric Seidel 提交于
      This will make it possible to connect a c++
      inspector backend in addition to the JS one.
      
      We lose the feature of running multiple inspector
      servers in this patch, but we weren't using that feature
      and could easily add it back if we plan to use it.
      
      This patch has a *ton* of boilerplate code due
      to crbug.com/431911, hopefully that will be fixed
      soon and we can delete all the Impl nonsense.
      
      R=abarth@chromium.org
      
      Review URL: https://codereview.chromium.org/710043004
      a1bf7bae
  13. 01 11月, 2014 1 次提交
  14. 29 10月, 2014 2 次提交
  15. 25 10月, 2014 1 次提交
  16. 24 10月, 2014 2 次提交