MXE and Qt 5.9.0

[Lubomir I. Ivanov]

On 31 July 2017 at 02:46, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> On 31 July 2017 at 02:24, Dirk Hohndel <dirk at hohndel.org> wrote:
>>
>>> On Jul 30, 2017, at 2:29 PM, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>>>
>>> On 30 July 2017 at 23:21, Dirk Hohndel <dirk at hohndel.org> wrote:
>>>> 5.7 didn't appear to include the esri plugin... That's why I tried to switch to 5.9. And because of the way mxe is organized, that brought with it the switch from GCC 4.x to 5.4 which is what I suspect might be the cause of my problem...
>>>>
>>>
>>> https://github.com/qt/qtlocation/tree/5.7
>>> indeed does not include the ESRI plugin so it's a new addition. but
>>> maybe you can try building the ESRI plugin with Qt 5.7.
>>>
>>> i was able to build the ESRI plugin locally, here is how:
>>>
>>> i have the official Qt 5.9.0 binary Mingw packages for Windows
>>>
>>> - downloaded this 5.9.0 tree in a zip
>>> https://github.com/qt/qtlocation/tree/5.9.0
>>> - extracted it in a folder qtlocation-5.9.0
>>> - cd qtlocation-5.9.0/src/plugins/geoservices/esri
>>> - qmake
>>> - make
>>> this resulted in .dll and .a files created in:
>>> qtlocation-5.9.0/plugins/geoservices
>>
>> I will give this a try,
>> The other thing that I was thinking about was "why do we need WebKit?"
>> So part of the argument for keeping WebKit was that WebEngine can't be cross built on Windows.
>> But then the question becomes, why do we need either?
>>
>
> the bundled docs also open inside a web page, which uses WebKit (Help
> -> Documentation)
> this can be easily replaced with opening a URI inside the user's
> preferred web browser.
>
>> Right now we have two things that need this functionality: Facebook and Printing.
>> The Facebook support really isn't all that complicated and it seems ridiculous to have a huge monstrosity like WebKit (27MB on Windows) as part of our binary for that. It's literally 20% of the size of our binary (btw: the second largest piece is icudt56 at 25MB... yikes)
>
> i won't comment on the facebook support as i haven't even tested it.
> i know it opens a webpage inside the settings window.
>
>> Printing is more complicated. I'm not quite sure how much we really need to have WebKit for that - I remember that you said earlier, Lubomir, that the layout code very much needs some WebKit functionality. But the question seems worth asking - what features do we actually need? What would it take to implement them differently?
>
> on the printing side and for the time being we cannot really get rid
> of the web page renderer dependency if we want to support templates.
> we need a full blown web page renderer for rendering the pages which
> the user wants to print using Grantlee, CSS and HTML templates.
>
> back in the day we didn't needed any of that because we only had 3-4
> predefined templates (table, 1 dive per page, 4 dives per page..etc).
>
> if we roll back to that, Grantlee and a web page renderer won't be
> needed, but we limit the user a lot and there will be complains, since
> there are template users out there.
> if we decide to to move away from WebKit or WebView and write our own
> HTML web page renderer, that's a massive task that can take years.
> if we decide to move away from HTML/CSS and write our own language for
> printing templates or some sort of a HTML subset with some predefined
> list of items / widgets to render, we become less user friendly and
> less flexible, and that's not an easy task to write as code either.
>

another option would be to try to do the following:
- remain using the CSS / HTML / Grantlee scheme
- generate a HTML page and write the profile images at a temporary folder
- instruct the user to print the pages inside his preferred browser
- open the HTML page inside the user preferred browser

the problem with this is that someone might still be using an old
version of Internet Explorer on Windows or browser-X that's just
broken in some way.
that's not a great user experience, either. ATM users are writing
templates specifically for the browser that Subsurface bundles.
it means that we won't be sandboxing the renderer and there might be
reports such as "my template no longer looks right after Subsurface
v.X.Y.Z.

lubomir
--