Linked by Kroc Camen on Thu 4th Dec 2008 18:20 UTC
Editorial Songbird is a new open-source music player that has this week landed at 1.0. Songbird is described as a "web player"- a music player for this modern, connected era. It blends the web-rendering core of Firefox (Gecko), with the media capabilities of GStreamer- a cross-platform, open-source media playback engine.
Thread beginning with comment 339222
To read all comments associated with this story, please click here.
Comment by leos
by leos on Thu 4th Dec 2008 20:02 UTC
leos
Member since:
2005-09-21

"The Mac download expands into a 117 MB"

I pretty much lost interest after that. For me, a music player should be something to play music in the background and use minimal resources doing so. I don't need some behemoth running in the background all the time, integrating every single online source of information into the app itself on the off-chance that I might want to look that stuff up.

By all means, allow me to get to the wikipedia/lyrics/pictures page for an artist/song, but why people think embedding this info into a music player is a good idea is beyond me. Those things exist on the web, and the correct tool for viewing them is a web browser. Instead of embedding a browser engine in your app, launch the browser with the correct link so I can view it properly and maintain the separation of responsibilities between apps.

Reply Score: 7

RE: Comment by leos
by Kroc on Thu 4th Dec 2008 21:23 in reply to "Comment by leos"
Kroc Member since:
2005-11-10

You need to understand how Mac apps work. Everything is in the one file. It's not like Windows where one app has parts in Program Files, DLLs in System 32, and then stuff in the Registry, and in other cases yet more in Common Files...

If you had continued reading - you would have noticed that the very next line says that iTunes is 129 MB.

Remember that this size includes all the translations -- something you don't get with many Windows apps, if at all -- as well as all of the open source libraries (like GStreamer) that have to be bundled because Songbird is not a native OS X app, using the native APIs.

I think you're doing yourself a disfavour by taking the file size into account, especially given that either a) you don't use a Mac AND/OR b) you never compared the file size to any of the other apps on the Mac.

Reply Parent Score: 1

RE[2]: Comment by leos
by andrewg on Thu 4th Dec 2008 21:33 in reply to "RE: Comment by leos"
andrewg Member since:
2005-07-06

You need to understand how Mac apps work. Everything is in the one file. It's not like Windows where one app has parts in Program Files, DLLs in System 32, and then stuff in the Registry, and in other cases yet more in Common Files...


Everything is not in one file! It may look like a file to you but it is a directory, a special one, but a directory none the less.

Reply Parent Score: 2

RE[2]: Comment by leos
by sbergman27 on Thu 4th Dec 2008 21:45 in reply to "RE: Comment by leos"
sbergman27 Member since:
2005-07-24

Remember that this size includes all the translations -- something you don't get with many Windows apps, if at all

And which, with the exception of a maximum of one translation, are completely worthless and a waste of time and space.

Linux users used to have to sit through endless rounds watching:

blah_blah_enGB
blah_blah_enUS
blah_blah_sp
blah blah_de
blah_blah_tw
blah_blah_se
...

scroll by endlessly on installations and updates. Thank the deities that be that Linux distros finally got a clue.

Mac apps really do this?

Reply Parent Score: 2

RE[2]: Comment by leos
by solarcontrol on Sat 6th Dec 2008 13:11 in reply to "RE: Comment by leos"
solarcontrol Member since:
2008-11-17

All of that aside, his complaint made no sense.
File size has nothing to do with resource usage (other than storage memory).
For example, any recoding app will use lots of resources but doesn't necessarily take up much space on the hard drive,

Reply Parent Score: 1

RE: Comment by leos
by Jason Bourne on Fri 5th Dec 2008 18:01 in reply to "Comment by leos"
Jason Bourne Member since:
2007-06-02

"The Mac download expands into a 117 MB"

Mac applications generally carry all the static libraries in one single file. There is a different philosophy of setup in Mac: There's no setup of anything. Just drag and run. I don't think it's the best philosophy when it comes down for shared libraries and take advantage of what's already in memory. But Mac does have a resource fork (meaning that it should be much more than 117 totally static).

Reply Parent Score: 1

RE[2]: Comment by leos
by sbergman27 on Fri 5th Dec 2008 18:21 in reply to "RE: Comment by leos"
sbergman27 Member since:
2005-07-24

I don't think it's the best philosophy when it comes down for shared libraries and take advantage of what's already in memory.

It's even worse for security update management.

Reply Parent Score: 2

RE[2]: Comment by leos
by Chicken Blood on Fri 5th Dec 2008 18:35 in reply to "RE: Comment by leos"
Chicken Blood Member since:
2005-12-21

"The Mac download expands into a 117 MB"

Mac applications generally carry all the static libraries in one single file. There is a different philosophy of setup in Mac: There's no setup of anything. Just drag and run. I don't think it's the best philosophy when it comes down for shared libraries and take advantage of what's already in memory. But Mac does have a resource fork (meaning that it should be much more than 117 totally static).


That's not true. Mac apps generally have dynamic libraries/frameworks, which can be embedded in the application bundle or located in a shared location such as ~/Library/Frameworks or /Library/Frameworks.

Drag-install apps usually use the embedded method, but apps that use installers are free to locate frameworks in either of the shared locations.

Reply Parent Score: 2