YOUR dream front end

**iamgnat** · 02-12-2008, 09:30 AM

Originally Posted by Jirka Jirout

- Modular architecture with the option of adding plug-ins, ideally with "safe mode" where only modules with some sort of certification would work. The architecture should also create a very secure sandbox so a module cannot crash the application if an error occurs.

I agree with the later, but not with the former. That is one of the reasons I have left Nokia and am still holding out to see what the SDK/publishing approach to the iPhone will be before I get a new phone (got I hate this Moto POS

). I have no problem with the hardware/software developer saying "that is not a supported addition, you need to reset to factory defaults before we will help", but I have a big problem with them trying to tell me what I can and can't do with it.

I understand the idea of the user being able to have more confidence in it, I just don't buy into it.

- Coherent GUI, designed primarily for ease of use. No crappy animations and stuff that only distracts the user.

Absolutely. That is the main thing I hate about after market head units that finally pushed me to using a Mac to essentially do the same thing.

- Full support of speech synthesis for reading the GUI (on request or after a short delay) as well as data and warnings.

As long as you can turn that off. Nothing is more annoying to me than a computer trying to talk to me....

Look at iPhone+Mac and Windows XP/Vista + Windows mobile. Apple did design a very different GUI while Microsoft tries to stick with the concepts from the desktop (menus, design of particular widgets).

See, to me the iPhone has a very Mac like UI. So do the non-touch iPods (at least the early models, the 4G+ have gotten kinda cluttered) actually. The Mac like feel is more than just the UI elements themselves, it is how the device operates as a whole. Simply put the, can you just start the App and intuitively understand how to do what you need to accomplish? While Apple isn't the only one that can write good applications like that, that is what they've based their whole OS on.

Originally Posted by NeonDev

Judging by the way this thread has veered towards the look of Front Ends I'd have to say that must be a very important feature in the "dream FE" indeed.

Absolutely. Take your own opinion that you expressed earlier. If it didn't fit in with how you want your car to look, would you use it?

Please tell me there is more to it than the shape of buttons.

Of course there is. It was an example. The UI elements are typically the easiest way to express the underlying OS, but far from the only way.

If NBB looks neither Mac nor Windows like then we accomplished our goal I think

And if you like it, more power to you and it. I have given Jirka a hard time about his UI for a long time, but that doesn't mean I respect his work or the App any less. It just means that it doesn't have one of my key requirements for the "ideal" front end.

Ha ha no offense to anyone but I want to stay as far away from the Apple of the 80's and 90s as possible. I wasn't a Mac user till OS X came about but the only similarities I see are the menu bar and the location of the window close widget. No "aesthetics" seem to have been taken at all (thank god)

I wasn't a big user, but I used them enough to be familiar. There are actually a lot of hold overs from the first versions of Mac OS, most people just don't understand/see it because it is the type of stuff you never think about. It's seemingly little things like how far apart UI elements should be spaces and how tall buttons are supposed to be, etc.. It's the little things like that that give you a nice consistent UI. Sure it has changed over the years, but for the most part it has been little tweaks and refinements vs whole sale changes.

Now the OS on the other hand, yes there are few similarities to the old Mac OS which I agree is a good thing.

Neon Boom Box is just two people trying to bring one more choice to the mac users. We hope they appreciate it no matter how they feel about the way it looks ;-)

I certainly do. It would be nice if we could ban together to have a large group of developers focus on a single project, but in as small a community as we have that just isn't going to happen.

that is a wonderful point. the iPhone not only looks different but interacting with it is totally different.

Is it really that different? You have a different tool to interact with it, but now the track pad on the Air gives you similar (though not touching the screen itself) functionality in the "real" OSX.

-dave

**iamgnat** · 02-12-2008, 09:37 AM

Originally Posted by VmtSquad

could we get a version for linux ?

Originally Posted by Cybix

there ya go Neon, your front end is sparking interest even with the non-mac mob! Linux version I would doubt... no cocoa in Linux... ?

Actually, it is very possible. I have looked into doing it with CFE, but there are some Mac specific functions I call (generating the gradients on the buttons and using iTunes as the music player) that I would have to over come first.

There is an open source version of NextStep (the basis of Cocoa) called GNUStep. Except for the name and functionality that they haven't caught up with yet, it is almost identical to Cocoa down to using the same Object and method names.

It is supposed to be simple (assuming you aren't using any Mac specific function calls) to build your App for Cocoa, then build it for GNUStep. I haven't tried it though so I don't know anymore than that.

I will say that GNUStep is a great resource when you are sub-classing something like NSButton or other UI elements. Apples documentation leaves a lot to be desired when you are getting down to overriding how the graphics are generated and being able to look at the GNUStep source is a huge resource.

-dave

**reece146** · 02-12-2008, 10:05 AM

I am firmly in the Jirka/NBB camp.

I don't want it to look like OSX necessarily. It might be ok to have some OSX characteristics (button shapes perhaps) but not look like an OSX application is ideal.

Why? Because on a ~7"-9" touch screen I can't see it working very well without a stylus. Sure, you can increase button sizes but then you have things that look awkward because they weren't styled to be displayed at that size.

What it needs to be:

1.) Usable! I don't want to have to keep my eyes on the screen to get the major functions done. It has to be as easy to use as the major manufacturer's systems. I see some of the custom themes that are posted on this site and just shiver with horror at how ugly and unusable they are. Sure, they look cool - for about 30 seconds when you start.

2.) Professional looking. Like the interface to OSX (jury out if applies to Leopard) less truly is more. I don't want lots of eye candy. I want function and something that I won't tire looking at. If it is all blinged up I guarantee after a few days it is going to look lame/ghey.

Some more thoughts:

1.) Touchscreen should be the primary interface. Alternatively, IF a knob type interface can get the job done in lieu of the touch screen I am ok with that. It has to be able to do everything though. I've never used iDrive on the BMWs so I am not certain how they work. I hear that the MB system is nicer though and that BMW has started copying some of the usability stuff from MB. Just what I've heard, haven't used either. Maybe your graphics arts guy needs to go for a "test drive" in both.

2.) Modular would be ideal. If I can integrate gpsdrive into the setup I would be a happy guy.

There's some other stuff I am forgetting.

**NeonBoomBox** · 02-12-2008, 10:29 AM

Originally Posted by iamgnat

Is it really that different? You have a different tool to interact with it, but now the track pad on the Air gives you similar (though not touching the screen itself) functionality in the "real" OSX.

It is actually.

as os x was not designed for multi touch all the new track pad does is provide a novel way of controlling functions that can be done just as easy with a mouse, button or slider which is not a ground breaking way to navigate the os. The iPhone on the other hand was designed from the ground up to use multi-touch. If you were to try and use a mouse with it it would hinder the navigating speed. And as for UI differences, If you were to compare a screenshot of os x UI and the iPhone UI the only similarities would be the look of some of the icons. Thats it.

So IMVHO i believe they are really QUITE different as they are two completely different devices with completely different purposes that have completely different UIs

**NeonDev** · 02-12-2008, 10:45 AM

Originally Posted by iamgnat

Actually, it is very possible. I have looked into doing it with CFE, but there are some Mac specific functions I call (generating the gradients on the buttons and using iTunes as the music player) that I would have to over come first.

There is an open source version of NextStep (the basis of Cocoa) called GNUStep. Except for the name and functionality that they haven't caught up with yet, it is almost identical to Cocoa down to using the same Object and method names.

It is supposed to be simple (assuming you aren't using any Mac specific function calls) to build your App for Cocoa, then build it for GNUStep. I haven't tried it though so I don't know anymore than that.

I will say that GNUStep is a great resource when you are sub-classing something like NSButton or other UI elements. Apples documentation leaves a lot to be desired when you are getting down to overriding how the graphics are generated and being able to look at the GNUStep source is a huge resource.

-dave

unfortunately GNUStep wont support a HUGE chunk of the code I execute (hell NBB won't even run under tiger without some modification). I am not sure about Car Front End but judging by use it uses apple events to control itunes which I doubt are supported in any way (aside from the obvious lack of linux itunes, which is a problem for me as well since NBB uses the itunes library).

here is the short list of why it wont be done:
No CoreAnimation(could get around if I needed to)
No CoreImage (pretty sure GNUStep doesn't support it and I make hefty use of it)
Apple Events (once again could get around it if i were inclined)
No IOKit (I don't use this yet but I will)
and the big tamale is No Quick Time framework thats the real killer right there I make vast use of it

sure you could prolly port most of the cocoa with little modification, assumind GNUstep supports the bundle structure of os x apps including NIB files), but all those other parts of the app would have to be completely rewritten to use other frameworks.

im sure there are equivalents in linux but I for one don't have the time or the drive to learn all new frameworks without compensation. Car front end would likely be alot easier to port

**iamgnat** · 02-12-2008, 11:06 AM

Originally Posted by NeonDev

here is the short list of why it wont be done:

These are all things that could (easily in some cases, painfully in others) be gotten around. My point wasn't that you should, but that you could.

Like I said, I looked into it for CFE but haven't pursued it as I would have to build a fully fledged Music player to replace my iTunes "skin" and have to find a Unix alternative to the CoreGraphics calls I use on my buttons.

Nothing too painful, but for both CFE and NBB that time would be better spent focusing on addressing the issues on their target platform and adding new features.

sure you could prolly port most of the cocoa with little modification, assumind GNUstep supports the bundle structure of os x apps including NIB files), but all those other parts of the app would have to be completely rewritten to use other frameworks.

it supports the older NIBs (not the new IB 3 NIBs or XIBs), though I haven't looked into it enough to see what it does about bundles since that is not a very Unix like structure.

From the code trolling I did back in Oct/Nov, GNUStep was as complete as all the frameworks that make up Cocoa in 10.4. It did not support the new 10.5 functionality (HUD views and such), but i'm sure it will be along shortly if it isn't already added.

Where it lacks is any of the lower level frameworks (like QT and IOKit), but those aren't actually part of Cocoa anyway.

im sure there are equivalents in linux but I for one don't have the time or the drive to learn all new frameworks without compensation. Car front end would likely be alot easier to port

As I said above, I agree completely. Focus the time where it is most effective (the Mac product) rather than diluting the product in such a way that everyone suffers.

The biggest issue with CFE as it stands right now is it's dependance on the iTunes app. I want to build a standalone music player at some point, but right now it works good enough so I can focus on other areas.

I'm not advocating that any of the 3 current projects should start supporting a Linux build, but it is something to keep in mind as we design and add new features. We never know where the long road of the future may take us

-dave

**iamgnat** · 02-12-2008, 11:33 AM

Originally Posted by NeonBoomBox

It is actually.

Actually, it's not which is part of it's elegance.

Both said by Apple early on and proven later on when they were hacked, the iPhone runs a slimmed down version of OSX and uses Cocoa for it's UI development. They are the same with a different skin. The iPhone has a UI that has very tight connections to Dashboard, FrontRow, and the AppleTV. None of them are exactly identical, but if you could find someone that had never seen or heard of an Apple product and put all of them next to each other I think you would find that they would recognize the UI similarities pretty quickly.

The iPhone on the other hand was designed from the ground up to use multi-touch. If you were to try and use a mouse with it it would hinder the navigating speed.

I'm curious what you think is designed around using multi-touch and would be hindered by using a mouse? The only thing i've seen the multi-touch used for that a mouse couldn't easily do is zooming (and actually ctrl+scroll wheel accomplishes that). Everything else is the same point and click approach that Apple and Microsoft have been doing since the first versions of Mac and Windows.

With very little coding and some simple hardware, you could even make your screen change it's orientation as you rolled your car over (I wouldn't want to beta test that for you though

).

Don't get me wrong, i'm impressed with the iPhone and how they have packaged all it's features. But I don't think it is the Jesus phone that many believe. With the exception of the multi-touch (which at least right now is still just useful for zooming) everything the phone can do has been done plenty of times over by many other phones. Like everything else though, Apple knows how to package it all up in such a way that it looks fresh and is easy to use which is in essence the true Apple "look & feel".

And as for UI differences, If you were to compare a screenshot of os x UI and the iPhone UI the only similarities would be the look of some of the icons. Thats it.

Mail is similar enough to Mail.app that it is easy to start using if you already use Mail.app.
Safari is essentially the same as it's OSX sibling without tab support (speaking of UI features, not missing plugins like Java and Flash).

The look and feel is more than just the static look of something. It is also about how it is used and how it functions. In that regard, I am not implying anything about NBB as I have not used it to know (sorry, but the graphics turn me off enough to keep me from loading it), just trying to describe what that ideal l&f is to me.

So IMVHO

As my feelings are mine

I guess for me I don't look at form vs function, but at how both interact with one another. That is the consistent thing that drives my passion for Apple products (except for their Pro software line, good god FCPs UI is a royal PITA!!!

).

-dave

**Jirka Jirout** · 02-12-2008, 11:41 AM

Originally Posted by iamgnat

I have no problem with the hardware/software developer saying "that is not a supported addition, you need to reset to factory defaults before we will help", but I have a big problem with them trying to tell me what I can and can't do with it.

Ups, maybe I was not clear. What we have in QCar is one simple setting named AllowForeignModules. If this is set to NO (by default), QCar will skip all non-Q-Branch modules that may be installed. The user can set it to YES and from this moment, QCar loads all plug-ins. But there is no free support for QCar running with 3rd party plug-ins.

Nothing is more annoying to me than a computer trying to talk to me....

Really? I thought you were married :-D Right now, my daughter starts to take over from my wife: "Daddy, was that not a 50 km/h limit board over there?!" Way more annoying than any computer.

The Mac like feel is more than just the UI elements themselves, it is how the device operates as a whole. Simply put the, can you just start the App and intuitively understand how to do what you need to accomplish?

True, but for how long have you been working with the computers? The car GUIs are still very young in comparison, so that the intuition you mention is still not quite there.

I certainly do. It would be nice if we could ban together to have a large group of developers focus on a single project, but in as small a community as we have that just isn't going to happen.

Well, merging all effort into one project is probably unrealistic, but we can certainly consider releasing some frameworks and code for use in other projects.

**Jirka Jirout** · 02-12-2008, 11:49 AM

Originally Posted by iamgnat

From the code trolling I did back in Oct/Nov, GNUStep was as complete as all the frameworks that make up Cocoa in 10.4. It did not support the new 10.5 functionality (HUD views and such), but i'm sure it will be along shortly if it isn't already added.

Bindings? KVO? We have last looked at GNUStep last summer and the conclusion was that it would be too much work to port it just for the fun of it. We still keep this door open though, just in case Apple decides to scrap the mini and we would have to switch hardware :-)

**iamgnat** · 02-12-2008, 12:06 PM

Originally Posted by Jirka Jirout

Ups, maybe I was not clear. What we have in QCar is one simple setting named AllowForeignModules. If this is set to NO (by default), QCar will skip all non-Q-Branch modules that may be installed. The user can set it to YES and from this moment, QCar loads all plug-ins. But there is no free support for QCar running with 3rd party plug-ins.

That sounds about as close as you can get to the best of both worlds. Great idea.

Really? I thought you were married :-D Right now, my daughter starts to take over from my wife: "Daddy, was that not a 50 km/h limit board over there?!" Way more annoying than any computer.

It's the wife that drives the BMW and 911, I just drive my Escape

Though there is a reason that we both drive with radar detectors

True, but for how long have you been working with the computers? The car GUIs are still very young in comparison, so that the intuition you mention is still not quite there.

I agree which is why I didn't spend half the cost (or much less depending on features) with a off the shelf in car system. Why they have to go for glitz and pretty lights instead of making things simple and easy to use is beyond me. The biggest gripe I had with my old Alpine was the simple fact that there was no way to see my track information AND the time (clock, not track) at the same time. God forbid I would like to look over and see both bits of information....

Well, merging all effort into one project is probably unrealistic, but we can certainly consider releasing some frameworks and code for use in other projects.

There are many reasons it's not practical, our differing views on things like the UI is just the easy one to see

It is one of the reasons that I went OSS with CFE though. If someone else wants to join the project, they are welcome. If they just want to steal the code for their own project, they are welcome as well.

-dave