Thread: The RR Replacements.

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 (-;

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#.

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

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.

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.

Originally Posted by Vinister

Just want to throw something out there:

I just got a palm pre. I tell you if I could triple the size of the screen it would be the best car-pc I have ever seen or used. I've been in the carpc game since the beginning and we've never gotten near the use-ability of this device.

If we could somehow emulate the software and hardware control of this thing, we'd be light years beyond RR. The Pre uses Web-OS, which I don't know alot about except it seems ridiculously easy to code for. Apps are coming by the dozen daily. It has been completely hacked and there are hundreds of home-brew apps, a kind of testing ground for new apps, and Palm seems to be letting it all happen.

- WIFI, GPS, EV-DO, Bluetooth, multi-touch... more than I've got and tons of work on a carpc
- Google maps integration, even satellite and street views (turn-by-turn street-view GPS app is in the works... can you imagine?!?)
- Good Media Players (Great ones coming soon)
- tethering for wifi'ing your ev-do
- oh yeah, its a phone too


I just can't stress how much better of a carpc this thing would be than my carpc. The ability to click on addresses anywhere (calendar, email, text, web, anywhere) and map it instantly is priceless. You never have to type in addresses manually. the whole thing is fully synced with your gmail, facebook, and outlook accounts, so you never have to actually enter any of it in.

This is how I want my carpc to behave. I think its even faster than my good ol' celeron car pc. How do we get from here to there?

There is an Emulator but it is just to test software, it has no actual hardware functions (of course). Maybe we could look at Web-OS as a carpc OS so it would be easier to develop for. Maybe we could actually Emulate the pre on a regular pc using the pc's existing hardware (not likely). Or maybe control the pre's actual hardware from a larger, touch screen interface. I doubt any of it is possible... but its something to think about.

I don't think the carpc user base is near big enough to support a proper OS that is able to stick with the times. Maybe if we merge with a community that is big enough, such as a smart-phone OS (android even?), we could reap many benefits.

Hehe, I just gave a presentation on why Android/moblin/webOS won't work in the car environment -at least as is. But you are exactly right. I believe that the frontend paradigm needs to die. No one else in the mobile industry is using it, why are we? Everyone else uses framework + apps, NOT monolithic FR + plugins. I believe LinuxICE has the potential to be a WebOS-like OS (both are linux based), but I'm just dreaming. I can't even convince a large junk of the community here to use it/develop for it.

Smartphone communities are easy to grow. You traditionally buy a device that has no installation requirements unlike the carpc. An OS for the car is much more difficult to grow because either people are hardcore windows guys, don't want to learn anything new (I don't blame them, the carpc hobby is too time-consuming as is), or just happy with RR and XP.

Originally Posted by kev000

I believe that the frontend paradigm needs to die. No one else in the mobile industry is using it, why are we? Everyone else uses framework + apps, NOT monolithic FR + plugins.

There's a reason why smart phones are harder to use in cars than say, an older phone. My old phone (which followed a monolithic style UI) was a lot easier to use without looking. It had a decent number of features, and yet still was very easy to use in vehicle because I didn't have to take my eyes off the road to figure out where icons were. My new phone which is a smart phone, is impossible to use without looking at it. Why? They switched from monolithic to framework+apps. It makes it harder to find what you want and launch it since things aren't menu based as much any more. Sure you can expand and add applications, but the ease of use factor has gone way down.

Everyone is going to the framework approach because it eases development of applications while allowing great expandability at the expense of this ease of use. Ease of use is cheap, while ease of development is priceless. IMO that's not a good thing for a carpc, but perhaps that's just me; I'm simple like that

Originally Posted by malcom2073

There's a reason why smart phones are harder to use in cars than say, an older phone. My old phone (which followed a monolithic style UI) was a lot easier to use without looking. It had a decent number of features, and yet still was very easy to use in vehicle because I didn't have to take my eyes off the road to figure out where icons were. My new phone which is a smart phone, is impossible to use without looking at it. Why? They switched from monolithic to framework+apps. It makes it harder to find what you want and launch it since things aren't menu based as much any more. Sure you can expand and add applications, but the ease of use factor has gone way down.

Everyone is going to the framework approach because it eases development of applications while allowing great expandability at the expense of this ease of use. Ease of use is cheap, while ease of development is priceless. IMO that's not a good thing for a carpc, but perhaps that's just me; I'm simple like that

I think what you are talking about is UI design issues: static vs. dynamic menus (menu - meaning any list of items that i choose something from). It has nothing to do with the underlying paradigm. A monolithic FE with dynamic UI that shows all the plugins is just as bad as an App based system with dynamic UI that shows all the apps. If you have a menu where users can easily memorize which button does what, it doesn't matter if the button launches an in-process plugin, or an out-of-process app, it's all the same to the end user: the button does what they expected it to do.

The benefits to me with the app system isn't scalability/expandability at all. A plugin model can be just as expandable if designed right. It's stability and the reuse of code. In an app design, I don't have to write any window manager code i let the existing window manager worry about window order and focus. That makes my life as a dev easier. It also takes advantage of multi-core systems without having to worry about all the caveats of threading.

Just to chime in here, I agree that the FE approach is too customized or purpose built and the framework approach is the right way to go.

However, I'm a little disappointed that the community doesn't seem to be able to break its focus on the car PC device and step back to think about the car PC experience. We seem to keep inventing new ways to do the same stuff - music, nav, video, etc.

Don't get me wrong, I'm a great admirer of the innovation and coding/hacking skills in this community. But again, I'm a little disappointed in the device focus rather than reconsidering the full car computing experience.

I guess this is understandable given that the hardware was the original challenge. Devices back then were not networked and the challenge was getting a system to operate in a stable and reliable fashion. Network connectivity in those days was spotty even in the home.

But that has changed and will continue to change. Mobile net access is cheaper, faster, and more available than ever before. That will continue for the forseeable future. Yet we continue to focus on cramming all of the functionality we need into a single device.

There are some things our PC's do quite well such as playing back music. There are other things they don't do as well such as providing unlimited and up to date storage or providing us with the capability to find and avoid traffic jams.

Why we aren't experimenting with using the network to run applications that provide us with dynamic and up to date information that makes it easier to operate a vehicle, I don't understand. Moving much of our applications and processing to the net reduces the configuration headaches and makes it more available.

Yet there is hope. I don't see why nGhost or Linux ICE couldn't evolve into networked applications with parts on your in car device and other parts on the network, operating as an integrated whole. Stuff inside your car gets controlled by the device or devices in your car. Stuff on the net gets processed on the net until it makes more sense for it to be in your car.

</soapbox>