Nokia geeft nieuwe smartphones Qt-ondersteuning

Nokia gaat alle nieuwe smartphones voorzien van ondersteuning voor het cross-platformframework Qt. Door miljoenen smartphones met Qt uit te rusten, hoopt de fabrikant ontwikkelaars te interesseren om er software voor te maken.

Qt zal ook worden ondersteund door smartphones met de oude Symbian-versies S60v3 en S60v5, die Nokia op goedkope smartphones installeert. Omdat daar tientallen miljoenen exemplaren per kwartaal van verkocht worden, hoopt de Finse fabrikant snel een grote groep gebruikers met smartphones met Qt-ondersteuning te hebben. S60v3 is de Symbian-versie die onder meer op de N95 staat; S60v5 draait onder meer op de N97 en de 5800 XpressMusic.

Voor gebruikers die geen Qt op hun toestel hebben, heeft Nokia de Smart Installer gemaakt: die detecteert of Qt op een smartphone aanwezig is en downloadt indien nodig het installatiebestand van de Nokia-servers. Het Finse bedrijf heeft deze week de 1.0-versie van de Qt-sdk uitgebracht. Daarnaast heeft de mobieltjesmaker diverse maatregelen getroffen om ervoor te zorgen dat het ontwikkelen van applicaties sneller, goedkoper en makkelijker wordt: zo zijn de kosten voor het 'signen' van applicaties voor Symbian geschrapt en kost de goedkeuring nog maar hooguit twee weken. Ook kunnen particulieren zich vanaf deze week aanmelden als ontwikkelaar; het hebben van een bedrijf is geen vereiste meer.

Qt is een cross-platformframework waarmee ontwikkelaars applicaties kunnen schrijven die zonder veel aanpassingen op Maemo, MeeGo en alle Symbian-versies werken. Maemo is het op Linux gebaseerde OS dat op de N900 en diverse internettablets van Nokia draait; MeeGo is de opvolger daarvan, die samen met Intel wordt ontwikkeld.

Het ontwikkelen in Qt kan met verschillende programmeertalen, waaronder C++. Nokia-specialist Katrien de Meij zal volgende week, tijdens het door Nokia en Tweakers.net georganiseerde evenement rondom de N8 en Symbian^3, over de mogelijkheden van Qt voor ontwikkelaars spreken.

Reacties (55)

[musicer]

Dit platform ziet er veelbelovend uit. Het zou natuurlijk geweldig zijn als andere fabrikanten dit ook gaan gebruiken en ontwikkelaars dus niet voor elk willekeurig OS een applicatie uit hoeven te brengen, want dan kunnen ze die tijd besteden aan het maken van betere en meer applicaties en hoeven we niet zo lang op specifieke apps te wachten voor het platform.

Ik ben echter wel benieuwd naar de prestaties, omdat het niet aan elk platform is aangepast. Als het maar niet zoiets als java wordt, want dat is dan wel mooi voor veel platformen geschikt, tenminste op featurephones, maar wel ontzettend traag.

[Reactie gewijzigd door musicer op 27 juli 2024 05:32]

[Terracotta]

Qt is al behoorlijk volwassen en snel hoor, KDE heeft een hele desktop, netbook en phone omgeving gemaakt met plasma dat zwaar van qt gebruik maakt en het werkt echt wel goed in alle omgevingen.

[Verwijderd]

QT (cute) kan op veel meer platformen ingezet worden.

Qt is released by Nokia on the following platforms:

* Linux/X11 – Qt for X Window System (Unix / Linux)
* Mac OS X – Qt for Apple Mac OS X. Support for applications on top of Cocoa APIs
* Windows – Qt for Microsoft Windows
* Embedded Linux – Qt for embedded platforms (PDA, Smartphone, etc.)
* Windows CE – Qt for Windows CE[14]
* Symbian – Qt for the Symbian platform.[15][16][17][18][19][20][21][22] Qt is to replace Nokia's Avkon as the supported UI SDK for the development of Symbian applications.[23]
* Maemo – Qt for Maemo, merged with Moblin to MeeGo

[edit] External ports

Since Nokia opened the Qt source code to the community on Gitorious various ports have been appearing. Here are some of them:

* Qt for OpenSolaris – Qt for OpenSolaris[24]
* Qt for Haiku – Qt for Haiku OS[25]
* Qt for OS/2 – Qt for OS/2 eCS platform.[26]
* Qt-iPhone – Experimental development of Qt for the iPhone.[27]
* Android-Lighthouse – Experimental development of Qt for Android.[28]
* Qt for webOS – Experimental development of Qt for webOS on Palm Pre.[29][30]
* Qt for Amazon Kindle DX – Experimental development of Qt for Amazon Kindle DX.[31]

IMO is QT momenteel de beste keuze voor multi platform ontwikkeling waar performance nodig is c.q. waar java qua performance niet voldoet.

[YopY]

IMO is QT momenteel de beste keuze voor multi platform ontwikkeling waar performance nodig is c.q. waar java qua performance niet voldoet.

of C#/.NET waarvan de ondersteuning op andere platformen nog achterblijft omdat dat via een open source project moet.

Java is overigens wel goed performant, alleen gebruikt het veel geheugen (o.a. door veel abstractielagen, virtuele machine) en dergelijke. Niet dat ik een Java vs de rest wil starten overigens.

[Enfer]

Interresante opmerking (dat java qua performance niet voldoet), alleen vind ik 'm tamelijk waardeloos zonder betrouwbare bron. Zou je hiervan een bron kunnen geven? Ikzelf merk namelijk helemaal niet dat Java slechte performance levert, zie ook de opmerking van YopY.

Natuurlijk ben ik wel met je eens dat het wel concurrenten kunnen zijn, hoewel je natuurlijk wel in je achterhoofd moet houden dat QT geen ontwikkeltaal is, maar een (cross-platform) library/framework die o.a i.c.m C++ gebruikt kan worden

[willem_liu]

Het voornaamste probleem met Java en platformonafhankelijk programmeren is dat het geen hardware ondersteuning biedt waar Qt dat wel doet. Met Qt kan je aanspraak doen op bijvoorbeeld OpenGL.

[MetroidPrime]

Java ondersteunt al enige tijd hardware acceleratie. Java heeft hardware accelerated rendering pipelines die gebruik maken van DirectX en OpenGL. Onder Windows en op de Mac is de default rendering pipeline er eentje die hardware acceleration ondersteunt, maar ik weet niet of de OpenGL pipeline tegenwoordig al de default is onder Linux.

[Verwijderd]

Interresante opmerking (dat java qua performance niet voldoet), alleen vind ik 'm tamelijk waardeloos zonder betrouwbare bron. Zou je hiervan een bron kunnen geven? Ikzelf merk namelijk helemaal niet dat Java slechte performance levert, zie ook de opmerking van YopY.

Je moet me geen woorden "op het toetsenbord leggen".
Lees de regel die ik typte nog een keer.

IMO is QT momenteel de beste keuze voor multi platform ontwikkeling waar performance nodig is c.q. waar java qua performance niet voldoet.

In de veel gevallen voldoet Java prima. Maar bij high performance toepassingen 3D gaming, media encoding c.q. video editing etc kan/zal java te weinig performance hebben. Puur omdat het geen binair gecompileerde taal is net als C# op .Net. Je hebt voor beide een virtual machine nodig die de code omzet naar de door de processor begrijpbare instructies.
Aangezien QT wel binair gecompileerd is heeft deze een veel betere performance. Het nadeel is dat de code voor iedere CPU/OS apart gecompileerd moet worden. (Wat bij Java niet hoeft)

[killingdjef]

Aangezien QT wel binair gecompileerd is heeft deze een veel betere performance. Het nadeel is dat de code voor iedere CPU/OS apart gecompileerd moet worden. (Wat bij Java niet hoeft)

Zoek eens wat op over "HotSpot".

Dat is een onderdeel van Java's VM die vaak gebruikte code compiled naar binaire instructies. Hierdoor draaien de onderdelen die het vaakst gebruikt worden heel snel.

[YaPP]

Interresante opmerking (dat java qua performance niet voldoet), alleen vind ik 'm tamelijk waardeloos zonder betrouwbare bron. Zou je hiervan een bron kunnen geven? Ikzelf merk namelijk helemaal niet dat Java slechte performance levert,

Het probleem met Java is dat een aantal fundamentele zaken performance vreten:
- geen stack based allocates van tijdelijke data structuren -> alles komt op de heap.
- geen inline allocatie van sub objecten -> alle subobjecten staan versnippert door het geheugen.

De garbage collector zelf is een performance overhead. Voor al deze subobjecten moet de GC nog extra aan het werk.

het klopt dat een JIT de applicatie flow kan verbeteren, en soms zelfs sneller dan native kan maken. Toch is het de ontwikkelaars van JGit bijvoorbeeld niet gelukt om de Java versie van Git beter te maken dan de C versie. Ze blijven - na een hele hoop tweaks - steken bij 2x langzamer dan C.

http://marc.info/?l=git&m=124111702609723

Het grootste voordeel van een native programmeertaal is dat je vele losse geheugenallocaties en gekopieer heen-en-weer kan voorkomen. Deze operaties zijn duur, en in Java (omdat alles een heap-object is) niet te vermijden.

Een prachtig stukje performance advies:

De CPU draait op een vaste snelheid. Je kunt de instructies niet sneller laten lopen. Het enige wat je kunt doen, is ervoor zorgen dat je programma minder hoeft te doen. Minder kopiëren, minder ingewikkelde code, minder complexe algoritmen. Daar helpt een close-to-metal taal als C bij. Het voordeel van een high-level taal is dat je slimme dingen soms sneller kan bouwen, en daarbij een acceptabele performance haalt.

[Reactie gewijzigd door YaPP op 27 juli 2024 05:32]

[julby]

Wat te denken van applicaties als Google Earth, Skype, Opera, Scribus? bron

Ik heb zelf maar een beperkte ervaring met Qt, maar moet zeggen dat ik het toch ideaal vond werken voor de creatie van multiplatform GUI applicaties.

[Ook al Bezet]

Wat te denken van applicaties als Google Earth, Skype, Opera, Scribus? bron

Verouderde bron, Opera wordt sinds versie 10.50 niet meer met QT gemaakt, het gebruikt gewoown wat aanwezig is. Op een KDE desktop zal dus inderdad QT gebruikt worden om de UI te tekenen, terwijl op een Gnome desktop GTK+ zal worden gebruikt.

[arendjr]

Sinds (uit m'n hoofd) versie 4.5 kan Qt ook gebruik maken van GTK-thema's voor het renderen. Weet je zeker dat dit hier niet gebruikt wordt?

[Goderic]

Ik ben er vrij zeker van dat Qt niet in KDE gebruikt wordt, Opera ziet er nl uit als een lelijk GTK programma (ondanks de zogezegde KDE integratie)

[jjkewl]

Ik gebruik Qt v4.6 nu al een jaar. Het lijkt erg op Objective-C kwa MVC opzet (zodat ik het met weinig moeite kan porten naar iOS). Is soepel en eenvoudig van een native of een eigen UI te voorzien. In een dag bouw je bijv een Adobe-achtig interface (docking panels met toeters en bellen). XML support daarentegen is huilen, dus zelf bijv TinyXml integreren. Presteert zeer behoorlijk op alle desktops (pc/mac/linux).

Ben ook benieuwd hoe het op deze minder krachtige telefoons draait.

[Verwijderd]

Helaas werkt het niet zo makkelijk. OpenGL is ook op meerdere platformen en toch garandeerd het niet dat apps makkelijk over te zetten zijn. Net zo met Qt. Als Qt beschikbaar is op een aantal platformen maakt dit porten iets makkelijker, maar er is ook een kans dat nog steeds meer dan 50% van de code platformspecifiek is.

[Ruud v A]

Bij het ontwikkelen van normale computerprogrammas is Qt wel handig, maar met mobiele telefoons lijkt dat me toch een stuk lastiger. De verschillen zijn veel groter. Op telefoons is de snelheid veel meer van belang, en bijvoorbeeld de resolutie van het scherm is overal anders. Je kunt wel iets hebben dat overal op past, maar het houdt natuurlijk ook een keer op.

[GeniusDex]

Het is niet 1 op 1 over te zetten nee, maar de library zelf is niet erg zwaar en ook heerlijk om te gebruiken voor op smartphones. Ik heb er een paar maanden terug even mee gespeeld, en kon toen met 1 kleine wijziging een simpele desktop-applicatie op mijn 5800 laten draaien.

Uiteraard moet je bij het porten je applicatie aanpassen voor zaken als schermresolutie, andere inputmethode, etc. De performance zal, mits je daar bij je normale applicatie ook op gelet hebt, waarschijnlijk geen probleem zijn. Qt werkt erg soepel en snel is mijn ervaring.

[willem_liu]

Op User Interface gebied valt inderdaad weinig te halen, maar als de applicatie goed gelaagd is opgezet dan kan je de busines logic hetzelfde houden op alle platforms waarbij je alleen de UI laag hoeft aan te passen specifiek voor de verschillende platforms.

[Anoniem: 366402]

QT is tegenwoordig best we toegespits op mobiele hardware, door zelfs een compleet eigen grafische omgeving te hebben. (zodat je geen rare X hacks hoeft te gebruiken).

Gelukkig is QT niet meer het lelijke zware beest van vroeger waardoor iedereen een hekel aan KDE had.

[Aaargh!]

Op telefoons is de snelheid veel meer van belang, en bijvoorbeeld de resolutie van het scherm is overal anders.

En op PC's is deze overal hetzelfde ? Nog ff afgezien van het feit dat je de meeste apps kan resizen naar whatever formaat je handig vind.

[Ruud v A]

Nee, maar bij computerschermen is het aantal pixels per inch overal ongeveer hetzelfde, zodat meestal alles goed leesbaar is. Bij telefoons verschilt dat veel meer, wat op een telefoon koeienletters zijn, kunnen op een andere telefoon nauwelijks leesbaar zijn. Met touchscreens wordt het nog erger, omdat je vinger dan ook nog moet passen.

[jjkewl]

Daarom scheid je functie van vormgeving. Ook zal je afentoe ingewikkelde functionaliteit moeten/willen uitkleden voor mobiel om het aantal benodigde schermen te beperken. Over het algemeen wordt je desktop software ook beter, slimmer en meer overzichtelijk nadat je hebt nagedacht over de mobiele versie (less = more, form follows function, etc).

[Forsith]

QT werkt ook perfect voor desktops hoor! Ik gebruik het zelf (i.c.m C++) voor de desktop applicaties die ik schrijf. Je kan met de (L)GPL license van Nokia gratis de source downloaden en compileren (duurt wel eventjes ). Ik begreep van een maat van mij dat Nokia met QT een vrij directe concurrent van .NET voor ogen heeft, iets wat misschien ook wel gaat lukken.

Het verbaast me dan ook niets dat Nokia probeert QT te pushen door dit ook op de nieuwe smartphones te zetten. Uiteindelijk moet je natuurlijk als professioneel ontwikkelaar wel flink lappen (1500 euro per jaar voor 1 OS per ontwikkel dacht ik), maar ze steunen er uiteindelijk ook het maken van gratis apps mee. Ik zie dat dan ook als een goede ontwikkeling van Nokia!

[MSalters]

Nu hoepn dat Symbian ook recente, complete GCC versies gaat ondersteunen op downmarket Symbian versies. Nokia heeft heel lang vastgehouden aan een gestripte versie van GCC3, terwijl de rest van de wereld al jaren over was op GCC4.

Overigens is ook Google met hun C++ versie voor Android in de vorige eeuw blijven hangen.

[ATS]

Qt zelf werkt in elk geval prima met GCC4.

[_Thanatos_]

Het is maar afwachten. Ik voorzie nog steeds drie grote problemen:

1) Het is (weer) een extra laagje dat geinstalleerd moet worden en alleen maar extra ondersteund moet worden.

2) Het gebruik van meerdere programmeertalen maakt het juist hoogdrempelig, en dat is bijna nooit goed voor het opbouwen van een massale applicatiewinkel.

3) Het gebruik van Qt maakt het geenszins platformontafhankelijk of portable naar linux/windows, gezien je een app voor een mobieltje nog steeds heel anders schrijft dan een app voor een desktop OS. Of je krijgt applicaties die aan alle kanten uitstralen dat ze voor en door nerds gemaakt zijn.

Met alleen een set nieuwe widgets en wat wrappers ben je er nog niet. Je moet juist zorgen voor een heldere, eenduidige omgeving met een eenvoudige maar wijdverspreide taal. Nu proberen ze het heel krampachtig aan alle mogelijke kanten zo flexibel mogelijk te maken, waardoor het gebruik ervan juist alleen maar moeilijker wordt.

Ik spreek niet uit ervaring, maar ik ben wel historiebewust. Dit is in het verleden altijd zo geweest, en tot op heden blijft het voorspelbaar: ontwikkelen voor iPhone en Android is makkelijk, terwijl het volwaardige omgevingen zijn en een volwaardige taal gebruiken, maar omdat de implementatie heel eenduidig is, doet iedereen hetzelfde en dat maakt het heel doorzichtig. Ontwikkelen voor bijv linux is juist heel ondoorzichtig, ook al is het heel "open", omdat er 23487123987 manieren zijn om iets te doen, ipv gewoon 1, toch is het zo flexibel dat het in theorie (en alléén in theorie) makkelijk moet zijn.

[Verwijderd]

Sorry maar ik vind je voorziene problemen niet bestaand.

1) het zijn gecompileerde programma's, geen extra laagje dus;

2) windows is alleen maar groot geworden indertijd door de tig device drivers

3) heb je ooit wel eens een app voor meerdere os-en gesschreven

[_Thanatos_]

1) Ja en? Ik bedoel als een telefoon nou geen Qt heeft? Wat dan? Dat heeft niets te maken met wel of niet gecompileerd.

2) Dat klopt, en wat precies heeft dat met mijn punt 2 te maken?

3) Ja, maar alleen in de vorm van webapplicaties. Het gaat me vooral om meerdere platformen. In THEORIE is het allemaal heel mooi: alle toolkits die je nodig hebt, bestaan al. Maar in de PRAKTIJK maakt het niet uit hoe je het wendt of keert, een mobiele app is anders dan een desktop-app.

[Verwijderd]

1) je compileert (je hebt geen extra laagje)

2) gebruikers, ontwikkelaars in dit geval, zijn zeer wel in staat zelf te bepalen voor welk gedeelte van een applicatie zij welke programmeertaal willen gebruiken, 'one fits all' is regelrechte lariekoek.

3) zie ook 2) je optimaliseert je code waar nodig

[ATS]

QML gaat komt toch wel een heel eind tegemoet aan je problemen in punt 3.

[_Thanatos_]

Fijn, dan krijg je van die apps die op een mobieltje "raar" werken omdat ze geport zijn vanaf een desktop-app, of juist andersom. Een mobiele app is nou eenmaal HEEL anders dan een desktop-app. Ik begrijp werkelijk waar niet hoe je het kunt bedenken dat ze twee gelijktijdig te schrijven zijn met eoa toolkit. Alleen het design al.

[StarZ]

Maar vervolgens geen centrale market maken... fail

[willem_liu]

Als hun "App Up" programma een verzamelplaats is van verscheidene repositories zoals de Hildon Application Manager bij Maemo dan is dat vrijwel een centrale market.
De Symbian telefoonjes hebben in ieder geval OVI store welk al een centrale market is.

[Terracotta]

Hun app up is een centrale market per hardware leverancier, in het geval van nokia wordt dat dus Ovi voor meego.

[willem_liu]

Op het moment in Maemo 5 heb je de HAM. Daarin kan je verschillende repo's toevoegen bijvoorbeeld:
- maemo.org
- joikuspot
- Sygic Mobile Maps

Dat zijn verschillende producenten van software. Echter in de HAM zie je geen verschil. Alle producten staan in 1 lijst.

[himlims_]

Centraal voor Nokia , niet voro 't platform enzich

[Anoniem: 366966]

QT is veel te complex voor het snel en simpel in elkaar kunnen flansen van de UI voor een app'je. Android werkt gewoon met xml-styletags:daarmee is het veel gemakkelijker en snel een leuke bruikbare UI te maken.

http://developer.android.com/guide/topics/ui/themes.html

[Reactie gewijzigd door Anoniem: 366966 op 27 juli 2024 05:32]

[BartOtten]

Maar in principe kan je dus wel iets scripten wat vervolgens ook op de desktop- PC kan draaien, op het scherm op in de koelkast enz enz.....Qt is heel erg uitgebreid en dat geeft het toch een puntje voorsprong.

[willem_liu]

QT heeft ook QML om snel iets in elkaar te flansen.

Dit is een script taal wat veel weg heeft van JavaFX en de taal die wordt gebruikt in Adobe FlexBuilder.

[Reactie gewijzigd door willem_liu op 27 juli 2024 05:32]

[julby]

Als je doel "snel" (een middagje?) een "app'je" in elkaar knutselen is, ok.. Maar zo moeilijk is Qt niet. Als je C++ al een beetje onder de knie hebt kan je met de Interface Designer van Qt behoorlijk snel interfaces in elkaar zetten. Een erg groot voordeel daarvan vind ik de vele voorbeelden die bij Qt worden meegeleverd en de erg uitgebreide (offline/online) documentatie.

[Verwijderd]

Allemaal leuk die "open-source" software, maar voor de gemiddelde consument is het niet interessant. Je moet de ontwikkelingen redelijk intensief volgen om bij te blijven. In de praktijk komt het er op neer dat fabrikanten toch zelf weer een update uit moeten brengen die weer draait op hun toestellen (zie Android).
Met als gevolg dat er een enorme versnippering op treedt -> hooguit 30-40 % heeft de laatste versie van de software geïnstalleerd. Open-source projecten zijn in mijn ogen een leuke inspiratie bron voor de magnaten die wel weten hoe ze geld moeten verdienen aan innovatie.

Ik heb zelf ook het een en ander meegemaakt in "open-innovatie". Waar het op neer komt is dat er vroeg of laat een partij bij betrokken is die de vruchten plukt van het enthousiaste, harde werk van "vrijwilligers".

Ik werk er niet aan mee, wordt er misselijk van; "open-zijn" is de nieuwe hype. Het is echter veelal gebakken lucht.

[wankel]

Ik sluit me aan bij Jerie, en

In de praktijk komt het er op neer dat fabrikanten toch zelf weer een update uit moeten brengen die weer draait op hun toestellen (zie Android).

Dat is het doel van OHA, de Open Handset Alliance. Maar dat kon je natuurlijk niet weten, met je attitude naar alles wat naar open ruikt ;-)

[Verwijderd]

Ja ergens op papier is het misschien de bedoeling, maar in de praktijk is het een ander verhaal. Google is de aanvoerder en fabrikanten zijn afhankelijk van Google. Daar is helemaal niets opens aan.
Eindgebruikers zijn niet zeker van updates, aangezien Android standaard niet op je telefoon draait. Daarvoor moet de fabrikant besluiten jouw toestel nog te ondersteunen, of toch maar niet. Onzekerheid ten top.
Wat ook zo'n leuke is, apps die niet elke Android telefoon ondersteunen. Kwam het afgelopen weekend nog tegen bij een maat van me. Er is dus ook geen sprake van eenheid binnen het Android platform.

Er is niets mis met het idee open, maar het is net zoiets als het communisme. Uiteindelijk faalt het. Android is daar een mooi voorbeeld van en blijkbaar is Linux ook niet zo fantastisch dat de gemiddelde consument er de meerwaarde van in ziet. En zo naïef zijn ze nu ook weer niet, als ze gratis kunnen downloaden weet ook ineens iedereen wel wat bittorrent is.

Ik blijf erbij dat "open" zijn de hype is die helemaal past bij het falen van het kapitalistisch systeem en de daaruit voortgekomen kredietcrisis. Ja, open-source is een ontwikkeling die al veel langer gaande is, maar nee NU is niet de tijd dat het hoogtij gaat vieren.

[Jerie]

Ja ergens op papier is het misschien de bedoeling, maar in de praktijk is het een ander verhaal. Google is de aanvoerder en fabrikanten zijn afhankelijk van Google. Daar is helemaal niets opens aan.

Er is inderdaad sprake van een machtsverhouding.

Echter, de software is volledig open, en je mag dus een custom firmware maken. Ook als fabrikant van een mobieltje. Er zijn ook custom firmwares, maar die bevatten dan niet de Google-specifieke software. Dat is logisch. Je bent ook afhankelijk van anderen die tijd/moeite/geld steken in zo'n custom firmware, maar dat is een kenmerk van open source: het is niet persee gratis.

Eindgebruikers zijn niet zeker van updates, aangezien Android standaard niet op je telefoon draait. Daarvoor moet de fabrikant besluiten jouw toestel nog te ondersteunen, of toch maar niet.

Je koopt een telefoon met een bepaalde Android versie en die wordt ondersteunt. Het is niet zo dat de volgende 5 versies van het OS ondersteunt worden.

Onzekerheid ten top.

FUD, ja.

Wat ook zo'n leuke is, apps die niet elke Android telefoon ondersteunen.

Dat kom je bij zo'n beetje elk OS en stukje hardware tegen. Ook bij iOS, Windows, Symbian, enz. Niet iedere telefoon is even populair of nieuw, of heeft dezelfde hardware.

Op mijn iPod touch kan ik standaard bijvoorbeeld niet met een GPS over BlueTooth babbelen, en ook geen GPS software installeren, terwijl het apparaat wel BlueTooth bevat. Om dat te activeren moest ik 10 EUR betalen, en zelfs dan mag ik het niet gebruiken om te babbelen met een GPS.

Op mijn Nokia E71 kon ik dat wel. Op mijn Nokia N900 kan ik dat ook. Op mijn Macbook Pro kan ik dat ook.

Er is niets mis met het idee open, maar het is net zoiets als het communisme. Uiteindelijk faalt het.

-1 troll.

Ik blijf erbij dat "open" zijn de hype is die helemaal past bij het falen van het kapitalistisch systeem en de daaruit voortgekomen kredietcrisis. Ja, open-source is een ontwikkeling die al veel langer gaande is, maar nee NU is niet de tijd dat het hoogtij gaat vieren.

Kapitalisme, kredietkrisis, wat maak je het toch ingewikkelt... dit zijn puur losse kreten, die enig fundament missen.

[ChaoZero]

Het feit dat niet alle android gebruikers op dezelfde softwareversies draaien is JUIST te wijten aan de merken die er geld aan verdienen; zoals htc. Laten alles ontwikkelen door de open-source community en als 2.1 eindelijk feilloos draait op de hero compilen ze de htc UI erop en brengen ze die uit als official update.

Wanneer er gebruik gemaakt wordt van packagemanagers en repositories zijn de updates (ook van software van derden) velen malen beter geregeld dan onder windows (mobile).

openoffice.org, java, flash, chrome, firefox; eigenlijk ieder programma wordt automatisch meegepakt.

De gebruikers die niet de laatste versie hebben zijn nalatig; niet slachtoffer van open-source software...

[Relief2009]

Gelukkig wil Google dat veranderen en toch een centrale update invoeren door gebruik te maken van modules.

[Jerie]

Misschien past jouw post meer in een of andere open source versus proprietary flamewar. Heeft nl weinig met Qt te maken. Sterker nog, je mag prima proprietary software tegen Qt compileren. Het doel van Qt is dan ook adoptie ongeacht de vraag of de software die gebruik maakt van Qt proprietary of open source is. Mbt het updaten van open source software kan ik kort zijn: APT.

[RoelRoel]

Je moet wel belachelijk veel geld betalen wil je een closed source licentie krijgen.

[ATS]

Of je gebruikt de LGPL versie en betaalt helemaal niets. Is het dan zo moeilijk om je even te informeren voor je dit soort dingen uitkraamt?

[wdulli]

Nu maar hopen dat ze angry birds voor Qt ontwikklen dan kan ik met mijn S60v5 ook uren lang spelen

[GiLuX]

je kan ook online de flash equivalent spelen:
http://armorgames.com/play/3614/crush-the-castle

[Hooiopdevork]

Het is wel irritant dat je onderhand ieder merk telefoon aparte software moet schrijven