Active Topics
-
The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 3 days, 15 hrs ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 4 days, 11 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 6 days, 20 hrs ago - more...
|
2009-12-28
, 18:12
|
|
Posts: 10 |
Thanked: 8 times |
Joined on Dec 2009
@ Tampere, Finland
|
#42
|
Originally Posted by voracity
because webkit is integrated into qt, and WRT is actually based on qt. therefore, qtwebkit is preferred
That's not to say I don't have my concerns. I am quite disappointed to see that WRT will use webkit rather than gecko (on philosophical grounds). So, out of curiosity, why was webkit chosen?
|
|
2009-12-28
, 18:30
|
|
Posts: 10 |
Thanked: 8 times |
Joined on Dec 2009
@ Tampere, Finland
|
#43
|
Originally Posted by go1dfish
yes, you can
Ok here's some others then:
Will it be possible to embed the Web Runtime in a 'normal' C/C++/Python based Qt application on Maemo, similar to the way you would embed a QWebView?
| The Following User Says Thank You to xizzhu For This Useful Post: | ||
 |
|
2009-12-28
, 21:02
|
|
Posts: 3,105 |
Thanked: 11,088 times |
Joined on Jul 2007
@ Mountain View (CA, USA)
|
#44
|
The concern about power management is relative and needs to be put also in its context. Even if in principle a well written native application will be more power efficient than a web runtime application, in practice the user might get no negative impact if the application is useful for simple actions.
For instance, I miss an application telling me where to go to take the quickest public transport to reach my home, based on my location and know timetables.
Imagine a developer goes ahead with a Web Runtime app because it's actually easy to program. I don't need to have a permanent widget polling data to tell me the nearest / fastest ways to reach my home. It happens perhaps once a week that I'm in such situations and I would just need one minute of use time of such app for being useful.
I also see the Web Runtime as a good development path for mobile developers. It's a good entry point for regular web developers giving a try to some basic ideas e.g. optimized clients of web services. Once they start in mobile development they get into more complex ideas, perhaps they hit some limitations in terms of APIs or performance and they start being interesed and learning in more native-ish programming. Qt offers an interesting transition path between pure Web Runtime and pure native Qt.
For instance, I miss an application telling me where to go to take the quickest public transport to reach my home, based on my location and know timetables.
Imagine a developer goes ahead with a Web Runtime app because it's actually easy to program. I don't need to have a permanent widget polling data to tell me the nearest / fastest ways to reach my home. It happens perhaps once a week that I'm in such situations and I would just need one minute of use time of such app for being useful.
I also see the Web Runtime as a good development path for mobile developers. It's a good entry point for regular web developers giving a try to some basic ideas e.g. optimized clients of web services. Once they start in mobile development they get into more complex ideas, perhaps they hit some limitations in terms of APIs or performance and they start being interesed and learning in more native-ish programming. Qt offers an interesting transition path between pure Web Runtime and pure native Qt.
|
|
2009-12-29
, 02:36
|
|
Posts: 25 |
Thanked: 22 times |
Joined on Dec 2009
|
#45
|
Originally Posted by Flandry
I did indeed read your arguments. I came to this thread after reading this one in which you make several comments along those lines, such as this on Java (and, given the context, Javascript):
What? Paranoid i may be, but disingenuous i'm not (and i don't appreciate you claiming i am if you don't actually read my argument).
Originally Posted by Flandry
But I'll grant you that I guessed incorrectly and will take you at your word that battery life (or device resources in general) is your first concern, the quality of the software ecosystem is second and anything else ranks below those two.
Not having java supported in my mind avoids diluting the quality of available software by having cheap & dirty java versions of apps pop up that never work as well as the alternatives would--alternatives that either won't get made or won't get refined because the nasty java version is "good enough".
In which case, I think you have little to worry about. For many applications, interpreter overhead really can be ignored --- for example, updating a weather or stock widget or any other kind of status widget; simple user interfaces for things like media players; small-scale file and email management; system maintenance tools; instant messaging; dictionaries; etc. Yes, they can be coded poorly, but so too can native apps. (And some of the core apps on the N900 have already proved this! --- though I should note, I'm still waiting on my N900 to arrive.)
For other applications (particularly games, but also many other apps) concerns about the interpreter's performance will swamp any concerns about battery life, so people will be forced to write natively (or, more likely, not at all).
But instead of batting fuzzy opinions back and forth, you can partly test this out for yourself. Find applications that have been implemented as both a web application and native application (to an equal standard, of course), run them both on your N900 for a long period, and compare the effect on battery life. Even better would be to cut some code yourself, so that you can guarantee the applications are as similar as possible. My guess is that those cases in which the web application depletes the battery faster will also have woeful performance in comparison to the native app.
Originally Posted by Flandry
Are you saying that device sales and satisfied users are completely unrelated to the number of repo apps available? I actually hope you're right (but I have very different motivations).
Furthermore, i don't believe the demographic you claim to represent is significant enough to matter if the WRT absorbs resources (whether developmental or on the device itself) that prevent the next maemo device from being less svelte and having a longer battery life (as described in my earlier post), which would exclude the much, much larger demographic that buys iPhones but doesn't want to develop in any way.
Simplified venn diagram of the point:
(((System Language Developers) WRT developers) smartphone users)
where # smartphone users >>> all developers
Pappy taught me there's no such thing as a free lunch. My preference is for efficiency over having WRT, and i think that's also most important for Maemo's growth (by the metric of device sales and satisfied users, not # apps in repo).
Your Venn diagram also suggests that anything WRT developers can do, native developers can do too, which I doubt very much. More than that, you seem to be suggesting that any useful thing WRT developers would do, a native developer will do (so long as WRT developers don't exist), which is clearly false.
|
|
2009-12-29
, 02:47
|
|
Posts: 25 |
Thanked: 22 times |
Joined on Dec 2009
|
#46
|
Originally Posted by xizzhu
Thanks, I thought something like that might be the case, but in what ways do QtWebKit and Qt interact? Does QtWebKit already have web developer-facing bindings to Qt APIs, or is it just easy to embed in Qt apps? (I would have thought Gecko would be easy to embed, too, though.)
because webkit is integrated into qt, and WRT is actually based on qt. therefore, qtwebkit is preferred
I assume another reason is for consistency with WRT on S60 and to cut down on code duplication. Understandable, but still disappointing.
|
|
2009-12-29
, 07:19
|
|
Posts: 10 |
Thanked: 8 times |
Joined on Dec 2009
@ Tampere, Finland
|
#47
|
Originally Posted by voracity
QtWebkit is already part of Qt, so no extra effort is needed to use webkit by WRT
Thanks, I thought something like that might be the case, but in what ways do QtWebKit and Qt interact? Does QtWebKit already have web developer-facing bindings to Qt APIs, or is it just easy to embed in Qt apps? (I would have thought Gecko would be easy to embed, too, though.)
I assume another reason is for consistency with WRT on S60 and to cut down on code duplication. Understandable, but still disappointing.
if I understand your question correctly
|
|
2009-12-29
, 11:16
|
|
Posts: 7 |
Thanked: 0 times |
Joined on Nov 2009
|
#48
|
I have scanned through this thread quickly so apologies if I have missed something, but how does Qt's QML fit into this picture?
When QML was released, I assumed it would become Nokia's "recommended" approach for developing cross-platform apps.
Paul Drummond
When QML was released, I assumed it would become Nokia's "recommended" approach for developing cross-platform apps.
Paul Drummond
|
|
2009-12-29
, 12:50
|
|
Posts: 25 |
Thanked: 22 times |
Joined on Dec 2009
|
#49
|
Originally Posted by xizzhu
Partly, thanks. I should probably read up a bit more on the WRT internals at some point, but I'm expecting that there will be some kind of javascript API to access Qt- or device-specific functions. I was wondering if that's already in QtWebKit in some way ... OK, did a bit of reading and that does seem to be the case (it's called Platform Services). You'd just use something like this bit of javascript:
QtWebkit is already part of Qt, so no extra effort is needed to use webkit by WRT
if I understand your question correctly
Code:
var so = device.getServiceObject("Service.Calendar", "IDataSource");
Re: QML. Hmmm. I really do hope this kind of stuff gets standardised, otherwise none of it will last... And why isn't this kind of thing being done under the auspices of HTML5?
|
|
2009-12-29
, 13:18
|
|
Posts: 10 |
Thanked: 8 times |
Joined on Dec 2009
@ Tampere, Finland
|
#50
|
Originally Posted by voracity
Qt provides the possibility to create hybrid application, you can take a look at e.g. http://qt.nokia.com/forms/whitepaper...tepaper-hybrid
Partly, thanks. I should probably read up a bit more on the WRT internals at some point, but I'm expecting that there will be some kind of javascript API to access Qt- or device-specific functions. I was wondering if that's already in QtWebKit in some way ... OK, did a bit of reading and that does seem to be the case (it's called Platform Services). You'd just use something like this bit of javascript:
WRT will provide some device-specific JS APIs, e.g. contact, calendar, etc. and yes, WRT has already provided such services.
To me, I think it's mainly due to the integration of Webkit into Qt
If it really will come "free", with no additional memory or processing requirements, unless a 3rd-party app is installed, it is truly optional and that's great. I obviously don't have to buy step 5, but i'd really really like to see it succeed and be something amazing, and that's the origin of my comments.
Furthermore, i don't believe the demographic you claim to represent is significant enough to matter if the WRT absorbs resources (whether developmental or on the device itself) that prevent the next maemo device from being more svelte and having a longer battery life (as described in my earlier post), which would exclude the much, much larger demographic that buys iPhones but doesn't want to develop in any way.
Simplified venn diagram of the point:
(((System Language Developers) WRT developers) smartphone users)
where # smartphone users >>> all developers
Pappy taught me there's no such thing as a free lunch. My preference is for efficiency over having WRT, and i think that's also most important for Maemo's growth (by the metric of device sales and satisfied users, not # apps in repo).
I feel comfortable that i've qualified that posititon. If people will stop taking one part of my statements out of context and instead answer the overall analysis or simply ignore me, i'd appreciate it. And i'll also shut up.
Unofficial PR1.3/Meego 1.1 FAQ
Accelemymote: make your accelerometer more joy-ful
Last edited by Flandry; 2009-12-29 at 16:42. Reason: Negated a double negative