[Development] Deprecating modules with 5.5

[Ziller Eike]

> On Feb 6, 2015, at 09:21, Simon Hausmann <simon.hausmann at theqtcompany.com> wrote:
> 
> On Friday 6. February 2015 08.42.53 André Somers wrote:
>> Knoll Lars schreef op 5-2-2015 om 16:28:
>>> But we don’t have much of a choice, if we want to deliver an up to date
>>> web engine.
>> 
>> Perhaps it is time to ask the question then: do we want to do that? Do
>> we really need to?
>> 
>> It seems to me, that it isn't really possible to do. Not in a way that
>> doesn't require huge effort in support or pissing off everybody not on
>> one of the large main stream platforms. And the question might be: why
>> should Qt deliver an up-to-date web engine exactly? Do we really think
>> that people are going to use Qt to build advanced browsers? Sure, some
>> might (KDE comes to mind...), but you are right in your observation that
>> the technology is moving too fast and is developed between giants like
>> Google, Apple and Microsoft who could not care less about other uses or
>> other platforms than their own.
>> 
>> All the while Qt is spending effort to catch up, deprecating compilers
>> and platforms because they can't take the latest Javascript engine to
>> it, users are hapily using browers like Firefox and Chrome.
>> 
>> Perhaps it is time to conclude that Qt just can't compete in this race
>> if it doesn't want to be crushed between the giants playing this field.
>> Perhaps it is just time to settle for indeed a simpler goal: don't try
>> to provide a fully integrated full-fledged web engine, but instead
>> settle once again for a simpler alternative that we _can_ support and
>> that can be used for things like showing embedded help or showing simple
>> sites, and perhaps an API to wrap and embed the native web view provided
>> by the platform but with limited integration.
> 
> What simpler alternative do you have in mind?

One possibility that would cover the use case of “show some simple styled html without javascript” case (e.g. documentation browsers) would be to give QTextBrowser some love again, fix some bugs there, and extend some of the css and html features in it. That definitely would be “offline first”, except that anyone who cares could of course fetch content from the web for it (the text browser based help viewer backend in Qt Creator also fetches content from the help database, so that already works fine ;) )

> This "catch up" race is _exactly_ the reason why we decided to build on top of 
> Chromium and don't look at it as just a "HTML/CSS renderer" anymore but as an 
> entire platform. Unfortunately that means the platform is wide and comes with 
> a lot of code, fortunately it almost entirely eliminates the "catch up" race.
> 
> And yes, there is a surprising interest among the users of Qt to use an up-to-
> date implementation of the web platform in their Qt application. Not 
> necessarily to build a web browser that competes with Chrome, Safari and the 
> lot.
> 
> 
> Simon
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer | The Qt Company
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B