Active Topics
-
Firefox with Leste (10)
to Maemo 7 / Leste by teroyk - 2 days, 22 hrs ago - more...
 |
Copernicus |
2015-07-02
, 23:10
|
|
Posts: 1,986 |
Thanked: 7,698 times |
Joined on Dec 2010
@ Dayton, Ohio
|
#21
|
Originally Posted by Zeta
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...)
|
|
2015-07-02
, 23:20
|
|
Posts: 339 |
Thanked: 1,623 times |
Joined on Oct 2013
@ France
|
#22
|
Originally Posted by Copernicus
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.
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...)
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...
| The Following 3 Users Say Thank You to Zeta For This Useful Post: | ||
|
|
2015-07-02
, 23:48
|
|
Posts: 1,746 |
Thanked: 1,832 times |
Joined on Dec 2010
|
#23
|
Originally Posted by mick3_de
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.
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?
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.
|
|
2015-07-03
, 00:03
|
|
Posts: 1,986 |
Thanked: 7,698 times |
Joined on Dec 2010
@ Dayton, Ohio
|
#24
|
Originally Posted by m4r0v3r
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...
The irony is I thought Qt would be faster in general than Androids apps, yet I look at the Jolla browser and wonder.
|
|
2015-07-03
, 07:11
|
|
Posts: 66 |
Thanked: 87 times |
Joined on Aug 2010
|
#25
|
Originally Posted by Copernicus
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.
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...
| The Following User Says Thank You to mick3_de For This Useful Post: | ||
|
|
2015-07-03
, 07:25
|
|
Posts: 1,986 |
Thanked: 7,698 times |
Joined on Dec 2010
@ Dayton, Ohio
|
#26
|
Originally Posted by mick3_de
Exactly! Gotta hope that they don't have to keep switching between backends all the time.
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.
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
| The Following User Says Thank You to Copernicus For This Useful Post: | ||
|
|
2015-07-03
, 07:38
|
|
Posts: 1,548 |
Thanked: 7,510 times |
Joined on Apr 2010
@ Czech Republic
|
#27
|
Originally Posted by Zeta
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.
About fragmentation, Silica also doesn't help as it can't run on anything else than Sailfish itself. But it looks great
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).
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
| The Following User Says Thank You to MartinK For This Useful Post: | ||
 |
|
2015-07-03
, 08:57
|
|
Posts: 1,055 |
Thanked: 4,107 times |
Joined on Oct 2009
@ Norway
|
#28
|
Originally Posted by mick3_de
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".
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?
__________________
i'm a Qt expert and former Jolla sailor (forever sailing, in spirit).
if you like, read more about me.
if you find me entertaining, or useful, thank me. if you don't, then tell me why.
i'm a Qt expert and former Jolla sailor (forever sailing, in spirit).
if you like, read more about me.
if you find me entertaining, or useful, thank me. if you don't, then tell me why.
|
|
2015-07-03
, 09:02
|
|
Posts: 1,055 |
Thanked: 4,107 times |
Joined on Oct 2009
@ Norway
|
#29
|
Originally Posted by m4r0v3r
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.
The irony is I thought Qt would be faster in general than Androids apps, yet I look at the Jolla browser and wonder.
Originally Posted by m4r0v3r
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 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.
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).
__________________
i'm a Qt expert and former Jolla sailor (forever sailing, in spirit).
if you like, read more about me.
if you find me entertaining, or useful, thank me. if you don't, then tell me why.
i'm a Qt expert and former Jolla sailor (forever sailing, in spirit).
if you like, read more about me.
if you find me entertaining, or useful, thank me. if you don't, then tell me why.
| The Following 4 Users Say Thank You to w00t For This Useful Post: | ||
|
|
2015-07-12
, 07:06
|
|
Posts: 735 |
Thanked: 1,054 times |
Joined on Jun 2010
|
#30
|
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...
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...