HahaIt's not really that. When I first made AMP, my original intention was to build a front-end that I wanted to use, exactly the way I wanted it. All the paths to files were hard-coded, etc. But then I decided to give it out and see if anyone liked it. I started making a few things as options, then it kinda got out of control.
AMP's growing beyond what I had originally planned. I guess it's good that it filled a niche. But.. I'm extraordinarily busy with school, and to be completely honest, it's not likely that I'm going to spend a few days implementing some random hardware or some odd feature request that I will never use. And a lot of people have really weird hardware setups (like the request for a weird touchscreen a few posts up), and I can't possibly make AMP compatible with every odd setup out there. I've made the code available if they want to change things to their liking.
I know a lot of people would like to help, but they don't know how to program. AMP is my first actual program I wrote for OS X (I wrote a few things I never released, just to learn how to use Cocoa.) It's really not that bad. There is an abundance of online resources ( http://www.cocoabuilder.com , http://www.cocoadevcentral.com , http://www.cocoadev.com , and best of all http://www.google.com ) that can be used to look at example code, talk to other people, and get a grip on what's going on.
So, no, its not hostility. I know I'm partially responsible for the problem because sometimes I'll respond immediately to a random feature request (ie, WarDriving) and implement it. I've been guilty of the same thing in other projects too. Sometimes it seems that good software just comes out of thin air, but.. Don't forget there's someone busting their *** behind the scenes :-) I just hope some people can pick up programming and start doing some plugins or tackling some of these feature requests. Like the traffic thing. It's a nice idea, it's easy to do, just open the URL, read the XML it gives you, parse it and then present it to the user. .. But I would never use that, and I doubt I'll spend the time doing it.
I'm only going to get busier and busier with life (studying for the boards, clinicals, etc), and I'll have less and less time to dedicate to this stuff.. I just need some help in sharing the load, is all. I hope I didn't sound like an *** or anything!
Goodnight!
-
ya, just wanna say thanks again for this program.
edit::
I dunno who reads digg but one of the latest stories are
"How to contribute to Open Source software"
1.Contribute quality:
help to make a better project, better looking and with new features
Submit bug reports
Suggest new features and options
Suggest ways to improve the framework (maybe comparing it to similar OS or comercial projects)
Submit some artwork (icons, backgrounds, logos) to use in the program
Correct spelling and grammar mistakes in documentation
Help maintain a web site for an Open Source project
2.Contribute documentation: Some Open Source projects have a poor or insufficient documentation
Help write good documentation
Translate the documentation (and program text) into another language
Read existing documentation, follow the examples, and make corrections
Create diagrams, screen-shots, and graphics for documentation
Develop spelling and grammar style conventions for documentors
Build a glossary of technical terms (so non geek people can understand)
Convert documentation into more useful formats (i.e. DocBook)
3.Contribute support: everybody need it at least once.
Let programmer do their work while you help other people
Answer questions on forums, mailing lists or IRC channels
Contribute to (or start) an online support group
Help other people learn how to use the program (or programming library)
Write HOWTOS and post them in related forums or your own blog
4.Contribute money: many Open Source projects have a donate button or a shop where to buy related products, but there are other ways to contribute money
Send a developer, project or company some money
Buy a Free Software product, or associated products
Hire Free Software developers
Contribute hardware
Contribute bandwidth
Advertise in their web site if they show ads
Buy products from companies that support Free Software
5.Contribute publicity: If the project gets popular there will be more people wanting to contribute
Package the application for a particular Linux distro (or other OS)
Convince people to chose Open Source products when possible
Write reviews
Write about new ways of using an Open Source program
6.Contribute appreciation: it's an extra way to contribute but may be the most important
Express your appreciation to developers (through email or forum post)
Send the programmers post cards
Give a project or developer a gift (some have wish lists for this)
Be polite when reporting bugs or asking for new features; developers has no obligation to do it after all
ditto(thanks for the great program)
I know verry basic cocoa and have watched many projects on this site develop only to get out of controll by many crazy options. I have wondered about the plugins for amp for a while now, if I could see a basic readme about them or maby a tutorial or template plugin that would be a big help. then I can start, but I'm not really sure where.
In regards to the phidgets post, I have been looking at them for a longtime and once took a class on hardware/software intigration, however I don't own any and don't want to make that investment seeing that I don't even have a maccar right now.
As far as keyless entry is concerned, I think a hybrid of phydgits and bluephone elete may be necisary. Bluephone can run an apllescript to tell phydgets to unlock doors or whatever when you are in a specific range.
But remember this is a Mac Car COMUNITY it isn't Alchamo's job to be the only programer. How do you expect him to program for phidgets if he doesn't even own any? The idea of a forum like this is that someone in the comunity has them, makes them work for them and submits it to a larger project and I think that is what we are lacking right now.
Ok, after looking at the phydgits site it may be possible to develop some functions without having the actual phidgets. The display can easily display text info similar to that of the current GPS window, so if there is a way to pass those strings along to a plugin they can be output to a small display in the dash to show heading, distance, speed, next turn and maby some other basic stuff like that. Can I get any documentation for writing a plugin for AMP?
Are you wanting to show anything on the mac's screen itself, or just output to the hardware device? The good news: in AMP's implementation of GPS, I output a .plist (NSDictionary) that contains all the GPS info you could want, so your plugin will be able to open that dictionary and get everything it needs.
-
Ok well I havn't really looked closely at implimenting this. Right now it is just an idea. I think it would be good to continue the on screen GPS but this will just allow another option for people who want it. I don't have a carpc and won't for quite some time but this just seems like an easy little add-on I think I can do.
bcohen, thanks for helping out aychamo. i know he really wants everyone else to help out and make as many plugins they can. just want to thank you for helping out. im slowing learning cocoa but it might be a while b4 i can help you two guys code AMP.
People have been playing with inkwell over at Inkwell? maybe this can work with a gesture input.
http://www.apple.com/macosx/features/inkwell/
Bookmarks