Re: [Development] Deprecating modules with 5.5
El Friday 06 February 2015, André Somers escribió: 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. This is a thought that I had several times when reading about the QtWebEngine. I understand, though, that the customers that The Qt Company is trying to appeal might not have a problem with bundling lots of libraries. Deploying to Windows, Mac (or mobile, even though here WebEngine not applies there) already means bundling lots of libraries with your application. We all know how web browsers have changed. From reasonable applications capable of fetching a file through a simple one way protocol, and displaying a mostly static multimedia content, to huge beasts that require lots of complex network (websockets, WebRTC), multimedia, graphics, devices, storage, etc. Kevin said Relying on Chromium is a horrible idea, but non-horrible solutions probably won't exist anymore if you add a web browser into the mix. You probably will have to surrender to what the upstream team that developed the browser left you. And there aren't that many upstreams. Speaking of that... What about Gecko? Is the license a problem? Or is still a technical reason? Because a long term possibility would be to team up with people in GNOME or KDE who might need a web browser engine, and speak with Mozilla to help. After all they are supposed to be a non-profit, so collaborating with other open source projects should be in their DNA. It's not like their XUL has much use outside their projects, so having some Qt and GTK+ integration and more users of their technologies should be good for their mindshare. Here are some notes on the patches that Sailfish Browser needs to embed Gecko: http://blog.idempotent.info/posts/whats-behind-sailfish-browser.html -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
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? 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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
On Feb 6, 2015, at 09:21, Simon Hausmann simon.hausm...@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@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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
On 06/02/15 08:42, André Somers an...@familiesomers.nl 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? If you ask me as a Chief Maintainer of the Qt project, I’d say: Why not as long as someone makes it happen. If you ask me as the CTO of TQtC, I’ll answer: Hell yes, we need it in the product to be competitive, especially on embedded. 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. Well, with Qt WebEngine we can actually keep up. That was the whole point of doing that change from WebKit. But yes, we can’t support it on a 10 year old compiler. But Qt is not about a least common denominator solution. We can and have to offer up to date things on newer OSes. 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. We are currently developing that simpler solution as well. It’s called Qt WebView and embeds the native web engine of the underlying platform. Unfortunately most OSes have different limitations as to how you can embed, making something that works well on all platforms very hard. Not to even mention that there is no native component to embed available on Linux. So far *we* have been that component. We will continue to need a web engine, and there is a huge amount of customer interest and need for it. Especially on the embedded side. I understand the concern of the Linux distributions. But they are only one part of the picture. Even though Qt has a very special position inside the Linux stack, it is used much more broadly. We can try to find solutions that work for the Linux distributions, but we’ve always had this kind of problems (even though there probably weren’t as extreme as with chromium). Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Doubts on license headers and correct people to add for a change in qtdeclarative
On Friday 06 February 2015 23:48:59 Lisandro Damián Nicanor Pérez Meyer wrote: - What's the custom with respect to copyright headers? I've added a simple test and normally all of them have a license header on them. Should I add one? Should I list myself? All files need licence headers and they should list the major contributors. If you're adding 10 lines or more of non-trivial contribution to an existing file, feel free to add your own name there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Doubts on license headers and correct people to add for a change in qtdeclarative
Hi! I've pushed a change to qtdeclarative [0] and I have two doubts: - Who exactly should I add to review it? git blames Lars in lots of places but I'm not really sure. - What's the custom with respect to copyright headers? I've added a simple test and normally all of them have a license header on them. Should I add one? Should I list myself? [0] https://codereview.qt-project.org/#/c/105650/ Thanks in advance, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
On 06 Feb 2015, at 09:32, Ziller Eike eike.zil...@theqtcompany.com wrote: 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 ;) ) Another alternative in the “documentation browser” space is to develop a Qt backend for a project like litehtml. Morten litehtml: https://github.com/litehtml/litehtml ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 4.8.7 snapshot build is available
Hi, there are some Mac framework fixes backported from Qt5 still waiting for approval in 4.8: WIP: Fix framework bundle hierarchy https://codereview.qt-project.org/#/c/95572/ WIP: Don't make Info.plist for debug framework bundles https://codereview.qt-project.org/#/c/95573/ Info.plist.lib whitespace fixup https://codereview.qt-project.org/#/c/95574/ WIP: Add CFBundleVersion to the Info.plist files. https://codereview.qt-project.org/#/c/95575/ Fix framework bundle deployment https://codereview.qt-project.org/#/c/95576/ Any chance to get those in 4.8.7? codesigning and verification of a Qt4 application build against Qt with those patches applied works fine. Regards Nils On Fri, Feb 6, 2015 at 10:01 AM, Nils Jeisecke jeise...@saltation.de wrote: Sorry for accidentally posting this obviously unfinished mail. Nils On Fri, Feb 6, 2015 at 9:59 AM, Nils Jeisecke jeise...@saltation.de wrote: Hi, WIP: Fix framework bundle hierarchy https://codereview.qt-project.org/#/c/95572/ -- Dipl. Inform. Nils Jeisecke fon: +49 (0) 521 - 329647-12 fax: +49 (0) 521 - 329647-40 email: jeise...@saltation.de --- saltation GmbH Co. KG | Niederwall 43 | 33602 Bielefeld Sitz Bielefeld | Amtsgericht Bielefeld HRA 15344 Persönlich haftende Gesellschafterin: saltation Beteiligungs-GmbH | Niederwall 43 | 33602 Bielefeld Sitz Bielefeld | Amtsgericht Bielefeld HRB 39339 Geschäftsführer: Daniel Brün --- ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
I consider a fully functional web engine component a very important piece of Qt. Easily embedding a website into a desktop application is extremely useful. Example applications are scrapers and website analysis tools. But there are a LOT more applications. Also more common ones. If the choice is dropping the web engine component or dropping old compilers I wouldn't need to think a second about the decision. -- Kind Regards Bernhard Lindner -Ursprüngliche Nachricht- Von: development-bounces+private=bernhard-lindner...@qt-project.org [mailto:development-bounces+private=bernhard-lindner.de@qt- project.org] Im Auftrag von André Somers Gesendet: Freitag, 6. Februar 2015 08:43 An: development@qt-project.org Betreff: Re: [Development] Deprecating modules with 5.5 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. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 4.8.7 snapshot build is available
Hi, WIP: Fix framework bundle hierarchy https://codereview.qt-project.org/#/c/95572/ On Fri, Jan 30, 2015 at 2:14 PM, Mark Gaiser mark...@gmail.com wrote: On Wed, Jan 14, 2015 at 12:34 PM, Salovaara Akseli akseli.salova...@theqtcompany.com wrote: Hi, 4.8.7-snapshot-2015-01-12-2-all-changes file uploaded next to installers ( http://download.qt.io/snapshots/qt/4.8/4.8.7/2015-01-12-2/4.8.7-snapshot-2015-01-12-2-all-changes ) to substitute actual change log file inside packages. 4.8.7-snapshot-2015-01-12-2-changes file published yesterday describes delta to previous snapshot. Similar changes files will be uploaded for the next snapshots. Change log file inside packages will be updated closer to actual release. Br, Akseli -Original Message- From: development-bounces+akseli.salovaara=theqtcompany.com@qt- project.org [mailto:development- bounces+akseli.salovaara=theqtcompany@qt-project.org] On Behalf Of Calogero Mauceri Sent: 13. tammikuuta 2015 17:09 To: development@qt-project.org Subject: Re: [Development] New Qt 4.8.7 snapshot build is available Hi, would it be possible to have a full changelog for this snapshot. The changelog file inside the pachage is empty. Thanks, Calogero Il 1/13/2015 4:04 PM, Salovaara Akseli ha scritto: Hi, New Qt 4.8.7 snapshot build is available http://download.qt.io/snapshots/qt/4.8/4.8.7/2015-01-12-2/ Snapshot is built against 50223ce5eebfdff01a88474f0589259137997458 Introduce Windows version 10. Changes compared to previous build: 50223ce5eebfdff01a88474f0589259137997458 Introduce Windows version 10. 6f55f3dbbb2cdae33a8b0d00b7bf2ada7fe79a04 Fix empty arrays in QML 1 18c5ff04103eadcb532d03d526714385943295ab Windows: Fix OS version determination for Windows = 8 8d831f5f444802879ae416bd110184d5a6cf1b26 QDateTime: Fix time format in doc 48194c74d3e2d2316fa4c57cf8b2e6687d8d6416 Fix compilation with QDND_DEBUG. 6f83ee60cf616731fb37d7a4357fc264fc167b2e Add Hebrew translation for Qt Linguist 25d972e12eda9dadf212d24af8d8f524572bdbfa Check world matrix is true when seeing if transformations are supported 62323e8d1b16167662c85e412d35804418593cc6 QIdentityProxyModel: remove slow bounds-checking, for more performance 87b82fb345a3384243da50240dab93589d072d7e Autotest: Setting tst_qaudiooutput and tst_qsound as insignificant Please test these snapshots, report possible regressions to bugreports.qt.io and send email about that (with bug id) to releas...@qt-project.org. Br, Akseli -- Akseli Salovaara The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Hi, I've just hit this bug: https://bugreports.qt.io/browse/QTBUG-13776 in Qt 4.8.x which is fixed in 5.0 via this patch: https://codereview.qt-project.org/#/c/41984/ Could that patch be backported to 4.8.7? My work environment requires 4.8.x. I've hit this issue when porting the work project from vcxproj to pro files (which would then be used to generate vcxproj files). The generated vcxproj files work just fine, but manually running nmake debug (or install) makes this issue pop up. Best regards, Mark ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Dipl. Inform. Nils Jeisecke fon: +49 (0) 521 - 329647-12 fax: +49 (0) 521 - 329647-40 email: jeise...@saltation.de --- saltation GmbH Co. KG | Niederwall 43 | 33602 Bielefeld Sitz Bielefeld | Amtsgericht Bielefeld HRA 15344 Persönlich haftende Gesellschafterin: saltation Beteiligungs-GmbH | Niederwall 43 | 33602 Bielefeld Sitz Bielefeld | Amtsgericht Bielefeld HRB 39339 Geschäftsführer: Daniel Brün --- ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
It is just not practical to ship a second copy of dozens of system libraries, all built as part of QtWebEngine. This is a nightmare in terms of disk space, RAM use, potential for symbol conflicts and delivery of security updates. These are all valid concerns but ultimately of secondary importance to most app developers who care most about delivering working software to their end users and for them the OS X / Windows model of bundling anything not guaranteed to be part of the base platform works quite nicely. We ship a complete copy of Qt in our non-open source app for Linux and a runtime wrapper that will choose on the fly whether to use it or not. Because of that we are able to offer a _better_ experience for our users than packaged open source software, which sucks. I'm not super enthused about shipping what is effectively a big chunk of an operating system as part of an app, but I can't disagree with Lars' comments about the effort required to maintain a modern browser engine. On 5 February 2015 at 16:08, Kevin Kofler kevin.kof...@chello.at wrote: Knoll Lars wrote: Yes, and I am sure, they have huge issues keeping up with the development of competing web technologies. I’ve been there and done that with first KHTML, then Qt WebKit for many years. The fact is that HTML5 these days is a huge pig, and supporting all of it using WebKit and supporting 10 different platforms is simply not possible with a team that’s smaller than ~50 people. We have tried for many years. The thing is, if you want to deliver something that is suitable for distributions (which the current QtWebEngine is NOT!), you will need to fork Chromium, because upstream does not care about the issues. Distributions such as Debian support many architectures. The Debian maintainers I've been in contact with over IRC were really unhappy to learn that QtWebEngine depends on V8. (They had not realized the implications of the announcement that it would use Chromium.) A JIT-only JavaScript engine, and browser code hardcoded to use only that engine (they removed the JS engine abstraction layer from WebKit and hardcoded V8 all over the place!) is horrible for portability. In Fedora, our primary architectures happen to be the ones V8 is targeting, but we do have secondary architectures on which we do not want to desupport large parts of Qt (such as Qt Assistant) and KDE. The bundling thing also really MUST be resolved. (At least the bundling of the many system libraries by Chromium. If you communicate that you have to bundle Chromium because you have to fork it to remove all the other bundled libraries, that will likely be a convincing enough argument to justify bundling Chromium.) It is just not practical to ship a second copy of dozens of system libraries, all built as part of QtWebEngine. This is a nightmare in terms of disk space, RAM use, potential for symbol conflicts and delivery of security updates. We distributions also very much want the web browser to use our shared multimedia stack, i.e. GStreamer. Then, the advantages of going with Chromium quickly start to vanish. IMHO, QtWebEngine is the one that should be deprecated. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] MacosX/iOS SecureTransport SSL Backend Call for Testers
The secure transport backend for Qt's SSL support was merged earlier this week [1] thanks to some great work by Jeremy Laine and Timur Pocheptsov. Please could those using Macos X and iOS give it a try and see how it works for them? Cheers Rich. 1. https://codereview.qt-project.org/#/c/101485/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 4.8.7 snapshot build is available
Sorry for accidentally posting this obviously unfinished mail. Nils On Fri, Feb 6, 2015 at 9:59 AM, Nils Jeisecke jeise...@saltation.de wrote: Hi, WIP: Fix framework bundle hierarchy https://codereview.qt-project.org/#/c/95572/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] MacosX/iOS SecureTransport SSL Backend Call for Testers
Actually, we have to fix configuration on OS X: Secure Transport is enabled with -no-openssl (-securetransport is not required) and this can be undesired side effect From: development-bounces+timur.pocheptsov=theqtcompany@qt-project.org development-bounces+timur.pocheptsov=theqtcompany@qt-project.org on behalf of Jeremy Lainé jeremy.la...@m4x.org Sent: Friday, February 6, 2015 4:43 PM To: development@qt-project.org Subject: Re: [Development] MacosX/iOS SecureTransport SSL Backend Call for Testers On 02/06/2015 03:17 PM, Richard Moore wrote: The secure transport backend for Qt's SSL support was merged earlier this week [1] thanks to some great work by Jeremy Laine and Timur Pocheptsov. Please could those using Macos X and iOS give it a try and see how it works for them? Some practical notes: - on iOS this backend is enabled by default - on OS X you can enable it like this: ./configure -no-openssl -securetransport Cheers, Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Deprecating BlackBerry Playbook support
Hello, Unless anyone is willing to help, I would like to propose deprecating and consequently removing BlackBerry Playbook code from Qt sources. This would mainly affect the QNX plugin. Reasons: - the Playbook NDK is old and its compiler does not keep up with newest C++11 improvements inside Qt Code. - the Playbook NDK diverges considerably from the standard BB10 NDK, making it non-trivial to keep a common codebase. - It's a defunct platform. - Maintenance time is limited. If anyone objects, please raise your hands. Cheers, Rafael -- Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
On 2015-02-06 09:22, Robert Knight wrote: It is just not practical to ship a second copy of dozens of system libraries, all built as part of QtWebEngine. This is a nightmare in terms of disk space, RAM use, potential for symbol conflicts and delivery of security updates. These are all valid concerns but ultimately of secondary importance to most app developers who care most about delivering working software to their end users and for them the OS X / Windows model of bundling anything not guaranteed to be part of the base platform works quite nicely. We ship a complete copy of Qt in our non-open source app for Linux and a runtime wrapper that will choose on the fly whether to use it or not. Because of that we are able to offer a _better_ experience for our users than packaged open source software, which sucks. ...and you're keeping up to date with all the security patches to Qt, Chromium, etc.? If not, your better experience is leaving your application's users vulnerable. Bad enough for individual applications to shoulder that burden. When you talk about the cost of maintaining a web engine, don't forget that by bundling Chromium, *you* (i.e. the Qt project) are taking on responsibility for the security of that entire stack. This means releasing a new version *of Qt* whenever a security issue is found in Chromium. Or in anything that Chromium bundles. Putting myself in the library/framework developer role, I would strongly want to punt that burden to upstream / the distro. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
