1. 21 Aug, 2014 - 1 commit
  2. 15 Apr, 2014 - 1 commit
    • Jocelyn Turcotte's avatar
      Fix how NewPopupDisposition is exposed in QQuickWebEngineView · 4d1d3302
      Jocelyn Turcotte authored
      
      I initially misintepreted the meaning of the enum, assuming that it
      meant that the window should possibly be blocked. The user_gesture
      parameter in WebContentsDelegate::AddNewContents is actually doing
      this, while the popup disposition means that JavaScript requested
      the window to be opened without one of the standard decoration (i.e.
      status bar, menu bar, tool bar, etc.).
      
      Update the QtQuick API to reflect this, renaming the "isPopup"
      parameter to a more familiar "isUserInitiated".
      
      The popup disposition is named "dialog" to match the previous
      QWebPage::WebModalDialog enum.
      
      Change-Id: Ib0c4bc53671fcf0dd9499aa1be2bbc8c494ba49e
      Reviewed-by: default avatarMichael Bruning <michael.bruning@digia.com>
      4d1d3302
  3. 13 Feb, 2014 - 1 commit
    • Jocelyn Turcotte's avatar
      QQuickWebEngineView new window API refactoring · b81a337a
      Jocelyn Turcotte authored
      
      Improve the code and API in a few ways:
      - Expose a more discoverable "request" argument in the signal.
      - Use the request as the carrier of the backend WebContentsAdapter
        and get rid of our handle.
      - Put the adoption method (renamed to openIn) on the request object
        and keep the view API clean of a context-specific adoptHandle method.
      - Use an enum instead of strings for the new view destination.
      - Do not let JavaScript own the request object since it won't be
        necessary until we want to support asynchronous view attachment.
        We can create the request object on the heap and let the JavaScript
        engine own the object once we want to support it.
      - Move the request class to its own header.
      - Replace tabs.currentView by currentWebView in the quicknanobrowser
        qml code since we now need this property on the root object anyway.
      
      Change-Id: I40d7d15255f516ead9f3e414dd587bf345e6ca4b
      Reviewed-by: default avatarSimon Hausmann <simon.hausmann@digia.com>
      b81a337a
  4. 28 Nov, 2013 - 1 commit
    • Jocelyn Turcotte's avatar
      Moving sources to src part 1: Move files. · fd61d752
      Jocelyn Turcotte authored
      This only move files without adjusting any paths.
      
      This moves:
      - lib/quick -> src/webengine/api (API files)
        lib/quick -> src/webengine (other files)
        This contains the main QtWebEngine module library since
        <ec7b2ee7
      
      >.
      - lib/widgets -> src/webenginewidgets
        Also rename this directory to match its module name and rename Api to api.
      - lib -> src/core
      - process -> src/process
      - resources -> src/core/resources
      - tools/* -> tools/scripts/
      
      The build directory is spread as follow:
      - build/build.pro -> src/core/gyp_run.pro
      - build/qmake_extras/* -> src/core/ (for the host and target .pro files)
      - build/qmake -> tools/qmake
      - Build related scripts -> tools/buildscripts
      
      Change-Id: I0cded1de772c99c0c1da6536c9afea353236b4a1
      Reviewed-by: default avatarZeno Albisser <zeno.albisser@digia.com>
      Reviewed-by: default avatarPierre Rossi <pierre.rossi@gmail.com>
      Reviewed-by: default avatarAndras Becsi <andras.becsi@digia.com>
      fd61d752
  5. 11 Jun, 2013 - 1 commit
  6. 10 Jun, 2013 - 1 commit
    • Pierre Rossi's avatar
      And shell is out ! · 65558744
      Pierre Rossi authored
      Introduce a few more bits of our own very basic implementations
      (URLRequestContextGetter and NetworkDelegate subclasses).
      
      Still need to figure out the appropriate dependancies in blinq.gypi
      65558744
  7. 04 Jun, 2013 - 1 commit