ubuntu-webapps-bugs team mailing list archive

[Chris Coulson <chris.coulson@xxxxxxxxxxxxx>]

Public bug reported:

WebView.icon has a few limitations that can only really be resolved by
offering a replacement to this API:

- It provides the remote URL of the icon, requiring the application to use Qt's network stack to download it. Applications need to be careful for icongnito webviews, as the icon download may leave a footprint on disk.
- It doesn't allow the application to support touch icons (<link rel="apple-touch-icon">)
- It doesn't allow the application to select an appropriate icon when there is more than one.

I propose we replace it with something like this:

class OxideQQuickWebView {
  QLIst<OxideQQuickFavicon> icons() const;
}

class OxideQQuickFavicon {
  enum Type {
    TypeIcon,
    TypeTouch,
    TypePrecomposedTouch
  }

  QUrl imageUrl() const;
  QUrl resourceUrl() const;
  Type type() const;
  QSizeF size() const;
}

imageUrl() will provide an image: URL that can be passed to Image
elements, and Oxide will register an image provider that will handle the
image download via Chromium's network stack.

The API should probably provide a way to create a QImage too, although
that would need to asynchronous.

** Affects: oxide
     Importance: Medium
         Status: Triaged

** Changed in: oxide
       Status: New => Triaged

** Changed in: oxide
   Importance: Undecided => Medium

** Description changed:

  WebView.icon has a few limitations that can only really be resolved by
  offering a replacement to this API:
  
  - It provides the remote URL of the icon, requiring the application to use Qt's network stack to download it. Applications need to be careful for icongnito webviews, as the icon download may leave a footprint on disk.
  - It doesn't allow the application to support touch icons (<link rel="apple-touch-icon">)
  - It doesn't allow the application to select an appropriate icon when there is more than one.
  
  I propose we replace it with something like this:
  
  class OxideQQuickWebView {
-   QLIst<OxideQQuickFavicon> icons() const;
+   QLIst<OxideQQuickFavicon> icons() const;
  }
  
  class OxideQQuickFavicon {
-   enum Type {
-     TypeIcon,
-     TypeTouch,
-     TypePrecomposedTouch
-   }
+   enum Type {
+     TypeIcon,
+     TypeTouch,
+     TypePrecomposedTouch
+   }
  
-   QUrl imageUrl() const;
-   QUrl resourceUrl() const;
-   Type type() const;
-   QSizeF size() const;
+   QUrl imageUrl() const;
+   QUrl resourceUrl() const;
+   Type type() const;
+   QSizeF size() const;
  }
  
  imageUrl() will provide an image: URL that can be passed to Image
  elements, and Oxide will register an image provider that will handle the
- image download via Chromium's network stack
+ image download via Chromium's network stack.
+ 
+ The API should probably provide a way to create a QImage too, although
+ that would need to asynchronous.

-- 
You received this bug notification because you are a member of Ubuntu
WebApps bug tracking, which is subscribed to Oxide.
https://bugs.launchpad.net/bugs/1532903

Title:
  Replace WebView.icon

Status in Oxide:
  Triaged

Bug description:
  WebView.icon has a few limitations that can only really be resolved by
  offering a replacement to this API:

  - It provides the remote URL of the icon, requiring the application to use Qt's network stack to download it. Applications need to be careful for icongnito webviews, as the icon download may leave a footprint on disk.
  - It doesn't allow the application to support touch icons (<link rel="apple-touch-icon">)
  - It doesn't allow the application to select an appropriate icon when there is more than one.

  I propose we replace it with something like this:

  class OxideQQuickWebView {
    QLIst<OxideQQuickFavicon> icons() const;
  }

  class OxideQQuickFavicon {
    enum Type {
      TypeIcon,
      TypeTouch,
      TypePrecomposedTouch
    }

    QUrl imageUrl() const;
    QUrl resourceUrl() const;
    Type type() const;
    QSizeF size() const;
  }

  imageUrl() will provide an image: URL that can be passed to Image
  elements, and Oxide will register an image provider that will handle
  the image download via Chromium's network stack.

  The API should probably provide a way to create a QImage too, although
  that would need to asynchronous.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oxide/+bug/1532903/+subscriptions