Linked by Thom Holwerda on Fri 18th Feb 2011 23:29 UTC
PDAs, Cellphones, Wireless The man, the legend: a main developer of the BeOS. Did the App Server, Interface Kit, Application Kit. These days, Benoit Schillings does something else entirely: he's currently the chief technology officer at Myriad, where he and his team is working on Alien Dalvik. Now that I know he's the one leading this team, I know for sure we've got something special here.
Order by: Score:
Running without Qt
by Kaj-de-Vos on Sat 19th Feb 2011 00:26 UTC
Kaj-de-Vos
Member since:
2010-06-09

It's unlikely that Qt plays a big role here, as the point of Dalvik is that it comes with its own GUI toolkit. Probably, Qt was just a suitable windowing system to target, because it makes the whole thing portable. So if you don't have or want Qt, it's probably quite doable to port it to a different graphics/windowing system.

Reply Score: 2

RE: Running without Qt
by marcell on Sat 19th Feb 2011 01:43 UTC in reply to "Running without Qt"
marcell Member since:
2005-07-11

qt probably *plays* a big role. qt targets different paint engines on different platforms (x11 on *nix, CoreGraphics on osx, opengl es for embedded or it's own raster engine for any other situation). that's *one* of the things which makes qt great for cross-platform development.

programming virtual machines can be done with idea to run it in hosting environment (e.g. javascript, lua and even python) or to run it independent from any hosting environment. dalvik vm is done to be the only virtual machine running on top of hardware (using linux kernel just for communication with hardware). java vm tries to run in parallel with the rest of the system. alien dalvik obviously like java vm is designed to run in parallel with other vms or on top of them.

making vm to be easy to integrate with many systems is quite hard. that's why qt is/was great choice for alien dalvik. besides targeting different graphic's systems qt provides unique api for many other subsystems: networking, multithreading, multimedia, interobject/process communication etc.

qt is not perfect. but besides mono (which is heavily leaning on .net) this is the *only* really cross-platform development atm. and it is lgpl.

qt (without nokia fucking it up with ms deal) could repeat the history of superior os/2 which could run native windows application even better then windows itself. providing that kind of solution you usually convince lazy devs to go just with native android or in the past windows applications.

Reply Score: 4

RE[2]: Running without Qt
by Kaj-de-Vos on Sat 19th Feb 2011 01:50 UTC in reply to "RE: Running without Qt"
Kaj-de-Vos Member since:
2010-06-09

Please note that I said "doesn't play a big role *here*" (answering Thom's question). Why else would Benoit say that Qt can be eliminated from the equation?

Reply Score: 1

RE[3]: Running without Qt
by marcell on Sat 19th Feb 2011 02:11 UTC in reply to "RE[2]: Running without Qt"
marcell Member since:
2005-07-11

ok, sorry. i probably got it wrong. my point is that qt *is* very important for writing the vm and of course that after vm being finished/compiled you don't need qt anymore to run it. still, there is a probably quite easier integration with systems which are based on qt (e.g. meego).

Reply Score: 1

RE[4]: Running without Qt
by vodoomoth on Mon 21st Feb 2011 13:52 UTC in reply to "RE[3]: Running without Qt"
vodoomoth Member since:
2010-03-30

i probably got it wrong. my point is that qt *is* very important for writing the vm and of course that after vm being finished/compiled you don't need qt anymore to run it.

Hmm, no. Libraries used to develop a code are usually also needed at runtime; otherwise there's no point in using them. The only exception I know of is unit test libraries, which are useless after the product is released. Unless Qt is used by the development tools and not by the product itself, Qt is needed at runtime. It may be linked in a static way but it's definitely there.

Edited 2011-02-21 13:53 UTC

Reply Score: 2

webOS
by Moochman on Sat 19th Feb 2011 01:30 UTC
Moochman
Member since:
2005-07-06

Please HP put this on webOS! Right now webOS is missing country/city-specific apps (for instance public transport planning) in most parts of the world. If Android apps could run on webOS, this would no longer be an issue, and nothing would stand in the way of a successful worldwide webOS launch!

Reply Score: 5

What about existing N900 users?
by moriarty on Sat 19th Feb 2011 01:50 UTC
moriarty
Member since:
2011-02-19

I'm actually a bit sad that considering it was first developed on the N900 with Maemo 5, they are not considering releasing it to the end users of that platform. In a MWC video they say it's a 20 MB install, and I'm pretty sure most N900 owners would be more than happy to pay for having this on their phone (as a long thread on a Maemo forum shows).

Reply Score: 4

WereCatf Member since:
2006-02-15

I'm actually a bit sad that considering it was first developed on the N900 with Maemo 5, they are not considering releasing it to the end users of that platform. In a MWC video they say it's a 20 MB install, and I'm pretty sure most N900 owners would be more than happy to pay for having this on their phone (as a long thread on a Maemo forum shows).


Indeed. I too am an N900-owner and would definitely want this thing. N900 is in the sad state of being completely discontinued, even the OS itself, and as such the only people interested in coding for it are those who do it on their free time at home and thus there simply ain't many applications to choose from, if any. If we got Alien Dalvik on the other hand we could just tap into all the great Android apps and continue using our beloved N900s for years to come.

I really hope Myriad comes around and releases this for N900, too.

Reply Score: 3

vivainio Member since:
2008-12-26

N900 is in the sad state of being completely discontinued, even the OS itself, and as such the only people interested in coding for it are those who do it on their free time at home and thus there simply ain't many applications to choose from, if any.


Huh? To me it appears there are tons of apps for N900 coming all the time, to extas-devel.

Reply Score: 3

WereCatf Member since:
2006-02-15

<quote>Huh? To me it appears there are tons of apps for N900 coming all the time, to extas-devel.</quote>

From the afore-mentioned people who code in their free time, not from any commercial entity and hardly "all the time." And tbh, most of the stuff there is just poor-quality rehashes of what is already available.

Reply Score: 2

RE: What about existing N900 users?
by ricegf on Sat 19th Feb 2011 14:49 UTC in reply to "What about existing N900 users?"
ricegf Member since:
2007-04-25

+1. I'd pay some serious money for a nice Android emulator on my N900, even in "as is" condition - not because I'm unhappy with my N900 (what other phone runs Free42, Python and Firefox?), but just for the fun of exploring alien Android apps on my old friend.

Well, I can hope they'll change their mind...

Reply Score: 4

vivainio Member since:
2008-12-26

but just for the fun of exploring alien Android apps on my old friend.


You can buy an mmc card and install Android (NITDroid) on it. This sets up a dual boot system where you can select either Maemo or Android at boot time.

Reply Score: 1

WereCatf Member since:
2006-02-15

You can buy an mmc card and install Android (NITDroid) on it. This sets up a dual boot system where you can select either Maemo or Android at boot time.


There's still plenty basic of functionality that doesn't work. Last I tried it even basic phone calls didn't work. Neither does camera. That already renders some of the most important functionality useless.

If on the other hand we had Alien Dalvik we would be able to benefit from those features and still sport our favorite Android apps.

Reply Score: 2

Comment by mutantsushi
by mutantsushi on Sat 19th Feb 2011 02:13 UTC
mutantsushi
Member since:
2006-08-18

What is so great about this?
I mean, what is so great about Java/Dalvik apps, that make them better than QT apps?
If he can embed needed QT code, why can´t this be done with any app, making it completely portable?
I suppose this would have the advantage of UI compositing possibly being hardware accelerated unlike Android, but that´s not really an advantage over something that keeps away from Dalvik entirely. I just don´t like the whole idea that Dalvik has ´resurrected´ Java somehow, when I thought it was dying for good reaons. Why not just put the same effort into building more meta-APIs, scripting JIT and tools to extend QT?

Edited 2011-02-19 02:17 UTC

Reply Score: 2

RE: Comment by mutantsushi
by Kaj-de-Vos on Sat 19th Feb 2011 02:22 UTC in reply to "Comment by mutantsushi"
Kaj-de-Vos Member since:
2010-06-09

It's not about Dalvik versus Qt; it's about making Dalvik applications available to people who can't run them now.

Reply Score: 2

RE[2]: Comment by mutantsushi
by shmerl on Sun 20th Feb 2011 00:46 UTC in reply to "RE: Comment by mutantsushi"
shmerl Member since:
2010-06-08

If this isn't open source and won't be available even for buying - what's the fuss?

Reply Score: 2

RE[2]: Comment by mutantsushi
by mutantsushi on Sun 20th Feb 2011 01:01 UTC in reply to "RE: Comment by mutantsushi"
mutantsushi Member since:
2006-08-18

OK, crap for all, then...
I mean, why not Win16 for all platforms?
Certainly more apps exist there than Dalvik.

Reply Score: 1

RE[3]: Comment by mutantsushi
by shmerl on Sun 20th Feb 2011 02:28 UTC in reply to "RE[2]: Comment by mutantsushi"
shmerl Member since:
2010-06-08

I'm not sure what are you talking about. Given the popularity of Android - the number of quality Dalvik based apps will only increase.

Reply Score: 1

RE: Comment by mutantsushi
by moondevil on Sat 19th Feb 2011 06:48 UTC in reply to "Comment by mutantsushi"
moondevil Member since:
2005-07-08

Java never died.

Many people wish it did, but it is still the number one language to program for. And in the IT world, most new developments are Java/.Net based, regardless of the geek community might feel about it.

I do love my C++, and feel there is no native programming language that matches it for the time being, but many companies see it differently.

To be honest if it hasn't for QT, you would be hard pressed to find a good C++ framework.

The main problem being that there are not many developers that know how to properly make use of C++.

Plus C++ is not a language that is easy to outsource,
hence the focus in easier languages.

Reply Score: 3

RE[2]: Comment by mutantsushi
by mutantsushi on Sun 20th Feb 2011 01:04 UTC in reply to "RE: Comment by mutantsushi"
mutantsushi Member since:
2006-08-18

Right, I don`t expect everybody to write every little app in C++.
(though Apple`s App Store seems to have plenty of developers who can write in ObjC...)
Fortunately, QT has it`s own JS-based QTScript and QML, and can link to other langauges like Ruby or Python. So language isn`t the issue for WRITING the apps, but only matters as far as the `standard platform language` determines the functionality of the API. Obviously, people still write C++ where it`s needed... And Google recognizes this, enabling native code execution was their first step away from Java mediocrity. Yet their entire API apps are expected to interact with general functions is still based on Java/Dalvik and it`s compositor isn`t even HW-accelerated (and they don`t seem to care).

Including QT sub-components for platforms that don`t already host them is a drag, but that`s what you have to do when platforms are closed and don`t allow users to install those libraries. Given network speeds, and the fact each app will not use the vast majority of QT, I don`t think it imposes an overly harsh burden for downloading of single apps.

Edited 2011-02-20 01:22 UTC

Reply Score: 3

RE[2]: Comment by mutantsushi
by Soulbender on Sun 20th Feb 2011 04:06 UTC in reply to "RE: Comment by mutantsushi"
Soulbender Member since:
2005-08-18

Many people wish it did, but it is still the number one language to program for. And in the IT world, most new developments are Java/.Net based,


Ah, so it's the new Cobol.

Reply Score: 4

RE[2]: Comment by mutantsushi
by ari-free on Sun 20th Feb 2011 12:09 UTC in reply to "RE: Comment by mutantsushi"
ari-free Member since:
2007-01-22

"And in the IT world, most new developments are Java/.Net based, regardless of the geek community might feel about it. "

They can have all the java and C# they want as long as it stays behind the corporate firewall along with Visual Basic. Consumers want smooth 3D hardware acceleration and low latencies for audio apps and they won't get it from java. That's why Android had to spend so much time working and expanding the NDK/renderscript.

Reply Score: 3

RE: Comment by mutantsushi
by ari-free on Sun 20th Feb 2011 14:40 UTC in reply to "Comment by mutantsushi"
ari-free Member since:
2007-01-22

"I suppose this would have the advantage of UI compositing possibly being hardware accelerated unlike Android"

I think this has changed for Honeycomb:
http://android-developers.blogspot.com/2011/02/introducing-rendersc...
http://developer.android.com/sdk/android-3.0-highlights.html
"Android 3.0 offers a new hardware-accelerated OpenGL renderer that gives a performance boost to many common graphics operations for applications running in the Android framework. When the renderer is enabled, most operations in Canvas, Paint, Xfermode, ColorFilter, Shader, and Camera are accelerated. Developers can control how hardware-acceleration is applied at every level, from enabling it globally in an application to enabling it in specific Activities and Views inside the application."

Reply Score: 3

Re: Embedding Qt
by remerico on Sat 19th Feb 2011 05:03 UTC
remerico
Member since:
2005-07-06

It is possible to embed parts of Qt in an app by recompiling Qt to be statically linked.

It does take a bit more work to accomplish, but it is perfectly doable.

Probably the reason why most developers don't do this is that it substantially increases the application's size, since it has to include whole or parts of Qt inside the app itself. It is also more practical to use Qt as an external library so it can be reused by other Qt apps, reducing code redundancy.

However, if the developer is targeting a system that doesn't have a Qt installed (or is quite a hassle to install), embedding Qt might be a better option.

More info here: http://www.formortals.com/how-to-statically-link-qt-4/

Edited 2011-02-19 05:16 UTC

Reply Score: 1

RE: Re: Embedding Qt
by mutantsushi on Sun 20th Feb 2011 01:02 UTC in reply to "Re: Embedding Qt"
mutantsushi Member since:
2006-08-18

Right, no reason you couldn`t do this for iOS AFAIK.
Even under their former language restrictions, C/C++ qualified.

Reply Score: 1

RE[2]: Re: Embedding Qt
by shmerl on Sun 20th Feb 2011 02:30 UTC in reply to "RE: Re: Embedding Qt"
shmerl Member since:
2010-06-08

Since Lighthouse is still in development and not included in regular Qt licenses - all this can't be normally used. But it's possible, yes:

http://www.youtube.com/watch?v=MjYJdi48B8Q

Reply Score: 1

Comment by Radio
by Radio on Sat 19th Feb 2011 22:11 UTC
Radio
Member since:
2009-06-20

Sorry in advance if I sound like that-same-troll-again, but can someone remind me again why MeeGo is now Nokia's fifth wheel, while WP7 - for which Alien Dalvik is not ready, and would have to be allowed to use native code (not impossible, but not done yet) - is their main platform?

"MeeGo is too late and does not have any app", right?

Seriously, between this and the lack of communication with Intel, Nokia really looks like a headless chicken.

(On an unrelated note, I just discovered the real story of Mike the headless chicken... :shock:)

Edited 2011-02-19 22:12 UTC

Reply Score: 3

RE: Comment by Radio
by Nelson on Sun 20th Feb 2011 03:54 UTC in reply to "Comment by Radio"
Nelson Member since:
2005-11-29

Because customers want a compelling experience. Shoehorning Android apps onto another platform wont solve that problem.

Reply Score: 2

RE[2]: Comment by Radio
by makkus on Sun 20th Feb 2011 07:58 UTC in reply to "RE: Comment by Radio"
makkus Member since:
2006-01-11

It doesn't have to be shoehorning. I use old Windows, Amiga and other games all the time on my T61p with Fedora, they appear as icons in the game menu and when clicked start fullscreen, fully configured for my hardware, including gamepad. Somebody without technical knowledge would not know it isn't native.

When implemented this way you have the second largest library of applications in the world right from the start.

Edited 2011-02-20 07:59 UTC

Reply Score: 2

RE[3]: Comment by Radio
by Nelson on Sun 20th Feb 2011 09:25 UTC in reply to "RE[2]: Comment by Radio"
Nelson Member since:
2005-11-29

It doesn't have to be shoehorning. I use old Windows, Amiga and other games all the time on my T61p with Fedora, they appear as icons in the game menu and when clicked start fullscreen, fully configured for my hardware, including gamepad. Somebody without technical knowledge would not know it isn't native.

When implemented this way you have the second largest library of applications in the world right from the start.


They maintain the Android look and feel, and throwing users who are accustomed to one experience, into another one, for the sake of application compatibility to me, is a waste. People don't want a half assed implementation I don't think, people want home grown applications optimized for the host platform.

The size of an application store does not matter as much as the quality of the most commonly used applications. 100,000 task managers don't mean a thing to the end user.

This is why a lot of these open platforms don't get anywhere. The opennes is overemphasized to the point where you sacrifice cohesion in the platform. There is a real balance that needs to be struct, and until people stop pretending that because you can do whatever you want with something, that you should, then things wont change.

Stop looking at things as numbers, or checkmarks in a feature list, and start looking at them as genuine, compelling end user experiences.

I'd much rather an application that performs and feels like it belongs on my phone, versus something that someone threw together. In fact, if we're going to draw comparisons, this is akin to Palm using iTunes for its webOS devices. Sure, they could do it, but its a cop out and unprofessional.

Edited 2011-02-20 09:28 UTC

Reply Score: 2

RE[4]: Comment by Radio
by Radio on Sun 20th Feb 2011 12:54 UTC in reply to "RE[3]: Comment by Radio"
Radio Member since:
2009-06-20

They maintain the Android look and feel, and throwing users who are accustomed to one experience, into another one, for the sake of application compatibility to me, is a waste.

Oh My God, this is so disturbing! The big rounded boxes does not have the same color! Everybody is so lost!

Seriously, who gives a damn? You already can't see the difference between a maemo and an android app (just look at the deezer app).

Reply Score: 4

RE[5]: Comment by Radio
by ari-free on Sun 20th Feb 2011 13:57 UTC in reply to "RE[4]: Comment by Radio"
ari-free Member since:
2007-01-22

I know...every website has a completely different look and feel and yet that doesn't stop people from using the internet.

Reply Score: 5

RE[6]: Comment by Radio
by lucas_maximus on Mon 21st Feb 2011 00:22 UTC in reply to "RE[5]: Comment by Radio"
lucas_maximus Member since:
2009-08-18

Most websites have a lot of common interface elements ...

e.g.

Call to action buttons,
Click on logo take you back to the home page,
BreadCrumbs
Header / Footer Areas.

etc. etc.

Reply Score: 2

RE[5]: Comment by Radio
by Nelson on Sun 20th Feb 2011 16:54 UTC in reply to "RE[4]: Comment by Radio"
Nelson Member since:
2005-11-29

"They maintain the Android look and feel, and throwing users who are accustomed to one experience, into another one, for the sake of application compatibility to me, is a waste.

Oh My God, this is so disturbing! The big rounded boxes does not have the same color! Everybody is so lost!

Seriously, who gives a damn? You already can't see the difference between a maemo and an android app (just look at the deezer app).
"

The way an end user expects to interact with an app is the way it's been interacting with the system as a whole. If an experience is different (not just visually, you cant sit here and tell me that Android and Maemo/MeeGo/whatever will all share consistent behavior with Android's look and feel) then the customer will be legitimately thrown off. This is UX 101. It's the whole point behind standard controls.

But you know what, you can be dismissive and you can oversimplify it if you want. However you, and engineers who think like you, are the reasons why the platform will never be a viable third way and will always remain a science project. It's like its amateur hour.

You people put principals above experience, to the point of absurdity, and you're producing a genuine, free software, open, .... piece of shit.

There is nothing wrong with code sharing or code reuse across platforms. That's fine, but the front end UI should be platform specific.

Edited 2011-02-20 16:56 UTC

Reply Score: 2

RE[6]: Comment by Radio
by WereCatf on Sun 20th Feb 2011 19:13 UTC in reply to "RE[5]: Comment by Radio"
WereCatf Member since:
2006-02-15

You people put principals above experience, to the point of absurdity, and you're producing a genuine, free software, open, .... piece of shit.

You know, more-or-less all modern platforms suffer from the fact that their applications have wildy differing looks and feel. Just take a sampling of Windows apps. Or OSX apps. Or even Android apps. And so on. Hell, even Microsoft themselves have trouble with keeping looks and feels consistent across their own software.

It still hasn't stopped people from using those applications. In fact there's applications that are extremely popular despite having looks and feels totally and wholly different from anything else!

The fact is that basic UI elements still work the same: tapping/clicking a button works the same on Android, OSX, Maemo and Windows, scrolling up or down works almost identically across all the platforms, and so on. Having slightly differing looks and feel is a hindrance, yes, but it's almost never completely blocks one from using the application in question.

Besides, trying to insinuate that only open-source software has consistency-issues is not only ignorant, it's downright stupidity.

Edited 2011-02-20 19:13 UTC

Reply Score: 4

RE[6]: Comment by Radio
by Thom_Holwerda on Mon 21st Feb 2011 00:00 UTC in reply to "RE[5]: Comment by Radio"
Thom_Holwerda Member since:
2005-06-29

[qThis is UX 101. [/q]

Didn't stop the iPhone. If you want an inconsistent mess, look no further than iOS.

Reply Score: 2

RE[6]: Comment by Radio
by lucas_maximus on Mon 21st Feb 2011 00:35 UTC in reply to "RE[5]: Comment by Radio"
lucas_maximus Member since:
2009-08-18

Well said.

A lot of commenters on here put ideals over pragmatics to the point of obsurdity.

The general "polish" on a software product that makes the difference between something which is adequate to something that is fantastic.

For example on my HTC desire, the volume buttons is exactly where my thumb would be if I am talking on the phone, so I can adjust the volume accordingly.

I also have a nokia 1661 which I use as my backup phone ... which I had to use this weekend since I left my android charger on my office desk ... another nicely designed phone which is solid ...

Double tapping "up" on the phone turns the small torch on, which is kinda intuitive since the the torch is above the screen. Tapping "down" on the phone brings up the phone book which is where the phone's keypad is ... this is a £20 phone, and nokia has made the effort to put this in ... on one of their lowest end phones.

These "nice little touches" that make the difference between good and great and many devs and geeks have an attitude "of you don't really need that" ... Consumers notice these little differences over time and it can either tarnish a companies name or make it.

Reply Score: 2

RE[6]: Comment by Radio
by Radio on Mon 21st Feb 2011 12:49 UTC in reply to "RE[5]: Comment by Radio"
Radio Member since:
2009-06-20

You people put principals above experience, to the point of absurdity, and you're producing a genuine, free software, open, .... piece of shit.
And experience proves that consistency is an over-hyped concept, usually championed by Apple and thrown by Apple fanboys at the ugly, unsuccessful Windows and Linux (as you are doing again - which is funny, as linux desktops are very consistent, at the expense of some other more important IMHO design details), who just happen to have turned their coats, by the way: http://www.osnews.com/story/24218/Consistency_in_UI_Design_Is_Now_B...

But maybe you'd rather read a report from a usability expert on this awesome iOS that crushes the competition thanks to the consistency of its interface (and not just hype):
http://www.useit.com/alertbox/ipad.html

once they do figure out how something works, users can't transfer their skills from one app to the next. Each application has a completely different UI for similar features.

In different apps, touching a picture could produce any of the following 5 results:

* Nothing happens
* Enlarging the picture
* Hyperlinking to a more detailed page about that item
* Flipping the image to reveal additional pictures in the same place (metaphorically, these new pictures are "on the back side" of the original picture)
* Popping up a set of navigation choices


Say what again?

Edited 2011-02-21 12:50 UTC

Reply Score: 4

Comment by shmerl
by shmerl on Sun 20th Feb 2011 00:25 UTC
shmerl
Member since:
2010-06-08

Is it open source?

Reply Score: 1

RE: Comment by shmerl
by vodoomoth on Mon 21st Feb 2011 13:51 UTC in reply to "Comment by shmerl"
vodoomoth Member since:
2010-03-30

Is that more important than the functionality or is it the natural curiosity in your tech side that speaks out?

Reply Score: 2

RE[2]: Comment by shmerl
by shmerl on Mon 21st Feb 2011 15:07 UTC in reply to "RE: Comment by shmerl"
shmerl Member since:
2010-06-08

See my comment above. If it's not open source (read I can install / port it if possible wherever I want), and can't even be purchased by individuals - this project is of little interest to me because of its very limited usability.

Edited 2011-02-21 15:08 UTC

Reply Score: 1

java2me over again?
by dsmogor on Sun 20th Feb 2011 14:32 UTC
dsmogor
Member since:
2005-09-01

This development seems to confirm what i had suspected, that the idea of os independent (subset of) programmable runtime isn't as dead as it seemed to be. Having the bigger part of the mobilie app market being just variants of iphone experience and differing for sake of more political ( vertical platform controll ) than technical reasons just begs for such a simple solution. They only seemed to have taken the torch form now failed sun attempt. Most apps (esp. fat clents ) doesn't dive deep into native platform caps anyway. It's only sad that programmers have again been forced to re-learn the same paradigms expressed a little bit differently for no apparent benefit most of the time. Example? somebody seemed do resent the lack of good public communication guides in some app store. from what I see there'RE plenty of perfectly capable solutions for that in j2me space, including google's own. And new ones are still emerging.

Edited 2011-02-20 14:42 UTC

Reply Score: 4