On 31 July 2017 at 12:02, Robert Helling <[email protected]> wrote: > Hi, > > On 31. Jul 2017, at 01:24, Dirk Hohndel <[email protected]> wrote: > > 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? > > 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) > 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? > > Because quite frankly, I think we'd be better off without needing either > WebKit or WebEngine... > > > just a quick reminder of why besides the windows problem we currently cannot > give up webkit in favour of webengine: The way page breaks are currently > implemented in pricing uses webkit technology. This come from the fact that > from its origin html (and its rendering) is not aware of page breaks. So we > put more and more in a page until it flows over than roll back and print and > continue. For the adding more and rolling back, we are accessing elements of > the html syntax tree via tags. And those (“find me the next <p> element!”) > are not available in web engine. In the documentation it says you are > supposed to do such things in a javascript. Except so far, nobody has > rewritten our logic in javascript (and I would have to learn that language > before I could attempt that). >
yeah, i was about to start on the WebEngine port but the Windows / Mingw problem with building WebEngine is a major showstopper. we can use the DOM / JS function getElementsByTagName() to find page breaks and such a call can be made from the C++ side using QWebEngine's QWebChannel. > I agree that the one Facebook page that we need to display is so simple we > could probably get away without an html renderer. But printing… once things > got even worse, at some point, it might be easier to bundle TeX… (ahem). > i must admit i was fond of the TeX idea. my understanding is that we went with HTML since more users know how to use it and because TeX had a big footprint (100MB?). lubomir -- _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
