QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

http://lists.qt-project.org/pipermai...ne/021979.html

The jump to QT5.2 was supposed to have been traumatic for the Sailfish team, with no sign of planning for a new rebasing of QT appearing since.

Presumably, they'll have to move eventually, so would an LTS release in Dec15 be the time to [start] that process?

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Can someone explain what's the Problem with updating a minor release of Qt on Jolla? Do the Sailfish OS Silica components only work with a specific Qt 5.x version? Isn't Qt 5.x supposed to be backward compatible with previous 5.x versions?

So I wonder why Ubuntu Phone already uses Qt 5.4 and Jolla found it difficult to update from 5.1 to 5.2 last year. Or was there any new Qt update within the last 2-3 OS updates in the meantime I missed?

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

I thought I read that the problem with the move to 5.2 wasn't so much about incompatibility with the version they were on before, but with the immaturity of the target version at the time, meaning they had to do a lot of working around bugs and performance/memory issues. You'd think an LTS would be an easier target in that regard.

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

And Ubuntu doesn't care so much about performance and memory issues, as long as they can run the latest and greatest version. ;)

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

The move from 5.1 to 5.2 was a big move. Large changes in the renderer, a totally new JavaScript engine, and a lot of other usual changes.

It took a team of people (let's say, ~2-4 people) some months (let's say six) of work before it was ready for the rest of the company to take a look at it, and unfortunately some rough seas elsewhere in the company meant that it took even longer after that to mature properly (another 3-4 months).

In my opinion, the move to subsequent versions is less drastic, although there is still a (constant) influx of bugs and performance regressions to fight against -- and this together with the tablet development means that there likely isn't going to be a lot of priority to this type of work unless it brings substantial benefits in another area, much as I'd like to see it happen.

When it does happen, I imagine that it is likely to happen a lot more piece-by-piece: QtMultimedia is already being upgraded in a future release because it's needed for some other bits and pieces, for instance.

And to answer the initial question: an LTS release is a very good thing from Sailfish's perspective. It means there's a reasonably solid base that can be focused on (and collaborated on with other people), rather than a constant train of moving targets where Sailfish would either be on the bleeding edge or constantly far behind.

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

And the fact that they're basing Ubuntu Phone versions on the desktop version (aligning). So if the desktop version has Qt 5.4, then the Phone version will have 5.4 as well. Jolla only has the phone (and the tablet WIP).

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Thanks, w00t.

Would you imagine that Sailfish might make use of the some the newly stabilised features in Qt?
QT3D is one example, i'm sure there are others too.

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Never say never, but I don't see e.g. the immediate switch to a 3D interface coming one release after the initial introduction of the 3D library, for instance :)

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Qt 5.5 just got released:

http://blog.qt.io/blog/2015/07/01/qt-5-5-released/

I still don't understand why I can use the latest Qt version with (Desktop) Linux, Windows (Phone), Mac, Android and even on Raspberry Pi but not on Jolla?

Hope that SFOS 2.0 has some more recent update.

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

I assume because the Jolla it limited by its hardware and it has to be ensured that Qt 5.5 won't bring any determinal performance issues, since on PCs its not as much of an issue, and Android Qt isnt the primary toolkit, while for Jolla the UX is built on Qt, also what APIs does it bring that you want?

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

I think I already covered this a few posts above you. It's not a trivial effort like you seem to assume it is, and the effort going onto that is effort that isn't spent elsewhere (other useful bugfixes/features, tablet work, etc)

It doesn't. You can watch the activity yourself on http://github.com/mer-qt/.

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

When you say you can "use" the latest Qt with all these operating systems, I believe what you mean is that you can run programs written using Qt on those systems. Other than desktop Linux, none of those OSs actually use Qt internally for anything (and only some distributions of Linux use Qt).

I would guess that, if you really wanted to, you could build an executable on Qt 5.5 and run it on a Jolla; you simply wouldn't be able to take advantage of Sailfish's GUI. You'd need to include your own UI graphics libraries into your app, much the way Qt works on Android. (Gah, I really, really hate the way Qt works on Android; I've been pulling my hair out trying to create a UI for my apps that looks at all reasonable. Creating a reasonable UI using Sailfish is so much easier...)

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

You can! All you need is somebody who'll package a new version of Qt for SFOS, which should be installed "beside" SFOS main Qt version. (Windows phone & Android doesn't provide Qt themselves, so there is no reason that we expect Jolla to provide this).

Being able to install latest Qt version on Jolla is completely different from the Qt version used by SFOS.

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

True, but isn't actually the point of newer Qt point releases also to bring performance improvements and lot's of bug fixes?
Don't you see the irony that a device what is build on the premise of Qt lags the newest improvements of the toolkit compared to all other platforms?

I think it would be really great to have an updated Qt WebKit or even the new Qt WebEngine module. All apps rendering web content including 3rd party web browsers would greatly benefit from it. Also Jolla could switch finally to GStreamer 1.x with Qt Multimedia. Besides this the SFOS SDK could use a newer version of Qt Creator for development.

Qt 5.2 still used in the latest SFOS came out the same time as the Jolla phone in December 2013. Don't you think it's time for an update at least for SFOS 2?

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

I never assumed that's a trivial effort.

But keeping a fork of a specific version longer gets more expensive over time. If the 5.1->.2 update was already that painful I wonder how difficult a higher update will be?

Ok, I see it's still based on the Qt 5.2.x migration work last year.

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Actually, that's a pretty good question. Many organizations do maintain the policy of limiting "minor" releases to just performance and fixing bugs, but this doesn't apply to everybody. Certainly, Qt has added and removed features whenever they wanted; heck, QML itself was introduced in Qt 4.7.

In short, the numeric value of a Qt release isn't a good indicator of just how much Qt has changed in that release.

The fundamental premise of Qt is ease of cross-platform app creation. I don't see how that should make updating an operating system any easier...

Moreover, Jolla is selling itself on having a superior mobile device user experience on top of a (mostly) open operating system. This really has nothing to do with what version of Qt they use; their selling point could still stand, even if they moved away from Qt altogether.

The way Qt has messed around with their web client software is far, far more than just a simple performance enhancement, and requires at least a little amount of effort to properly adjust to. Similarly, GStreamer 1.x has some interesting differences over 0.10. And I don't see any significant value in having the latest version of Qt Creator; I'm currently using Qt Creator 2.4.1 (SDK 4.7) for Maemo work, Qt Creator 3.1.2 (SDK 5.2) for Sailfish work, and Qt Creator 3.3.0 (SDK 5.4) for Android work. They're all pretty much identical in terms of how they work, other than that they all support some radically different Qt features.

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

The general process the Jolla guys work with is to get their changes upstreamed to the latest Qt and then back-port them to Qt5.2 for use on the Jolla. This is initially more work but it means that the two branches are converging not diverging.

GStreamer 1.0 is a prime example of this, its currently in testing for the next release (fingers crossed)

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Yes, but fragmentation goes against cross-platform.
We are starting to see the same problems with Qt, than with other eco-systems (like Android) : the more different Qt versions there are in the field, the more difficult it gets to make cross-platform things, except if using only the lowest common denominator.

Someone who starts to write an application today, will use Qt5.5 on desktop, but would not be able to directly use canvas3D/qt3D/QtLocation/Bluetooth4LE on Ubuntu touch, and a lot less in Qt5.2 on Jolla.

That is what is bad in this situation. On the other hand, not spending all their time to try to follow closely each release of Qt is legit.

About fragmentation, Silica also doesn't help as it can't run on anything else than Sailfish itself. But it looks great ;)

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

The general behavior has been kept the same, but it is getting a lot more efficient when using refactoring tools in the last versions. Kits and devices has also seen a major overhaul since 2.4.
And QtCreator is not tied to a specific version of the Qt toolchain, it is only an IDE. I always use the last QtCreator version for all my toolchains (Qt4.x and Qt5.x), I even develop with it for embedded devices with no OS and no Qt.
So Jolla can update their SDK without changing the Qt version running on their OS, if they'd see the need.

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

You're telling me! ;) I've given up on trying to create a single unified UI for my own apps, which is why I've got a different version of the Qt SDK up and running for each of the devices I'm targeting.

However, I have to admit that the non-GUI parts of Qt really do work as advertised. I was able to get the back-end of my Pierogi app up and running on Android in just a couple of days, and was using it to control TVs and other devices. I just recently threw Linguine at Qt on Android, and was quickly pulling down podcasts with it as well. It's just that I can't possibly use the same Qt GUI for both Maemo and Android. :(

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Really?! So, for example, you could plug the Maemo toolchain into the Qt 5 SDK, and it would be able to build Maemo apps? (If so, it'd be nice to try and re-package the Maemo and Meego toolchains back into the Qt SDK...)

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Can't tell for sure for Maemo which I never used. 3 months ago, I was cross compiling apps for Qt4.7 embedded on PowerPC with the same version of QtCreator I was using at home for Qt5.4 desktop. So it is quite flexible.
I don't use anymore Qt4.x toolchains, but don't see why it wouldn't still be supported (Creator only launches qmake/make, which stays the same for all versions).

In the end, I also use it a lot with embedded devices (DsPIC, STM32, SAM7, ...), and calling their compilers/flasher tools, from inside QtCreator. It is less polished than when doing pure Qt thing, but QtCreator is lights years ahead of MplabX or IAR IDEs, so it is good...

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Its simple, updates can bring regressions and rather than simply thinking YOLO lets just roll it out and see what happens since Qt is the heart of our system seems like a pretty stupid move.

Also I already explained that the Jolla is limited hardware wise so workarounds and optimizations maybe needed to make Qt viable.

The irony is I thought Qt would be faster in general than Androids apps, yet I look at the Jolla browser and wonder.

I would indeed enjoy the new WebEngine. But the company has around 100 people and I assume there not all coders lol. I wonder if we could just update it manually.

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Wow. Really? Google has invested an unbelievable amount of time and money into their browser (Chrome) to make it competitive with both IE and Firefox. Qt, on the other hand, has essentially no in-house web expertise. Web browsing is absolutely the last place I would expect a Qt-based system to be better than Android...

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

That's why they use the expertise of Google and the open source community and switched from QtWebKit to QtWebEngine based on Chromium and the Blink rendering engine.

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Exactly! Gotta hope that they don't have to keep switching between backends all the time. :) But yeah, it takes some effort to migrate code from WebKit to WebEngine; here's a wiki from Qt on the subject:

https://wiki.qt.io/Porting_from_QtWebKit_to_QtWebEngine

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

What about Universal Components ? It of course would not look like Silica on other platforms but makes it possible to have a single UI codebase. :)

A nice example of UC usage is modRana, which has the same UI codebase for Sailfish OS (Silica backend), desktop Linux and Android (both use the QtQuick Controls backend).

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

You're right, but the "price" is paid at two different points. Waiting to upgrade means that the pain for that upgrade is delayed until someone decides to pay it (aside from the fairly insignificant cost of having to backport things that are required). It can grow so long as it isn't paid (like interest on a mortgage, say) but it's "tomorrow's problem".

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Browsers are a hard thing to compare because you're really not comparing application frameworks, you're comparing engines. In the case of the Jolla browser, you're comparing a small Qt-based UI shim plus the Gecko rendering engine doing all of the work — a massively complicated, large codebase, against whatever else you're using.

Having used WebEngine in non-Jolla projects, I'm happy with it. It's a very nice tool, and I'd be very interested to see it in an experimental browser.

I'm not completely sure it would be able to replace the built in browser overnight, though: I don't have numbers, but WebEngine was quite resource-hungry.

You would be able to (independently from Sailfish) build your own copy of a newer Qt (including WebEngine) and use that to build your own application. I'm fairly sure that Silica's UI components wouldn't work though, as last time I looked, they had dependencies on internal APIs inside Qt (which have no backwards-compatibility promise, meaning they break from one release to another).

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

with a QT5.6 LTS coming in December I cannot see Jolla porting Sailfish to any other version such as 5.3 / 5.4 / 5.5 in the interim.

that said, i would not expect to see such a change made quickly, so perhaps we might see Sailfish 3.0 based on QT5.6 in December 2016...

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

I think there's a problem with performance in Sailfish generally, it's not browser specific, and shouldn't be Qt specific. Per the browser performance testing I did on the Jolla & Nexus5, FireFox running inside Alien Dalvik VM on the Jolla is faster than any browser on the Nexus5 running Sailfish (SD800 is miles faster than SD400 in Jolla), let alone SF on the Jolla. This shouldn't happen. I tested UP performance on the Nexus5 too ... it also uses Qt, QML and libhybris for hardware adaption. If there are inherent issues with them, then they'd suffer too. However, Octanev2 results for Ubuntu Phone's default browser are faster even than any browser running in a fast, lightweight AOSP based Android ROM on the same phone (vastly faster already than Nexus5 w/ SF). So there shouldn't really be a reason why Sailfish is so slow, if UP can do it. It looks like SF has a hard time loading the CPU properly. Maybe task scheduling is broken or poor? Did the testing in April, nothing has changed with 1.1.7 as I tried it last night; was hoping that as 1.1.7 supposedly carries a lot of the technical underpinnings for v2.0, they might have done something. I'm sure Jolla have been aware of it forever, and I did pass the results on... but they've never acknowledged the issue or added potential improvements to the new roadmap - mainly I suspect because it differs from the narrative that SF is fast, efficient and lightweight (something that couldn't be further from the truth ATM with RAM hunger and poor performance) ... or maybe they don't know how to fix it / what the cause is.

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Er, but why not? Mozilla is a group founded long ago to build a web browser, and up to this day still centered around their web browser. I would expect their code to be quite performant...

If I've got this right, UP is using "oxide" for their web engine, and oxide is based on chromium. Therefore, UP is using Google's engine for its web layout; which, again, should provide a superior browsing experience.

And, again, this is also what Qt themselves have recently done -- pretty much given up on their existing webkit engine, and gone with Chromium. If/when Jolla migrates to the more recent versions of Qt, their browser should hopefully better match Ubuntu Phone and other chromium-based systems...

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

You're really clutching at straws here.

Sailfish Browser is based on Gecko? Please insert your new excuse here.

If Webkit on Qt has been so abandoned and is so poor, and Gecko so great (though not as fast as Chromium), then why are the (deprecated) versions of Qt Webkit used in WebPirate & WebCat still (much) faster than the (much newer Gecko build) Sailfish Browser?

Also, UP's browser gets better results in OctaneV2 than either Chrome or Opera (Chrome based) in lightweight AOSP Android builds on the same (Nexus 5) phone ... and the UP port for N5 is a community Alpha (like the SF N5 port).

Anyway, anything that significantly loads the CPU in Sailfish tends to cause the app to hang, freeze or badly slow down long before 100% CPU utilisation is reached ... this shouldn't happen.

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Really, all I'm trying to say is that the current Sailfish browser code probably isn't as good as its competitors. Which, I think, is what you are saying as well. My only addition is that I believe that Jolla is not focussed (and should not be focussed) on trying to create the fastest possible browser; that's a job better left in someone else's hands. I want them to concentrate on the underlying OS, and on growing their business. A good browser is important to a good mobile device experience, but someone else can create that app; Jolla doesn't have to do it themselves...

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Just because code stops being worked on doesn't mean it immediately "rusts" like metal would. It'll still compile and work the same way it did the last time (unless something changed underneath it).

In addition, there's a few more important things to keep in mind there:

• The number of people working full time on QtWebkit (when it was "alive") was something like 5-6x the number of people working on the Sailfish browser full time.
• QtWebkit has a much longer history than the Sailfish browser: it was released initially alongside Qt 4.4, in 2008. The Sailfish browser UI was initially started on in February 2013[1], later released at the end of the year with the Jolla phone. The Gecko work it uses dates back quite a long time, but has changed UI architecture a number of times, so it is also quite new on the side of platform ports.
• QtWebkit also shipped in a multitude of finished "products" (the N9 being the most prominent talked-about example here, but I've worked on a few others, and heard of a lot more in addition) over those years, compared to Sailfish's grand total of one (so far).

[1]: https://github.com/sailfishos/sailfi...8cd9e22fc47e98

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Fun factoid for historians who didn't bother to look it up themselves: the initial skeleton of the browser used QtWebkit :-)

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Amen!

I have always considered default applications bundled in the OS a proof of concept and a free bonus (or burden, depending on whether they can be easily removed - and that includes them staying removed after an OS update, nudge nudge wink wink).

The OS developer's effort is best placed in developing the OS. It is the application developers whose job it is to make bigger, better, faster, more featured applications, including browers.

Of course, the OS needs to attract those application developers first. Therein lies the biggest challenge ;)

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

http://blog.qt.io/blog/2015/12/18/in...-term-support/

Seems to be too late for Jolla or maybe not?

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Too late in what way? This just seems to make Qt 5.6 even more appealing as the next target, as it will remain both stable and supported for quite some time to come...

Re: QT5.6 (Dec15) to be Long Term Support - implications for Sailfish?
 

Jolla could have done with that a year ago. Does this mean that finally there's a possibility of a decent range of permitted libs in the harbour?