Front End Challange! - Page 2

Qbancash · 08-12-2005, 09:11 AM

Quote: Originally Posted by jdkarr01

OK so lets forget the politics and competition. If people for some reason like windows then good for them. Windows still has a lot of catching up to do but isnt necessarily terrible if you dont go online with it and aren't trying to do too much. The point being to each his own. Lets get to teh point and that is we need a front end. I will be more than happy to work with anyone I can. Noodles what language are you using. I would love to be able to help you and my brother can help to. I know some people in a development group at the University of Illinois where I go that do mac dev stuff. I will push the idea to them and if they seem to be interested I will get you guys to push them a little. Forget who is better and lets just make something good.

THATS THEWAY TO GO!! Good spirit and if you know the stuff, work together...

::JP

RoyN · 08-12-2005, 09:20 AM

As always I will suggest features that would be useful to me (and consequently others)

Full steam ahead! I hate mac, I hate windows, I hate computers (j/k) but I like choice!

SEGgeek · 08-12-2005, 01:01 PM

Amen Brother!

Jonathan

Wiredwrx · 08-12-2005, 01:13 PM

Quote: Originally Posted by noodles

And what exactly are you doing in this forum? Keeping an eye on the competition?

Not necessarily the competition. Staying informed. For whatever reason, MAC guys have a very elitist mentality. That MAC is better then everything else, and that Windows is really Winblows.

Truth be told, I could care less. But it seems that every chance the MAC guy has to rag on Windows, they do so. I was pointing out how silly the elitist statements were, because in fact, when it comes to FEs in particular, MAC is way behind.

You guys deserve a Front End. There is no reason why you shouldn't have one. Not because MAC is better, but because MAC exists.

Michael

Program on MAC lovers

SEGgeek · 08-12-2005, 01:27 PM

Can we keep the Mac vs Windows issue away here, and keep our eye on the prize?

huh?

Jonathan

jdkarr01 · 08-12-2005, 02:44 PM

Agreed. It doesnt matter which is better if we don't have a front end. Right now I'm working on converting iKarr to Objective-C(which I don't know very well). That should give us a pretty sturdy cocoa app. If anyone wants to help or wants help let me know. My brother and I will help or you can help us. I figure iTunes is what we need first(or at least some sort of mp3 program) then video is next then maybe bluetooth. Lets also work on getting a company to do mac gps with turn by turn. If we petition the right places they may help. Any positive ideas please post here. If someone wants to be in charge then lets elect someone. Heck I can organize it. We can assign people tasks based on what they have and can do. Any other ideas let me know

SEGgeek · 08-12-2005, 05:04 PM

BTW: I am SERIOUS about the cash reward, MP3car Can set up a paypal account if there interested in doing this.

Jonathan

jdkarr01 · 08-12-2005, 07:24 PM

I talked to the head of the mac group at school and they may be interested in at least helping or they may make it a project which would be great. I know there was some talk about GPS at some point with a British group call Navigator. Does anyone know any more about this? I talked to a guy about OBDII connection for the mac. If anyone else wants to send him an email I can look up the info. Also if people have a list of specific details they want or would like go ahead and post might give someone some ideas. Keep it all coming guys!!!

RoyN · 08-12-2005, 08:35 PM

I think OBD should be relarively simple.... unlike GPS you dont really need anything special for OBD... as long as you have a serial reader (with a serial/usb for macmini interfacing) you can just access the serial port and send text commads to the ECU and recieve and interpret the data easily...

OBD is basically a polling system, so your app needs to send a command to the ECU, and then listen for a reply. This is fairly well documented as a protocol and should be a pretty trivial job... (in terms, cause then you get to the multi-interface support problems, skinning problems, gauges and so forth... but using an ELM based device shouldnt be difficult to get something out the door relatively quickly)

SEGgeek · 08-13-2005, 12:39 PM

Well, I have been playing around with designing a front end.
And I have stumbled on using Microsoft POWERPOINT to create a custom front end.
It DOES everything in scriptable and hyperlinkable programs.

this MAY be a GREAT solution till someone comes out with something 'slicker'

Jonathan

jdkarr01 · 08-13-2005, 01:44 PM

What my brother and I have done and could do in applescript is probably much better than powerpoint. Thats also just a temporary solution but go for it if you can get something working

milkhead · 08-14-2005, 01:18 AM

You guys are missing the main point behind a Mac environment as opposed to a PC environment... The ability to use the stability of OSX, native quartz effects of the Mac, and the defacto carputer standard that is the Mac Mini to really make a slick, functional, stable application. As far as features in the automotive environment goes, and no one is a bigger fan of the mac than me, the PC is going to win out because of the wealth of GPS Navigation software. That being said, it doesn't mean that the Mac isnt a worthwhile platform to use. The mac is perfectly suited for the automotive environment, you just have to play up its strong suits and most of all, really give it that cool factor.

None of these easy solutions like using powerpoint, applescript, etc. are going to end up with a decent product. The main problem with, and the reason people keep trying to come up with new Mac front ends, is because all of those already out there are ugly, only work half the time, and are in permanent beta mode.

In order for the mac to be worth while in an automotive environment it needs to be based on asthetics, funtionality, and reliability. The same principles that Apple has focused on since its inception. Here is a little interface example i created a few months ago...

Now this is only a couple of screens of a fictional program. But I could see something visually excting like this, in cooperation with some cool quartz effects and intuitive navigation being a real winner as far as a front end goes. Don't focus on things like petioning companies to come up with navigation software and tangents like that... visualize the design of a front end as if the mac mini is just a really really powerful head unit. Start by creating a program that does three or four things through a really intuitive and visually exciting interface. Program it in a real programming language, use some cool effects, and opensource it so people can work their own magic. Focus on that for the first leap.

avidan · 08-14-2005, 04:13 AM

hi everyone. its good to see some sincere discussion going on related to the mac front end projects in development. I am a *nix developer, and got started on my Mac about 2 years through ADC. Apple provided me with a top of the line machine, but since it was given to me based on the financial server apps i was developing for BSD, I have always used the command line compilers/environments on my mac (perl, java, python, c, etc)
I have spent about 6 months planning a PC carputer, as i still maintain 200+ windows machines...or at least my employees do

Lets just say, my desire to keep windows out of my home has extended to my car. The mini is connected to a lilliput in a custom bezel, and my P1900 arrives on tuesday.
So, the development begins. I am happy to join the developers, and devote as much of my skills as possible. I am begining to feel that Obj-C is going to be the language of choice, so ill go grab a book tomorrow.
Has anyone thought about the possibility of a highly customized set of dashboard widgets? This would give us all the free enhancements that will come with apple upgrading dashboard, and a HUGE group of developers...what are the downsides to dashboard?
I think it might be time to create a forum thread dedicated to pooling development efforts in the Mac car community.
I must say, the nicest thing about the Mac development community right now is the affinity for OPEN SOURCE!
Lets keep source open, and a project will never die!

I'll go ahead and start the new thread....

Jirka Jirout · 08-14-2005, 07:48 AM

Quote: Originally Posted by avidan

Has anyone thought about the possibility of a highly customized set of dashboard widgets? This would give us all the free enhancements that will come with apple upgrading dashboard, and a HUGE group of developers...

I already have a basic implementation of the dashboard widgets support and I can see several important issues, which to me indicate this is not the way to go (although I do see the advantages as well)

Quote:

what are the downsides to dashboard?

1. While you can use WebKit (WebView to be exact) to view dashboard widgets, it seems impossible to keep the preferences of the widgets between the app launches. Every time you open the application and load the widget, a new instance of the widget with default settings is created. I suppose that the Dashboard application is somehow providing mechanisms to archive/unarchive the widget instances, including their settings, but so far I do not know how it is doing that.
2. You depend on touchscreen or mouse/keyboard emulation for control. I do not see an easy way of hooking the widget controls up to some other interface (like my PowerMate or joysticks some other people are using).
3. Widgets are mostly bloody slow and inefficient

Mahalis · 08-14-2005, 11:00 AM

Quote: Originally Posted by Jirka Jirout

1. While you can use WebKit (WebView to be exact) to view dashboard widgets, it seems impossible to keep the preferences of the widgets between the app launches. Every time you open the application and load the widget, a new instance of the widget with default settings is created. I suppose that the Dashboard application is somehow providing mechanisms to archive/unarchive the widget instances, including their settings, but so far I do not know how it is doing that.

Dashboard stores widget settings in ~/Library/Preferences/widget-com.*.plist in the new binary plist format. These can be converted back and forth with regular XML plists using the command-line "plutil -convert binary1 [file]" or "plutil -convert xml1 [file]".

Quote:

3. Widgets are mostly bloody slow and inefficient

Not in my experience.. though it may depend a lot on your ram and cpu.