[Krypton]

skiTunes home

[ALL inline images must be no wider than 480 pixels --tooki]

skiTunes is a new project with the aim of creating a new open source alternative to iTunes.

From the author:

It's an open-source alternative to iTunes that's faster and sports more features than iTunes does - namely that it's written in Cocoa and uses normal system resources rather than it's own. Because of this, themers will have a much easier time making skiTunes match the rest of the system.

Other planned features include:
� WMA/OGG playback. It will also support any format supported by VLC.
� Multiple iPod management
� iPod --> Computer transfers
� Skinnable "mini-mode"
� Built-in integration with Adium, Growl, and other opensource projects
� SkinKit - don't like the layout/look of skiTunes? Just cook up a Nib file and a few graphics and you have a skin!
� Nearly unlimited extensibility with plugins
� Compatible with iTunes library files


So basically, it's iTunes on steroids - I'm hoping this might become the Adium of music players Smile

The project is in desperate need of members - If you can help in any of the following areas, please IM me. No web designs/graphics are needed; I have that covered.

Currently needed:
- General Obj-C/Cocoa programmers
- Quicktime programmers
- CoreAudio programmers
- XML gurus

I thought this would be of interest due to the relatively large volume of requests for such an app recently.

[Millennium]

Except for the fact that "written in Cocoa" is not a feature, this app looks pretty intriguing for those who don't use the iTunes Music Store (which, admittedly, I don't). I think I'm going to wait for a couple of versions, but this is definitely something I plan to watch.

[CharlesS]

Originally posted by Millennium:
Except for the fact that "written in Cocoa" is not a feature

Yes, it is:

- It means you can count on certain features being there.

- It means that this project is much easier for developers to work on (handy in an open-source project).

- Since they're developing this with the aim of making it easily skinnable, being Cocoa will probably be helpful towards that end.

With that said... can they get away with copying iTunes' interface so closely? That seems pretty blatant to me...

[Chuckit]

If it's skinnable, then the app won't necessarily look like that, I guess.

Incidentally, I also object to touting "written with Cocoa" as a feature. It implies that projects not written in Cocoa would not have the same functionality, which just ain't right.

[CharlesS]

Originally posted by Chuckit:
If it's skinnable, then the app won't necessarily look like that, I guess.

Incidentally, I also object to touting "written with Cocoa" as a feature. It implies that projects not written in Cocoa would not have the same functionality, which just ain't right.

But Cocoa does give you certain functionality, such as Services, the system-wide spell check in text fields, emacs shortcuts in text fields, Accessibility support, click-through with the command key, etc.

For certain types of apps, I will indeed be looking for an app that is preferably in Cocoa. Granted, a music player is not one of those types of apps, but it's still legit to have it in the feature list, IMO.

[songoku912]

Very interesting indeed.

[Superchicken]

If they want to be the adium of audio, they need to do a few things... don't rip off iTunes. Be different and offer features Apple doesn't. As well, make sure you don't leave out features that iTunes have if you can avoid it. Art work, and Ratings should not be difficult to have. As well, include better default themes if your big thing is themeing.

It's interesting, but they also need to get a better name, something unique and open source sounding... how bout... *unes or maybe Munix, Audix? Not to mention, they need to get a better icon. Perhaps even a mascot...

[Chuckit]

Originally posted by CharlesS:
But Cocoa does give you certain functionality, such as Services, the system-wide spell check in text fields, emacs shortcuts in text fields, Accessibility support, click-through with the command key, etc.

Those are features. But those features are not Cocoa. Those features come for free with the standard Cocoa widgets, but as I'm sure you know, it is entirely possible to make a Cocoa app that has none of those things or a non-Cocoa app that has all of those things.

[CharlesS]

Originally posted by Chuckit:
Those are features. But those features are not Cocoa. Those features come for free with the standard Cocoa widgets, but as I'm sure you know, it is entirely possible to make a Cocoa app that has none of those things or a non-Cocoa app that has all of those things.

Well, there are some Carbon apps that support Services and Accessibility, but certainly not anywhere near the percentage of Cocoa apps that do (darn near 100%). As for the system-wide spell check, that feature is Cocoa. The AppleSpell service links against the Foundation, and yes, Carbon apps can use it - by calling Cocoa methods from Carbon! It's possible, but I've only seen it done in one app - BBEdit/TextWrangler. Go ahead and check the binary if you'd like - it links against both Cocoa and Carbon, and if you run class-dump on it, you'll find it has Objective-C code in it. On an unrelated note, BBEdit/TextWrangler also happens to be the only Carbon app I've ever seen incorporate the emacs shortcuts in a text widget.

For all the above-mentioned features, what's the percentage of Carbon apps that use them? Very low. Could you write a Cocoa app that supported none of these? Maybe if you totally rewrote the text view object... but why would you do that?

As for the last one I mentioned - command-click-through - well, to not support that in Cocoa I think you'd have to rewrite the whole window and view objects, wouldn't you? And do you know of even one Carbon app that can do this? Not even the excellent TextWrangler seems to support command-click-through. I don't use the Carbon framework enough to even know if it's possible with Carbon. Is it?

And then there's other little things like the font panel, plus subtle little niceties like the window bar document proxy icons not making the window pop to the front when you start dragging them from a background window (the fact that the Finder doesn't do this drives me nuts when I'm trying to drag a folder into the Terminal and the Terminal is in front)...

I dunno, some of these are probably bugs in the Carbon framework that Apple could theoretically fix... but they never do.

[bgotori]

Hey Krypton

Thats GREAT!!! Can't wait for your Program!!!


Great Times Ahead!!!

Brad

[Krypton]

If I'd known this would bring the Carbon apologists out of the murky depths I wouldn't have bothered

Moving swiftly on, I'm not too keen on copying the iTunes UI either but I imagine they would be receptive to feedback on the matter.

[Millennium]

Originally posted by CharlesS:
But Cocoa does give you certain functionality, such as Services, the system-wide spell check in text fields, emacs shortcuts in text fields, Accessibility support, click-through with the command key, etc.

So the programmer didn't have to do as much work. That's not a feature; that's just a circumstance which arose during the app's design.

You disappoint me. Far be it from me to be a "Carbon apologist", but you of all people should know better than to be touting a programming language and API as a feature of a program. You're a developer, and a good one at that; you have no need to sink to this kind of false marketing.

[CharlesS]

Originally posted by Millennium:
So the programmer didn't have to do as much work. That's not a feature; that's just a circumstance which arose during the app's design.

You disappoint me. Far be it from me to be a "Carbon apologist", but you of all people should know better than to be touting a programming language and API as a feature of a program. You're a developer, and a good one at that; you have no need to sink to this kind of false marketing.

I'm just pointing out that there are reasons for someone to like Cocoa apps.

Look, I'm not one of the fanatics saying that I would only use Cocoa apps, that good apps can only be written in Cocoa, or that Apple should rewrite the Finder from scratch, or any of that. But I'm also not one of the fanatics on the other side of the fence who claims there's no difference between a Carbon and a Cocoa app and that Cocoa offers no advantages to the end user, because that simply isn't true either.

My position is what I see as a nice, reasonable position in the middle of the road. Cocoa isn't the be-all and end-all of the universe, and it isn't necessary for life, but it does offer some nice things that I appreciate when I use an app written with it.

[saddino]

Originally posted by Krypton:
Moving swiftly on, I'm not too keen on copying the iTunes UI either but I imagine they would be receptive to feedback on the matter.

If anyone remembers, iFlicks (which also lifted the iTunes interface) was mysteriously shut down a few days after its release and then was rereleased with a redesigned interface without comment. The infringing elements, judging from the changes, was the entire top toolbar and widgets/info-window, as well as replacing "copied" iTunes widgets.

Even more important, iTunes is a well protected trademark, and "skiTunes" is just asking for trouble from Apple legal.

Projects like these deserve a chance to survive, so someone should tell them not to blow it by copying the iTunes UI or trademark.

[Chuckit]

Originally posted by Krypton:
If I'd known this would bring the Carbon apologists out of the murky depths I wouldn't have bothered

Carbon apologist? I've never written an app entirely in Carbon in my life. The most Carbon I've ever used is writing some wrappers for certain functions that don't exist in Cocoa (like aliases, Carbon Events and the ability to read OS 9 comments). I think Cocoa is a fantastic framework for developers, which is why I use it. It's just deceptive to talk as though being made with Cocoa makes an app better than an app not made with Cocoa (which is what the term "feature" implies).

[Angus_D]

Originally posted by Chuckit:
Carbon apologist? I've never written an app entirely in Carbon in my life. The most Carbon I've ever used is writing some wrappers for certain functions that don't exist in Cocoa (like aliases, Carbon Events and the ability to read OS 9 comments). I think Cocoa is a fantastic framework for developers, which is why I use it. It's just deceptive to talk as though being made with Cocoa makes an app better than an app not made with Cocoa (which is what the term "feature" implies).

Your users should never know/care what framework you used to develop your application.

[Turias]

Originally posted by saddino:
If anyone remembers, iFlicks (which also lifted the iTunes interface) was mysteriously shut down a few days after its release and then was rereleased with a redesigned interface without comment. The infringing elements, judging from the changes, was the entire top toolbar and widgets/info-window, as well as replacing "copied" iTunes widgets.

Even more important, iTunes is a well protected trademark, and "skiTunes" is just asking for trouble from Apple legal.

Projects like these deserve a chance to survive, so someone should tell them not to blow it by copying the iTunes UI or trademark.

Agreed. These is no way this app is going to be released as is without Apple legal coming down on them.

[wataru]

As I recall, Apple patented iTunes's interface. The patent included a diagram detailing just about everything copied into skiTunes. I think this will get gutted by Apple Legal pretty quick.

[Superchicken]

For the record, I actually like to know what my Apps are written in... I love the fact that Pages is Cocoa, because I can change the graphics in it. I actually changed the new page icon in the tool bar since it wasn't consistent with the one in Keynote, now the two look better together... granted I'm a freak... but seriously guys it's a valid point pointing out what scripting language it's written in, perhaps it isn't a feature but it's valid to point out. NeoOffice/J has a reference to it's language in it's name! Not to mention people regularly complain about slow Java apps... it's certainly not life or death, but it's valid. That said they need to get a good UI designer on this project... If they get the app stable I wouldn't even mind helping them with a nice mock up and making graphics for the widgets.

[CharlesS]

Originally posted by Superchicken:
For the record, I actually like to know what my Apps are written in... I love the fact that Pages is Cocoa, because I can change the graphics in it. I actually changed the new page icon in the tool bar since it wasn't consistent with the one in Keynote, now the two look better together... granted I'm a freak... but seriously guys it's a valid point pointing out what scripting language it's written in, perhaps it isn't a feature but it's valid to point out. NeoOffice/J has a reference to it's language in it's name! Not to mention people regularly complain about slow Java apps... it's certainly not life or death, but it's valid. That said they need to get a good UI designer on this project... If they get the app stable I wouldn't even mind helping them with a nice mock up and making graphics for the widgets.

Although we're talking about frameworks, not scripting languages (C, C++, and Objective-C definitely not being scripting languages, and Carbon and Cocoa not being languages at all), I agree with the rest of what you say. No one minds if a developer's page mentions an app is written for Java, or .NET, or PowerPlant or gtk or qt or RealBASIC or whatever. But bring up Cocoa and everyone's in a tizzy, mostly because people are reacting to people who spout stuff like:

Originally posted by Krypton:
If I'd known this would bring the Carbon apologists out of the murky depths I wouldn't have bothered

The reason for the anti-Carbon statements, on the other hand, seems to come from the users of the old NeXT system whose philosophy of the complete object-oriented interface seems to have been gutted by the inclusion of Carbon, so they're bitter (and, of course, there are others who are simply ignorant). Carbon was necessary for OS X to get the necessary applications it needed to survive. And, of course, great applications can be written in Carbon (example: TextWrangler). To be fair, though, I can kind of understand the NeXT people's frustrations - things like Services were indeed much more useful back in the NeXT days, and it is kind of a shame that the NeXT philosophy had to go out the window. And the differences I pointed out are clearly evident and objectively true, along with other differences such as the weird line ending inconsistency in text fields, so it's somewhat disingenuous to say there's no difference at all.

With that said, you need to look at the reason why this app listed Cocoa as a feature. It's because instead of using custom widgets like iTunes does, it uses all the standard Cocoa widgets, so that if you theme the OS, their app will inherit the changes. It's for themers. And for a themer, it's a legitimate benefit to have the app use the standard Cocoa widgets.

[lenox]

| insert obligatory "Finder.app should be rewritten in Cocoa already!" whine here |

[TETENAL]

Originally posted by Superchicken:
For the record, I actually like to know what my Apps are written in... I love the fact that Pages is Cocoa, because I can change the graphics in it.

That has nothing to do with Cocoa.

[CharlesS]

Originally posted by lenox:
| insert obligatory "Finder.app should be rewritten in Cocoa already!" whine here |

God, no.

[Millennium]

Originally posted by CharlesS:
With that said, you need to look at the reason why this app listed Cocoa as a feature. It's because instead of using custom widgets like iTunes does, it uses all the standard Cocoa widgets, so that if you theme the OS, their app will inherit the changes.

That has nothing to do with Cocoa, however. Carbon apps can also use standard OS widgets. In fact, they can even use nib files just as Cocoa apps do.

[Superchicken]

So why is it that nearly every carbon app I've seen has never allowed me to change the widgets? Can a developer make it so that you can't change the widgets in a Cocoa app?

[CharlesS]

Originally posted by Millennium:
That has nothing to do with Cocoa, however. Carbon apps can also use standard OS widgets. In fact, they can even use nib files just as Cocoa apps do.

Not the metallic iTunes style buttons. Those are only available in Cocoa nibs as of 10.3.x.

Quit being so patronizing.

[TETENAL]

Originally posted by Superchicken:
So why is it that nearly every carbon app I've seen has never allowed me to change the widgets?

Probably because you have mistaken all bundled, NIB-based Carbon applications as Cocoa.

[Millennium]

Originally posted by Superchicken:
So why is it that nearly every carbon app I've seen has never allowed me to change the widgets?

Because there are other ways to generate widgets in Carbon. Of particular interest is the .rsrc file, which itself a descendant of the old resource forks from the OS9 days. These widgets can be changed, but it requires a different editor. In the OS9 days one would use ResEdit, which still runs fine in Classic. Nowadays, Resorcerer and ResFork are more popular.

I don't know why nib files never caught on with the Carbon crowd, seeing as they're usable in OS9 as well as OSX. My guess is that the Carbon apps you've dealt with have a heavy legacy codebase which would take (as far as the developers believe) too much effort to port.

Can a developer make it so that you can't change the widgets in a Cocoa app?

It is not common, but it is certainly doable.

[Superchicken]

Anyway can we get back on topic... actually I think I might do a mock up of how this App should try and look...

[CharlesS]

Originally posted by Millennium:
Because there are other ways to generate widgets in Carbon. Of particular interest is the .rsrc file, which itself a descendant of the old resource forks from the OS9 days. These widgets can be changed, but it requires a different editor. In the OS9 days one would use ResEdit, which still runs fine in Classic. Nowadays, Resorcerer and ResFork are more popular.

Since the resources are in data-fork .rsrc files more often than not these days, you'll need to copy all the data into the resource fork of a file in order to edit it with ResEdit, and then copy the data back afterward.

I don't know why nib files never caught on with the Carbon crowd, seeing as they're usable in OS9 as well as OSX. My guess is that the Carbon apps you've dealt with have a heavy legacy codebase which would take (as far as the developers believe) too much effort to port.

Many of the good Carbon apps like TextWrangler, the Finder, et al. use nib files. Unfortunately, these are in the minority.

[Hugi]

Why on earth should developers not tell users which framework they use to write their apps? I always prefer to use Cocoa apps when possible, since I can use the Icelandic spell checker in Cocoa-apps, but not in Carbon apps.

Oh, and on topic; skiTunes looks great, I hope you guys won't meet with any trouble from Apple, although you'll probably have to change the look

[Angus_D]

Originally posted by Hugi:
Why on earth should developers not tell users which framework they use to write their apps? I always prefer to use Cocoa apps when possible, since I can use the Icelandic spell checker in Cocoa-apps, but not in Carbon apps.

DTS provides sample code for how to call the system spell checker from a Carbon application.

[Hugi]

Originally posted by Angus_D:
DTS provides sample code for how to call the system spell checker from a Carbon application.

Sorry, that doesn't help me when no one implements it. Or should Icelandic users decompile the applications they use, create the carbon-cocoa connection and recompile?

[Chuckit]

You should tell developers you want this feature. Just because nobody's doing it doesn't mean you should write off any Carbon app that may in fact do it.

[CharlesS]

Sure, they can do it, but in practice, the only app I've ever seen which actually does it is TextWrangler.

[Superchicken]

http://clayshaker.com/mbp/notiTunes.jpg

Check that out, that is the SORT of look this app should be heading in, not this theme ripping off iTunes. The reason iTunes was successful was because it didn't rip off what was available but rather offered a better interface, a cleaner look and a more compelling feel. They can certainly make it themable. But if you're trying to rip off iTunes everyone will just keep comparing it to iTunes instead of letting it live on it's own. The reason Adium took off was because Adium wanted to make a better app than AIM, not make an open source AIM.

[wataru]

Yep, here's the picture from the patent. I think these guys are toast if they don't change something. Then again, this is Mac-only, unlike that other copycat Lsongs, so maybe they won't care that much.

[torifile]

Originally posted by wataru:
Then again, this is Mac-only, unlike that other copycat Lsongs, so maybe they won't care that much.

They HAVE to care that much. If they don't protect their patent, they will lose it.

[saddino]

Originally posted by torifile:
They HAVE to care that much. If they don't protect their patent, they will lose it.

Actually, that is only true of Trademark. Copyrights and patents do not have to be actively defended; they can expire, but cannot be "lost."

Nevertheless, Apple has protected their iTunes design patent before, and I'm sure they will again.

[King Bob On The Cob]

These people do not understand at all, do they?

Your supposed to give it a REALLY crappy default skin, then a page over have the good iTunes skin supposedly created by someone with no affiliation with the project (who lives in Russia as well).

[[APi]TheMan]

Originally posted by King Bob On The Cob:
These people do not understand at all, do they?

Your supposed to give it a REALLY crappy default skin, then a page over have the good iTunes skin supposedly created by someone with no affiliation with the project (who lives in Russia as well).

Haha a great idea, thanks for lightening the mood of this thread.

Oh, and I'm excited about skiTunes, so I'll be watching this one too.

[iindigo]

Hi, owner of the skiTunes project here.

To answer some things that have come up in this thread -


I've promoted being written in Cocoa for a few reasons. The main one being that nearly everyone knows without shadow of a doubt most Cocoa applications use native widgets, and therefore enterthe mind as "truely" theme-saavy. Carbon applications, however, seem to have a good deal of urban legends about them and could confuse people as to skiTunes' compatibility with ShapeShifter/other themers. Another reason is that a lot of people feel that Cocoa applicatios are faster (they usually are) and I myself feel that Cocoa apps feel more "at home" and feel more native than carbon apps. Also, as others have mentioned, with the project being Cocoa it takes off a little bit of coding work and throws in some extras for free (Spell checking, find panel, font panel, color panel, the list goes on)

Now as to the interface - I've copied iTunes for the time being mainly because it allows the program to have a tried-and-true interface in early development stages. This helps ward off bad reviews on the skiTunes interface until we're ready to release the new interface.

To Superchicken: Thanks for the consideration/help on the interface, but we're probably not going anywhere near there. I'm planning on more of a toolbar-based interface (don't worry, I promise I won't go MS Office-style on ya'll with the toolbars ). I'll post a mockup for it after a while to see what you guys think.



John

[iindigo]

Here's a mockup I quickly threw togerther in Photoshop. It isn't final, and some things a little messed up (toolbar icon spacing, for example) but it should be enough to give you an idea of how the redesign is going to look.

http://skitunes.iindigo3d.com/redesign.jpg

Opinions and crits (as long as they aren't too harsh) welcome.

[Chuckit]

Originally posted by iindigo:
I've promoted being written in Cocoa for a few reasons. The main one being that nearly everyone knows without shadow of a doubt most Cocoa applications use native widgets, and therefore enterthe mind as "truely" theme-saavy. Carbon applications, however, seem to have a good deal of urban legends about them and could confuse people as to skiTunes' compatibility with ShapeShifter/other themers. Another reason is that a lot of people feel that Cocoa applicatios are faster (they usually are) and I myself feel that Cocoa apps feel more "at home" and feel more native than carbon apps. Also, as others have mentioned, with the project being Cocoa it takes off a little bit of coding work and throws in some extras for free (Spell checking, find panel, font panel, color panel, the list goes on)

Aside from the last reason (which is valid), ugh. That's exactly why I objected. You're just trying to play anti-Carbon FUD to your advantage. "People think Cocoa apps are better, so I'm going to encourage them in this irrational bias because it suits me."

I'm sorry if I sound drama queen-y, but even though I don't particularly use Carbon, this kind of FUD drives me up the wall. You could have expressed all these features much better explicitly. "It uses all Mac OS X-native technologies, and can be themed with programs like Shapeshifter."

By the way, I thought you were going to allow skinning. How can you allow skinning and still use all standard widgets at the same time? Aren't these ideas kind of antithetical?

[Chuckit]

Originally posted by iindigo:
Here's a mockup I quickly threw togerther in Photoshop. It isn't final, and some things a little messed up (toolbar icon spacing, for example) but it should be enough to give you an idea of how the redesign is going to look.

http://skitunes.iindigo3d.com/redesign.jpg

The blue dial is a little bit distracting. When you first see the picture, it's like, "LOOK AT ME! I AM THE BLUE DIAL THY GOD!" I'd say make it a bit less lickable.

[iindigo]

Originally posted by Chuckit:
Aside from the last reason (which is valid), ugh. That's exactly why I objected. You're just trying to play anti-Carbon FUD to your advantage. "People think Cocoa apps are better, so I'm going to encourage them in this irrational bias because it suits me."

I'm sorry if I sound drama queen-y, but even though I don't particularly use Carbon, this kind of FUD drives me up the wall. You could have expressed all these features much better explicitly. "It uses all Mac OS X-native technologies, and can be themed with programs like Shapeshifter."

By the way, I thought you were going to allow skinning. How can you allow skinning and still use all standard widgets at the same time? Aren't these ideas kind of antithetical?

Sorry about all the anti-Carbon-ness, it probably comes from my own personal disliking for carbon apps. This is mainly due to the carbon app known as the Finder - ugh... that's for another another thread though.

As for skinning, the skins won't be like the skins you're used to, like Audion and SoundJam skins. skiTunes skins will be .nib files and a some graphics wrapped up into a .tuneSkin package. This way, native widgets will still be used.

[Moose]

Originally posted by iindigo:
Here's a mockup I quickly threw togerther in Photoshop.

Still looks like iTunes, but with different widgets. The placement of everything is identical.

[iindigo]

Originally posted by Moose:
Still looks like iTunes, but with different widgets. The placement of everything is identical.

The top area is a toolbar, which allows you to arrange it however you like.

[- - e r i k - -]

Originally posted by iindigo:
Here's a mockup I quickly threw togerther in Photoshop. It isn't final, and some things a little messed up (toolbar icon spacing, for example) but it should be enough to give you an idea of how the redesign is going to look.

http://skitunes.iindigo3d.com/redesign.jpg

Opinions and crits (as long as they aren't too harsh) welcome.

Compare this screenshot with the top one and ponder why I'm still going to use iTunes if this is the interface you are going to offer in the final version of skiTunes.

[Truepop]

looks cool but I would like to see an project that looks like the audion 4 idea.

http://www.panic.com/extras/audionst...p-audion4.html