Author Topic: QtWebEngine status (depends on Chrome / Chromium patches)  (Read 727 times)

pocock

  • Full Member
  • ***
  • Posts: 240
  • Karma: +23/-0
    • View Profile
QtWebEngine status (depends on Chrome / Chromium patches)
« on: October 07, 2020, 06:56:35 am »
A lot of interesting things depend on QtWebEngine

QtWebEngine depends on Chromium, they periodically take a snapshot of the Chromium code from Google

Chromium patching is already in progress, is it complete?

I opened a bug for it within QtWebEngine

When somebody confirms the Chrome patches are ready, the QtWebEngine developers could enable it in their list of supported platforms.  They will probably need to know the minimum supported version of the Chromium code, they probably won't have time to look through the Chromium history, if anybody could add comments to the Qt bug report that would be really helpful.

If they can cherry-pick patches that haven't been accepted by Google, please also comment on that Qt bug report
Debian Developer
https://danielpocock.com

MauryG5

  • Hero Member
  • *****
  • Posts: 545
  • Karma: +15/-1
    • View Profile
Re: QtWebEngine status (depends on Chrome / Chromium patches)
« Reply #1 on: January 26, 2021, 03:12:05 pm »
Hey Daniel, do you mean there is a hang on this patch and therefore all Chromium development on Power has stalled? Damn you have to try to fix it then, you can't even download it anymore and it's a shame because it's the best together with Firefox and it's a big lack for us in my opinion ...

madscientist159

  • Raptor Staff
  • *****
  • Posts: 47
  • Karma: +10/-0
    • View Profile
Re: QtWebEngine status (depends on Chrome / Chromium patches)
« Reply #2 on: January 27, 2021, 10:51:09 am »
Hey Daniel, do you mean there is a hang on this patch and therefore all Chromium development on Power has stalled? Damn you have to try to fix it then, you can't even download it anymore and it's a shame because it's the best together with Firefox and it's a big lack for us in my opinion ...

It's still being updated:

https://github.com/leo-lb/ungoogled-chromium/commit/362ec8584e373b798f9e3e45f4791b2dae2d0ee3

As usual, Google is not interested in merging patches, but that doesn't mean the community can't keep working around them downstream.  As far as what it will take to convince Qt...well, that's another organization that has a long history of ignoring user requests.  If there's a way to patch Qt downstream based on the existing Chromium port, that's probably the best bet.

As far as Google "killing" Chromium, all I see is they're moving the Google backend access into the proprietary builds.  From my perspective, that's actually a plus -- no hidden sync with Google servers when using the open versions, and less to need to "unGoogle" over time.  Frankly, if one is OK sharing all that data with Google in the first place, why not go buy a Chromebook or use Windows on x86....  ;)

MauryG5

  • Hero Member
  • *****
  • Posts: 545
  • Karma: +15/-1
    • View Profile
Re: QtWebEngine status (depends on Chrome / Chromium patches)
« Reply #3 on: January 27, 2021, 01:19:26 pm »
Well Tim then we will wait for it to be available again and so I can download it on Ubuntu as well. Instead I wrote about the discussion related to the RAM reading problems of slot b1, I need you to give me support and if I have to, I will open a tiket directly to Raptor support because I have not received an answer on that discussion ...

pocock

  • Full Member
  • ***
  • Posts: 240
  • Karma: +23/-0
    • View Profile
Re: QtWebEngine status (depends on Chrome / Chromium patches)
« Reply #4 on: January 27, 2021, 01:31:22 pm »
As far as what it will take to convince Qt...well, that's another organization that has a long history of ignoring user requests.  If there's a way to patch Qt downstream based on the existing Chromium port, that's probably the best bet.

Do you know if anybody is actively pursuing this?

Do you know any sources of funding for work like this?

I'm personally happy to do things on an ad-hoc basis from time to time, such as the 4k page size issue.  But this feels like it could take a bit more effort, it may be more productive for somebody to get to know it and stick with it over the long term.  I've already worked on some proprietary Qt-based solutions, for example, I was in the Kondor+ development center when they were migrating to Qt around 2007/2008 and we are also using TelepathyQt in reSIProcate so I have some impression of the minimum effort involved.
Debian Developer
https://danielpocock.com