Closed beastie1 closed 9 years ago
We can consider them in future, I guess that QtWebEngine backend could be first thing using build options, being disabled by default until it will become more useful (version from Qt 5.4 so far is not very useful, doesn't do much more than "just" render pages - compared to QtWebKit it has very basic API).
as a no-programmer, can I ask what advantages this can bring? Is it a matter of size or speed? And how much enhancement we're taking about in % ? (just average, obviously)
i'm just very curious about this :)
I guess that QtWebEngine backend could be first thing using build options
It was the second thing I thought of, but I later removed it as I didn't really know how the Qt Project will manage the transition. Will QtWebKit be deprecated and removed as soon as the QtWebEngine API is complete enough or will they keep both? If the latter, then a backend build option would surely make sense.
what advantages this can bring? Is it a matter of size or speed?
Size, speed and customizability. It matters both for the individual builder as well as the package repository maintainer. And it has an impact, not only on the Otter binary itself, but also on all the dependencies that may be fetched and built in the process. Some repositories may only have, say, Hunspell and not Aspell, or vice versa. One dependency may be 300KB big and the alternative... 700KB!
@beastie1, QtWebkit will be available until Qt6, so we have years before it will be removed. I want to have ability to switch them dynamically (and possibly other backends, if someone will create them), so as soon as QtWebEngine will be mature enough then by default both will be built by default.
It seems that this topic can be now closed, build options should be discussed separately for each feature that makes sense to be configured that way (mostly extra modules, like extra backends and mail client etc.). So far we don't have features that make sense to be disabled at compile time.
Good day!
Would you consider adding build options in the future?
Right now I can think of an option to enable/disable content blocking support and another to switch between a i18n-Otter and an english-specific version.
For the future, I guess there could be options for the support of skins (native default skin, multiple skins, Opera skins), modules (feeds reader, mail, IM, etc.), extension (no extension support, Firefox API, Chrome API, etc.), spell checking (disabled, Hunspell, Aspell, etc.)