AMP Wishlist Thread - Page 17

iamgnat · 10-04-2006, 09:31 AM

Quote: Originally Posted by aychamo

I looked at iTheater's soure-code, and it has literally 1/10th the features of AMP, but has 10 times the # of files, and almost not a single line of comments.

I don't know to iTheather's code base, but reasonably breaking up code into self contained "helper" objects is a very strong design method. By doing that you don't have to look in many places (or search through one big file) to find what you are looking for and assuming you are using a good public/private (in practice even if the language doesn't truely support it) changes are localized to one place as well as effects of those changes.

Notes are a problem in all code and with all developers. Depending on ones view, there are too many or too few on any given day. In the end, we are all human and have our own preferences.
I am big on documenting code, but I believe it is more than just having more notes than you have lines of code. The idea is that your code should be clean (i.e. don't use 1 line when 3 makes your intent clearer) so that it tells most of the story. Then you add notes to those areas that just need a little help. Logging messages not only help the user know what is going on, but can also help document the code as well.

-dave

iamgnat · 10-04-2006, 09:32 AM

Quote: Originally Posted by Bugbyte

I think Bobby's doing an amazing job and I know everyone is extremely appreciative.

This does need repeating

-dave

Bugbyte · 10-04-2006, 09:36 AM

One solution that we used for Harmony was OpenSVN. Once the repository was set up, you could commit your changes and then, using OpenSVNX, could compare, using the GUI, changes others have made to the repository. You literally have side by side comparison and select those to accept in your version and those to reject.

I know you had some trouble setting up the repository so you went with CVS, but once we got it going, making changes was pretty easy. The only issue was when someone would change the nib files. There's no way to make a comparison. You basically have to coordinate who's doing what on the nib or you'll step on each other.

minicoopS007 · 10-04-2006, 09:37 AM

Quote: Originally Posted by Jirka Jirout

Considering the monolithic and static design of the application and lack of a clearly defined API for add-ons, it is very difficult to add anything to AMP without playing around with the core and tweaking it.

First off AMP is a great program, but I have to agree with Jirka. I tried creating a XM add-in but was forced to play with the core. AMP's api was not that obvious, and i need more control. Also by making it a pluggin, it made the navigation horrible. I think we need to address AMPs navigation, too many clicks. For example I'm in radio mode and I want to get to a pluggin. I click back, click out of music, then click ...but that is another topic.

So I decided to create a AMP one-off which will have XM. Unfortunately I don't have the time to rewrite HXM, which is a java XM controller in objective-C to create a tight integration with AMP, so the interface is applescript to HXM. To maintain the look and feel of AMP i've decided to use radiosharks interface. So if you have radioshark and/or HXM, the radio button is enabled. To get to XM click on the radio button twice. For now there are two bands XM1 and XM2. What I'm working on now is to display the XM contents in the visible window (the dialog that comes up), since the radio display just shows the channel number. I would say I'm 80% complete.

I know this will be a bear to merge back into AMP and don't plan to do it. Whatever new features bobby adds I may incorporate them. Whoever created the project on sourceforge kudos to you. But adding to Tom's comments, it is hard working together on opensource projects. We all have lives, different coding speeds, distance...sounds like a marriage.

LightningMac · 10-04-2006, 10:58 AM

Well I did get everyone talking

iamgnat · 10-04-2006, 12:40 PM

Quote: Originally Posted by Bugbyte

I know you had some trouble setting up the repository so you went with CVS, but once we got it going, making changes was pretty easy. The only issue was when someone would change the nib files. There's no way to make a comparison. You basically have to coordinate who's doing what on the nib or you'll step on each other.

CVS and SVN and very similar in most regards. The nicer things about SVN (that I know of) is that if the repository servers are setup to do so, you can restrict who can have modify access to specific directories (i.e. someone could have access to a plugin, but not the core) and it supports diffing of binaries (CVS imports the whole binary everytime).
The Version Comparison tool (can't think of it's name off the top of my head and am too lazy to look right now

) works with CVS too and is very nice (though outside of it being slow Java, I really like Eclipse's compare tool a bit better).
My big issue (and it appears to be the same for CVS and SVN) is that XCode doesn't have all the functionality built in to it. For example, if you add a new file/dir, you need to run the import and add commands at the command line vs having functionality in XCode itself. It is also painfully slow for commiting and retrieving from CVS (the command line and Eclipse's interface are orders of magnitude faster working with the same code from the same CVS servers). That there is no way to retrieve a Project (that you don't currently have) from CVS/SVN is annoying to (again you have to do it from the command line).
Given how much thought and effort Apple put into XCode, i'm more than a bit surprised that Source Management really feels like an after thought.

As far as coordination goes, that is indeed a big issue. Programming as part of a team is what I do for a living. You just have to setup best practices for the project (e.g. only commit working code, commit nightly, etc..). The comparison tools are there to allow you to merge differences if you are commiting from an older version because someone made another change in the meantime. It takes practice, but it does work.

-dave

LightningMac · 10-04-2006, 12:54 PM

hey guys check this out (Apple working on GPS with Google?):

http://www.mactelchat.com/articles/2...-evidence.html

Jirka Jirout · 10-04-2006, 02:19 PM

Quote: Originally Posted by LightningMac

hey guys check this out (Apple working on GPS with Google?):

http://www.mactelchat.com/articles/2...-evidence.html

Nothing new - a function to display a map for an address has been around in Address Book for quite a while...

aychamo · 10-04-2006, 02:20 PM

Quote: Originally Posted by Jirka Jirout

Nothing new - a function to display a map for an address has been around in Address Book for quite a while...

Jirka, is english your first language?

Jirka Jirout · 10-04-2006, 04:27 PM

Quote: Originally Posted by aychamo

Jirka, is english your first language?

No, it is not. Sorry for any errors :-)

LightningMac · 10-04-2006, 08:24 PM

Quote: Originally Posted by Jirka Jirout

Nothing new - a function to display a map for an address has been around in Address Book for quite a while...

I was talking about the several references to GPS in the code

Jirka Jirout · 10-05-2006, 01:16 AM

Quote: Originally Posted by LightningMac

I was talking about the several references to GPS in the code

Yes, and if I look at what it really is, it looks like an option to display a map of location where the picture was taken using the GPS coordinates stored in image's EXIF data.

LightningMac · 10-05-2006, 02:10 AM

maybe this will give a clearer picture of what I was trying to say, from macrumors.com:

iPhoto 6.0.5 Google Maps Integration And Apple GPS-enabled Device?
Wednesday October 04, 2006 09:37 AM EST
Posted by longofest

MacTelChat has found hidden references in iPhoto 6.0.5 that show Apple is preparing iPhoto for integration with Google Maps. It appears as though a hidden button in the interface would allow hidden GPS attributes about a photo to link with Google Maps and show where in the world a picture was taken.

This news comes as AppleInsider revisits a patent application discovered in September by MacNN for a "multi-functional handheld device." According to the patent, the device could contain a multitude of hardware features, including:

- Microphone
- Force Sensing
- Camera
- GPS
- Cellular radio

AppleInsider also notes that Apple may be behind a survey conducted in the spring, which asked users to "rate their preference of form factor designs for a next-generation Internet handheld device."

ilmiomac · 10-05-2006, 06:10 AM

I think we're completely Off Topic talking about rumors on Maybe-it-will-be-released-sometimes-somehow products.
Let's talk about AMP here. Thanks

bcohen5055 · 10-07-2006, 10:43 AM

Yes lets talk more about amp and less about rumors. I think that for some applications the plugin interface is fine. For instance, the Phidget LCD plugin that someone requested just needs to basicly run in the background reading a plist generated by amp and sending data off to the device. If clicked on in the plugin display you can change the contrast of the screen and modify what data is being displayed. (I think I can make it display GPS info or song info). but besides that it can just sit there unnoticed using all of amps music and GPS data. I find this to be much cleaner, theres no need for me to have anymore controll over amp than reading plists and maby we can develop some more ways to output amps data for other uses in the background. This would alow for amp to do all the heavy lifting and plugins to just format and use the data for whatever their specific purpose is.