This repository has been archived by the owner. It is now read-only.

LuneOS is broken (LuneOS patches not rebased on qt5-qtwebengine for 5.10.1) #1459

Open
ollieparanoid opened this Issue May 2, 2018 · 10 comments

Comments

Projects
None yet
5 participants
@ollieparanoid
Member

ollieparanoid commented May 2, 2018

LuneOS UI is packaged in postmarketOS. Thanks to the work from @magmastonealex and @PureTryOut, we had the QT 5.9 version of qt5-qtwebengine working with patches required for LuneOS on top. However, Alpine Linux (which postmarketOS is based on) switched to QT 5.10.1 now, which means our QT packages must be upgraded as well.

Unfortunately the patches from LuneOS don't apply anymore. I found patches for QT 5.10.0 here, but they don't work with 5.10.1 either.

To make the repository build script go through again, I'll move qt5-qtwebengine from aports/main to aports/luna and disable the luna folder from compiling for now. In the meantime I've learned that ncopa is looking into providing qt5-qtwebengine in Alpine Linux (without LuneOS patches though, but it's still great) and he said the musl specific patches we have are helpful.

@shr-project, @ericblade, @Tofee, @Herrie82:

  • Do you have a patchset for QT 5.10.1 as well, or do you have plans to create one?
  • Would it be possible at some point in the future to have LuneOS UI working without patching QT?
  • What happens when running LuneOS with the stock qt5-qtwebengine, without the LuneOS specific patches?
@shr-project

This comment has been minimized.

shr-project commented May 2, 2018

The patches in https://github.com/webOS-ports/meta-webos-ports/tree/master/meta-luneui/recipes-qt/qt5/qtwebengine aren't ready even for 5.10.0, I run out of time before I was able to finish it, so even when they apply to 5.10.0 it failed to build later and in the end I've removed qtwebengine from LuneOS temporarily until I find more time to finish it.

Rebasing them for 5.10.1 should be relatively easy (or at least easier than from 5.9.5, but still the build issue would need to be resolved). I don't plan spending enough time on this in following months. Some of the patches aren't really upstream-able, so things like palm bridge won't probably be ever available without patching qtwebengine.

ollieparanoid added a commit that referenced this issue May 2, 2018

Disable LuneOS UI (see #1459) [skip ci]
Moved from aports/main to aports/luna, so we can disable the entire
folder from building in the binary repository:
* qt5-qtwebengine
* postmarketos-ui-luna
@ollieparanoid

This comment has been minimized.

Member

ollieparanoid commented May 2, 2018

Thanks for the instant answer!

in the end I've removed qtwebengine from LuneOS

And LuneOS still works?
Can we just remove it from the dependencies and that's it?

@Tofee

This comment has been minimized.

Tofee commented May 2, 2018

@shr-project

This comment has been minimized.

shr-project commented May 2, 2018

@ericblade

This comment has been minimized.

ericblade commented May 3, 2018

I've been gone far too long to be able to offer too much useful insight here. I'm curious as to if there's a better way to architect the Bridge, and maybe other pieces, though, so that it doesn't require patching qtwebengine and chromium quite so much.

I just dug through the patches, and keeping in mind that i'm really not familiar much at all with what's going on in the LuneOS WebAppManager.. i see a few things that look like they really should be handled at the WebAppManager side, but they are really small potatoes compared to the bigger patches that include the Bridge and such. One thing is that I'm not sure what the intended purpose for several of the patches is. I mean, I can read what the code does but I have no idea what the background is, or what features of LuneOS need it.

Like, the Standard Font patch, I'd probably consider implementing that as a default CSS element in the web app manager. Password Echo, I'd probably follow the "TODO" in Chromium, that says to default it to on if there's a time delay for it, upstream it, and use that. RequestQuotaPermission looks like it should be able to be built in by implementing whatever function it calls back to. There's a lot there, though.

@ollieparanoid

This comment has been minimized.

Member

ollieparanoid commented May 7, 2018

Alpine Linux has qt5-qtwebengine packaged in their testing folder now, and I guess that there will soon be binary packages available. When that happens, we could enable LuneOS in postmarketOS again and simply use the unpatched qt5-qtwebengine as a short term solution. (And afterwards, apply the LuneOS patches on top of the Alpine packages again.)

Thanks for all the answers!

@Herrie82

This comment has been minimized.

Herrie82 commented May 11, 2018

@ericblade Thanks for your review. A lot of this code has gone through a lot of iterations (i.e. back from when it was still webkit1 and Qt 4.6) up to where it is now. I'm sure some things could be done better or in a different way. With the recently released code for the WAM with webOS OSE we'll have to see what would be the best way forward.

The biggest issue so far has been the Chromium updates in QtWebEngine since they skip quite some Chromium versions between a major Qt release (usually 4 or 5), so quite some of the Chromium code that we patch changes. So with each new Qt release these patches need to be reworked quite a bit as well.

@ericblade

This comment has been minimized.

ericblade commented May 11, 2018

@Herrie82 oh, i'm sure. i am familiar with the history :-) Just pointing out there's probably ways of doing some or most of that internal to webappmanager, but it's going to be varying levels of difficulty. I suspect that something like the font patch could pretty quickly be done by inserting a default CSS style sheet that applies to everything unless overridden in the app. If QWebEngine doesn't support that, then I'd consider that a missing feature on their side. Much of the rest of it, I'd need a bit more understanding of what the purpose of it is to come up with good ideas for re-doing the patches in a place that's easier to control. I'd be happy to have that conversation perhaps in a more appropriate github location, or IRC, if we've got a group of people that are familiar with that stuff.

I don't suspect that LuneOS is wanting to pick up the OSE WebAppManager? Seems there's some upsides but some downsides with that idea probably as well.

@shr-project

This comment has been minimized.

shr-project commented Jun 18, 2018

@Tofee finished my partial rebase for Qt 5.11 and fixed most of runtime issues, the latest qtwebengine changes are here:
https://github.com/webOS-ports/qtwebengine/commits/webOS-ports/master-qt5.11
https://github.com/webOS-ports/qtwebengine-chromium/commits/65-based-wp

we don't have fixed set of patches for 5.10.

@Tofee

This comment has been minimized.

Tofee commented Jun 18, 2018

FYI, I am also currently working on removing some of the patches, and prefer having external components, for instance via QtWebChannel or QTWEBENGINE_CHROMIUM_FLAGS. Less patching is also a good thing for LuneOS :-)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.