On 31 July 2017 at 02:24, Dirk Hohndel <[email protected]> wrote: > >> On Jul 30, 2017, at 2:29 PM, Lubomir I. Ivanov <[email protected]> wrote: >> >> On 30 July 2017 at 23:21, Dirk Hohndel <[email protected]> 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. > > Because quite frankly, I think we'd be better off without needing either > WebKit or WebEngine... > i can agree, but with WebKengine - the HTML printing template support needs to go too. lubomir -- _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
