The RR Replacements.

kev000 · 10-09-2009, 12:54 PM

I love talking about software concepts. I love looking at new fresh ideas. I really like talking about innovation. So RoadRunner is now dead. The non-open RideRunner has replaced it. The technology used to code it is dead also (VB6). The concepts and basis for the creation of RR were derived from (AFAIK) Frodoplayer and is a fork of MediaCar? Anyway, all the concepts are old. Several years later, where are we today today?

What will be the software that will replace RR? For me, there are two candidates that are worth taking a look at: RevFE, OpenMobile. The rest of this dialog is technical, so if you only want the conclusion, skip to the bottom conclusion.

RevFE
RevFE is built using a flourishing and innovative language: Qt. Backed by a huge sponsor, Nokia, Qt is an exceptionally fast (prototyping and running) toolkit. The RevFE core is a tight message bus that does nothing but load and pass information between plugins. Plugin interfaces are exposed in native Qt c++, or any .NET language. This allows for RevFE to progress quickly. Plugins can be developed very fast adding new functionality.

RevFE is also crossplatform, which allows it to be run on Windows, Linux or Mac. The problem is, not all the plugins are crossplatform (the iGuidance plugin is the obvious example).

Functionality wise, RevFE is just like RR. It starts up full-screen, it launches apps, plays music, embeds other apps and acts just like a traditional monolithic frontend. Plugins can be multi-threaded or single threaded. This is good in the terms of resources, but a bad plugin could bring down the entire system. RevFE is skinnable. It loads skins from it's own XML schema or it can load RR skins.

OpenMobile
OpenMobile (OM) is written in C#. It runs on any platform that the Mono runtime will run on (win, mac, Linux). The features of the language also allow for quick prototyping as with Qt. C# runs much slower than C++ code, but on a machine with a decent processor, the difference isn't noticeable by the user. To speed up the appearance of startup, OM loads the screen and then offloads the plugin loading to another thread. When the plugins are finished loading they fade in a nice animated fashion. Traditionally, string parsing in C# is slow, so OM mobile uses compiled skins to get around that issue. The result works well.

Functionality in OM is still on the light side. The project is relatively new and progressing well. I attempted to load up the solution in monodevelop and encountered some errors. I'm not on the latest version of monodevelop, so it may just be MD issue rather than a OM issue. I'm looking forward to seeing where this project goes.

The license for OM is GPL3 with 1 inclusion, the "about box" must be un-modified. This is an interesting extra requirement on top of the already restrictive GPL3, but was probably seen as an acceptable means of protecting authorship. Questions of actual GPL compatibility in the future may arise.

GPL serves to protect the coders. When RoadRunner became RideRunner, because there were no specified license for the core or the plugins, the author was able to close source his code along with everyone else's. This obviously ticked off contributors and coders. GPL protects it's coders by disallowing anyone to close it up. Any modification to the code must be given back to the original coder. GPL keeps open things open, which is also a major benefit to the end-user.

Both projects are accessable vis sourceforge.net. This is a huge advantage for potential contributors. RR never had a public code repository. Code was exchanged in hard to track ways and the maintainer did all the magic of making it work. A public SVN repository begs contributors to "check-me-out" and "hack-on-me".

Conclusion
RevFE is by far the most further along of the two. Although both have the potential to be developed and progressed rapidly, RevFE is usable in the car now. OpenMobile can do things, but not nearly as many *yet* as RevFE. Both however, are leaps and bounds better because of code securing licenses, a modern language, accessible code, and the ability to do rapid development of plugins.

If you want a drop in replacement for RR, RevFE is for you. Malcom2073 is known to prioritize users needs. And because the code is accessible via a code repository, you can get the changes instantly (if you are willing to compile it), rather than waiting for the maintainer to get around to pushing a release.

Appendix
So why didn't I mention LinuxICE or nGhost3 as an alternative to RR? Simply put, they aren't. For one, nGhost doesn't run on Windows. Secondly, the FE's listed above don't diverge very far from the original tree in terms of conception. They do a lot to avoid the same mistakes and are technically superior semantically speaking than RR, but they are still monolithic front ends. nGhost doesn't follow the same pattern and thus isn't a replacement, it's an entirely different experience. nGhost3 tries to more match what the outside market is doing and in some aspects CentraFuse3 is doing the same: that is, creating an application framework for developers. nGhost3 goes even further by allowing out-of-process applications and plugins linked by a communication layer and the OS's window manager. This is a pattern followed also by Nokia, Moblin, and Google on their mobile platforms.

For me, the future of car computing is nGhost3. Just like the future of RR is RevFE.

chunkyks · 10-09-2009, 01:14 PM

The problem with adding restrictions to the GPL is that it means other projects can't take your code and add it to their own. [and the opposite can be problematic too].

Also, unless you get copyright assigned to you by contributors, you need to get their permission to change the license in future; eg, if you wanted to take out the restriction to make your project fully GPL-compatible, you need written permission from each and every nontrivial contributor. PITA

Someone else who tried to change the license on a project [physfs]. Ignore the zlib proselytisng, just look at what needed to be done to get the license changed: Physfs "License Change Proposition"

Pertinent FSF FAQs:
Can I modify the GPL and make a modified license?
What does it mean to say that two licenses are “compatible”?

To be fair, I feel openmobile's modification is well-intentioned, but there is an FAQ on the topic:
I want to get credit for my work. I want people to know what I wrote. Can I still get credit if I use the GPL?
Of course, this doesn't resolve the original intention of having, in essense, a publically-visible CREDITS file in the runtime.

Just a little IANAL-but-I-do-care-about-copyright-and-licensing braindump.

Gary (-;

PS Also, OP actually had it slightly wrong; it's not that the About box must be unodified, it's that it must be easily accessible. So you are allowed to add your own name to it, which is the point.

justchat_1 · 10-09-2009, 03:47 PM

Quote: Originally Posted by chunkyks

The problem with adding restrictions to the GPL is that it means other projects can't take your code and add it to their own. [and the opposite can be problematic too].

Also, unless you get copyright assigned to you by contributors, you need to get their permission to change the license in future; eg, if you wanted to take out the restriction to make your project fully GPL-compatible, you need written permission from each and every nontrivial contributor. PITA

Someone else who tried to change the license on a project [physfs]. Ignore the zlib proselytisng, just look at what needed to be done to get the license changed: Physfs "License Change Proposition"

Pertinent FSF FAQs:
Can I modify the GPL and make a modified license?
What does it mean to say that two licenses are “compatible”?

To be fair, I feel openmobile's modification is well-intentioned, but there is an FAQ on the topic:
I want to get credit for my work. I want people to know what I wrote. Can I still get credit if I use the GPL?
Of course, this doesn't resolve the original intention of having, in essense, a publically-visible CREDITS file in the runtime.

Just a little IANAL-but-I-do-care-about-copyright-and-licensing braindump.

Gary (-;

PS Also, OP actually had it slightly wrong; it's not that the About box must be unodified, it's that it must be easily accessible. So you are allowed to add your own name to it, which is the point.

How bout asking for clarification next time guys

Ok i'll admit the "additional restriction" was badly worded...so here it is in legal speak:

Quote:

The additional restriction is a clarification of Section 5d and Section 7b of the GPL. These terms state that in a program with interactive user interfaces, Appropriate Legal Notices that are included may not be removed in future versions. In the case of Open Mobile - the "About Box" contains the copyright owners and license under which the program is distributed. While the about box itself is not required to be included, its contents the ("Appropriate Legal Notices") are to ensure future versions of the software are not mis-represented.

Not only is that fully compliant with the GPL, it protects future users by ensuring the of the validity of the software they are using.

Now...for some comments on the above writeup:

Skinning:
It would be interesting to note the massive difference between using all native controls and using a hacked together combination of native controls, api calls, flash, and embedding.

Performance:
OpenMobile can also easily be compiled to native code which runs just as fast as c++ (and will do so automatically in the background before we hit version 1.0). I also don't think comparisons between c#'s speed parsing 100,000 strings compared to c++ are really relevant in a FE. Feel free to run those benchmarks for yourself :P.... Additionally, as fast as Qt is its still a large framework/layer of abstraction. Even though c# as a language may be slightly slower, openMobile is still its own graphics engine aka OM->GDI+->video card compared to revFE->qt->openGl->graphics card. (unless I missed something)

The big one:
The only thing I didn't like seeing was the comparison with cf3. Besides the fact that its not even released, finally giving users some amount of external interfacing in no way comes close to what any of the other front-ends do. Not to mention the whole OM is a giant framework for developers-half the wiki is dedicated the different parts.

Quote: Originally Posted by chunkyks

PS Also, OP actually had it slightly wrong; it's not that the About box must be unodified, it's that it must be easily accessible. So you are allowed to add your own name to it, which is the point.

I pretty much covered it all in the above-just wanted to make it clear thats not the point as much as you cant remove open mobiles copyright owners and take credit for writing the app...you are more then welcome to add your name to the list though-if you make changes.

chunkyks · 10-09-2009, 04:10 PM

That's perfectly reasonable. I feel it would be better to clarify that you consider the About box to be "appropriate legal notices" that should be left intact under those sections - rather than calling it an "additional restriction", since it isn't. [Especially since calling it an "additional restriction" carries with it ramifications that you didn't intend]

What would happen if someone took your GPL code and put it in their own app, that didn't have a GUI? Not that I'm planning on it, but hypothetically there might be something fantastically useful in the soon-to-be OBD openmobile plugin that could be useful in obdgpslogger... but obdgpslogger doesn't have a UI.

Gary (-;

malcom2073 · 10-09-2009, 04:19 PM

Quote: Originally Posted by justchat_1

Skinning:
It would be interesting to note the massive difference between using all native controls and using a hacked together combination of native controls, api calls, flash, and embedding.

Please elaborate? Are you saying OM will be better because you're writing everything from scratch rather than using resources already available? (Web browser, flash gauges, etc)?

Quote: Originally Posted by justchat_1

OpenMobile can also easily be compiled to native code which runs just as fast as c++

Please state your sources? afaik this possibility went out with dot net 1.0.

Quote: Originally Posted by justchat_1

Additionally, as fast as Qt is its still a large framework/layer of abstraction. Even though c# as a language may be slightly slower, openMobile is still its own graphics engine aka OM->GDI+->video card compared to revFE->qt->openGl->graphics card. (unless I missed something)

You are close, RevFE->Qt->Winapi(GDI)->Video Card, or on linux RevFE->Qt->Xlib->video card

You are also however, wrong about the Qt thing. Qt is fast because c++ function calls have less overhead and take less time than c# function calls. So c++ can go through multiple levels of abstraction in the time it takes c# to even think about going through one.

There's nothing wrong with using c#, and I truly believe that OpenMobile has great potential. I look forward to seeing it mature. I just hope you do some research into the limitations of c# and figure out ways around them.

kev000 · 10-09-2009, 04:23 PM

Quote: Originally Posted by justchat_1

Skinning:
It would be interesting to note the massive difference between using all native controls and using a hacked together combination of native controls, api calls, flash, and embedding.

Using a unified control framework can be leaps better than using a mix of everything, you are probably correct. That's one more advantage RevFE and OM have over RR.

Quote:

Performance:
OpenMobile can also easily be compiled to native code which runs just as fast as c++ (and will do so automatically in the background before we hit version 1.0). I also don't think comparisons between c#'s speed parsing 100,000 strings compared to c++ are really relevant in a FE. Feel free to run those benchmarks for yourself :P.... Additionally, as fast as Qt is its still a large framework/layer of abstraction. Even though c# as a language may be slightly slower, openMobile is still its own graphics engine aka OM->GDI+->video card compared to revFE->qt->openGl->graphics card. (unless I missed something)

Like I said, to the user, the difference in performance may not be noticed by the end-user. However, you probably benefit greatly from having compiled skins rather than parsing at load time don't you? That's an advantage in your favor, cuz unlike you, RevFE has to parse xml at loadtime. It would be interesting to benchmark this however (compiled vs xml skins...).

RevFE doesn't use an OpenGL backend. It probably looks more like this RevFE->Qt-call->GDI+->GPU while OM probably looks more like this: OM->.NET-call->GDI+->GPU. I could be wrong, but .NET probably wraps the native c/c++ API's for GDI+. But that's completely irrelevant. .NET is just as big a framework as Qt.

Quote:

The big one:
The only thing I didn't like seeing was the comparison with cf3. Besides the fact that its not even released, finally giving users some amount of external interfacing in no way comes close to what any of the other front-ends do. Not to mention the whole OM is a giant framework for developers-half the wiki is dedicated the different parts.

Plugin Framwork != Application framework. I'm really not sure how CF3 is going to do that, or what justifies them calling it an App framework (maybe just clever marketing). It may very well be just the same as OM and RevFE's (and RR's for that matter) plugin frameworks. nGhost3's framework is a true Application framework. Meaning, you can dev a plugin, or an app and maintain the same look, same communication link, and the same behavior as you would expect in order to maintain a consistent look and feel.

Quote:

I pretty much covered it all in the above-just wanted to make it clear thats not the point as much as you cant remove open mobiles copyright owners and take credit for writing the app...you are more then welcome to add your name to the list though-if you make changes.

I think if I were to take your names out of the code and put mine it'd be a copyright violation and fraud which are already protected without any additional terms.

justchat_1 · 10-09-2009, 04:48 PM

Quote: Originally Posted by kev000

RevFE doesn't use an OpenGL backend. It probably looks more like this RevFE->Qt-call->GDI+->GPU while OM probably looks more like this: OM->.NET-call->GDI+->GPU. I could be wrong, but .NET probably wraps the native c/c++ API's for GDI+. But that's completely irrelevant. .NET is just as big a framework as Qt.

Yes if its used... Open Mobile doesn't use anything but the wrapped gdi+ calls...compared to using Qt, along with qt's classes, controls, etc. At least thats the way I saw things...

Quote: Originally Posted by kev000

Plugin Framwork != Application framework. I'm really not sure how CF3 is going to do that, or what justifies them calling it an App framework (maybe just clever marketing). It may very well be just the same as OM and RevFE's (and RR's for that matter) plugin frameworks. nGhost3's framework is a true Application framework. Meaning, you can dev a plugin, or an app and maintain the same look, same communication link, and the same behavior as you would expect in order to maintain a consistent look and feel.

How is that in any way different to OpenMobiles framework? Common control set, common communication link, common (but user configurable) look and feel.
Or are you saying that cf3 is going to allow consistent look and feel between unique applications?

Quote: Originally Posted by kev000

I think if I were to take your names out of the code and put mine it'd be a copyright violation and fraud which are already protected without any additional terms.

Well true...but i've seen developers include copyright info in the source code (available only by request)...and then no copyright info in the gui itself, or have it hidden under so many menus the user can never find it. Users see just the app name and assume they made it themselves.

justchat_1 · 10-09-2009, 05:19 PM

UGH-this stupid forum marking everything read thing is starting to get annoying. Completely missed the middle two posts.

Quote: Originally Posted by malcom2073

Please elaborate? Are you saying OM will be better because you're writing everything from scratch rather than using resources already available? (Web browser, flash gauges, etc)?

Better-no...lighter and faster absolutely yes. In some ways far more capable. You probably noticed the extensive use of alpha blending we do for effects. Not possible when you embed opaque things like flash. I would also argue natively drawn controls not only use less CPU but also look better and a lot more integrated then flash controls. Thats not to say embedding can't be done-i for one don't want to write a web browser from scratch just that it makes a nice difference.

My biggest issue with using native windows controls was the fact that they had 100 properties and 50 methods most of which just ate up memory and slowed things down. Qt is alot better but by trying to cater to "everything" they still end up being a lot more bloated then something written from scratch.

Quote: Originally Posted by malcom2073

Please state your sources? afaik this possibility went out with dot net 1.0.

On mono its the AOT command, on windows its the ngen utility. Both compile to native code for the platform your running on-and support the full set of optimizations.

Quote: Originally Posted by malcom2073

You are close, RevFE->Qt->Winapi(GDI)->Video Card, or on linux RevFE->Qt->Xlib->video card

You are also however, wrong about the Qt thing. Qt is fast because c++ function calls have less overhead and take less time than c# function calls. So c++ can go through multiple levels of abstraction in the time it takes c# to even think about going through one.

3/4 - i guess thats a C for me lol i would argue that while c++ has far less overhead, creating bloated controls in c++ compared to creating slim controls in c# could be pretty close depending on how big the difference was.

Quote: Originally Posted by malcom2073

There's nothing wrong with using c#, and I truly believe that OpenMobile has great potential. I look forward to seeing it mature. I just hope you do some research into the limitations of c# and figure out ways around them.

So far so good... I also think revFE has some great potential-in fact its been inspiration for how openMobile does a few things. Scrolling lists in OM didn't just get inspiration from the iPhone

malcom2073 · 10-09-2009, 05:39 PM

I stand corrected about the native compiling. I'd be interested to see some benchmarks comparative to equivalant c++ programs.

Quote: Originally Posted by justchat_1

i would argue that while c++ has far less overhead, creating bloated controls in c++ compared to creating slim controls in c# could be pretty close depending on how big the difference was.

Perhaps you're mistaking small exe size, with small code? Sure your c# code for a control is much smaller, but the .net backend powering that tiny snippet of c# code is huge.

Quote: Originally Posted by justchat_1

So far so good... I also think revFE has some great potential-in fact its been inspiration for how openMobile does a few things. Scrolling lists in OM didn't just get inspiration from the iPhone

Cool

justchat_1 · 10-09-2009, 06:05 PM

Quote: Originally Posted by malcom2073

Perhaps you're mistaking small exe size, with small code? Sure your c# code for a control is much smaller, but the .net backend powering that tiny snippet of c# code is huge.

Not at all... most of the giant back end only comes into play if its used. I've actually done the trace - its 3 cpu instructions and an api call. But back to my point-if you create a control with 50 properties i don't care what language that is - it takes time to allocate memory for all that. It doesn't matter if c++ can do xyz 10x faster then another language...if it does it 100 times more its going to be slower

I haven't looked into qt in awhile but a quick google search gave me this (tell me if im off):
A QTAbstractButton contains 68 properties, 250 functions, and 6 signals. The more specific classes are a little slimmer but thats still ALOT. All of the values need space allocated and deallocated in memory, many of those values need to be checked or manipulated during rendering, and i started with the simple controls.

malcom2073 · 10-09-2009, 06:10 PM

Quote: Originally Posted by justchat_1

Not at all... most of the giant back end only comes into play if its used. I've actually done the trace - its 3 cpu instructions and an api call. But back to my point-if you create a control with 50 properties i don't care what language that is - it takes time to allocate memory for all that. It doesn't matter if c++ can do xyz 10x faster then another language...if it does it 100 times more its going to be slower

I haven't looked into qt in awhile but a quick google search gave me this (tell me if im off):
A QTAbstractButton contains 68 properties, 250 functions, and 6 signals. The more specific classes are a little slimmer but thats still ALOT. All of the values need space allocated and deallocated in memory, many of those values need to be checked or manipulated during rendering, and i started with the simple controls.

You aren't seriously trying to argue that c# using winforms is faster than c++ using Qt are you?

chunkyks · 10-09-2009, 06:22 PM

Ah, language-baiting. How I miss the days when it was completely clear cut [old-time java can suck my balls], although I notice that the arguments haven't actually changed.

I just want to throw in that comparing C# the language/CLR to Qt is like comparing C to openGL.

For want of an apples-to-apples comparison, it might be wiser to go with "the C# interface to winforms vs Qt". And it's my limited understanding that in that realm, Qt crushes C#/winforms performance. Of course, the case now as it was then is that the glue layer is sufficiently skinny that it's *all* about the other stuff you do rather than the cost of one extra function call.

Also, sixty eight properties is a pretty good approximation of zero in terms of memory needed. I would go so far as to point out that the winforms button is on an equal footing

Gary (-;

justchat_1 · 10-09-2009, 08:45 PM

Quote: Originally Posted by malcom2073

You aren't seriously trying to argue that c# using winforms is faster than c++ using Qt are you?

No im saying a language is only as fast as the code its executing... no ones arguing that c++ is much faster especially qt....i'm only saying that bloated c++ can be slower then very slim c#.

Quote: Originally Posted by chunkyks

Ah, language-baiting. How I miss the days when it was completely clear cut [old-time java can suck my balls], although I notice that the arguments haven't actually changed.

I just want to throw in that comparing C# the language/CLR to Qt is like comparing C to openGL.

For want of an apples-to-apples comparison, it might be wiser to go with "the C# interface to winforms vs Qt". And it's my limited understanding that in that realm, Qt crushes C#/winforms performance. Of course, the case now as it was then is that the glue layer is sufficiently skinny that it's *all* about the other stuff you do rather than the cost of one extra function call.

Also, sixty eight properties is a pretty good approximation of zero in terms of memory needed. I would go so far as to point out that the winforms button is on an equal footing

Gary (-;

The winforms button is far slower ->but openmobile doesn't use winforms it uses straight GDI+. My argument was that even going through the .net overhead, straight gdi+ calls were faster then creating and manipulating bloated controls in qt, along with bloated paint functions.

Once I can figure out a good way to test AOT compiled c# against c++ i might be so bold as to say we easily have qt beat-but for now im gonna pick my battles

malcom2073 · 10-09-2009, 09:05 PM

Quote: Originally Posted by justchat_1

Once I can figure out a good way to test AOT compiled c# against c++ i might be so bold as to say we easily have qt beat-but for now im gonna pick my battles

I would be quite interested in seeing this. Having performed benchmarks previously between c# and c++, I don't see AOT giving it that huge of a boost, but I can admit I'm wrong.

kev000 · 10-11-2009, 03:13 AM

I just got back from the Utah Open Source Conference and have some additional incite on this subject. The keynote was done by a representative from Adobe. He talked about the implications of open sourcing applications. Adobe's strategy is currently: open source the tools and apps that you can. Adobe has discovered, like many others, that even though Open Sourcing apps costs more than keeping it closed, benefits such as goodwill, community, and evangelism are enough to offset the costs of opening it. It's not enough to give away stuff for free, it's got to be open.

RideRunner probably isn't going away soon. I do not wish to imply that it will. RoadRunner however, as it was known as the community developed Open Source application, is dead to many forum members.

I didn't want this to turn into a language battle. When I started coding nGhost, it was a mere experiment. Even though it was written in a modern language, it quickly fell into a state where it was cumbersome to add new features because of my immature coding style at that time. As applications grow larger, the more likely this is to happen. They quickly become difficult to manage beasts. Because of this, I rewrote nGhost from scratch (nGhost2) and now I'm writing it again (ng3) this time with a better design with scalability in mind and more planning.

Some feel that RoadRunner has become that unmanageable beast. Some feel that using a modern language with improved scalability in mind can produce a better FE. Some feel that open source is more than just free software: it's a responsibility. This post discusses two such projects that plan on doing just that.

User Name		Remember Me?
Password