(2 replies, posted in Features)

I'd rather not see them in the default distribution, but an additional downloadable add-on (read: plugin) would ofcourse be cool - I won't use it though.
Cog is, in my eyes, a music player, not an entertainment suite.


(61 replies, posted in Development)


(61 replies, posted in Development)


(39 replies, posted in Development)

Wow, I didn't know it had become this long tonguecool


(39 replies, posted in Development)

Another view on the sidebar problem would be to let the user choose which plugin controls the sidebar.
In other words a plugin desides what 'its' sidebar would look like. Since there can only be one sidebar, not every plugin is happy. However just as with drawers you can hide sidebars, so all plugins should be able to interact with 'their' sidebar.

I think I cannot realy make clear what I mean so I give an example:

Suppose I write a plugin that lets you have multiple file-drawers with multiple root-folders (I do not - yet - intend to do so).
Suppose furthermore that my plugin provides some button for each file-drawer.
In the drawer example I think you are able to open two different file-drawers (I vaguely remember that OSX will then give each vertical window-border a drawer). You would get some terrible interface-clutter otherwise.

Now lets see how this would have been done with a sidebar.
When no of my file-bar buttons are pressed, there would be no sidebar.
When one is pressed, a sidebar with the file tree would appear.
When another is pressed, that button pressing also means: "I hand over sidebar control to this instance of the plugin." The contents of the sidebar now seem to change into the newly selected file-tree.
You can also think of this as the 'old' sidebar hiding and the new one taking its place in the interface.

I can see no real down-side on such alternative approach (I don't think its a real advantage to keep two file-views open). I do see some improvements, mainly concerning decent interface design.

A problem would be how to implement plugins that influence the sidebar (insted of having its own). This problem is similar however to interacting with drawers.

I might be wrong about quite some things I said because OSX interface-programming is not one of my specialties. I do know some things however about what a good (OSX or, for that matter, any operating system) interface should look like.


(6 replies, posted in Development)

What is the status and future of Cog plugins?

If it is going to be implemented thogoughly I suggest moving Last.fm and perhaps even some codecs (what would I need video-game support for if I don't have any such files?) to plugins.

Within a month or so (when FreeBSD 7.0 RC1 is out to be precise) I will have my server up and running again and with it MusicPD. I would like to write a MPD plugin that loads the filelist of MPD into the file-drawer (or sidebar). It would be nice if it could have a search-field, but that is perhaps more of a future thing.


(39 replies, posted in Development)


(41 replies, posted in Archives)


(91 replies, posted in General)

I'm a MusicPD user, but:
- when my server is down
- I want to listen through my headphones
- I have a local file (voicemail) I want to hear
I use (and love) Cog.

I might add that my server is down about 2 months each year, so I use Cog a lot wink.


(28 replies, posted in Development)

How about developing for Leopard from 0.08 on (0.08 including) and having some fork or backport. I suggest to open the SVN of it for the community, so you don't have to backport yourself.
I know some techniques won't be (easily) possible on pre-Leopard OS X. In my oppinion a backport should then do without them. I don't think this will be a big problem since the current version of Cog is - though not perfect - extremely usable already. It is those small imperfections that can - when fixed in a Leopard release - without much effort be implemented in a backport by volunteers.


(41 replies, posted in Archives)

Please consider adding the ":" that is part of the Bass-cleff. I remember someone else noting this earlier but think this is the right moment to bring this issue to your attention.


(61 replies, posted in Development)

It appears my Dutch translation was not perfect yet. For some unknown reason (aliens? my neighbours brainwashing me?) the translation of "Previous song" and "Next song" ("Vorige Nummer" and "Volgend Nummer") have switched places in the pop-up menu from the Dock-icon.

While I'm at it, there are also some inconsistencies over there concerning captitals. It should read "Afspelen/pauzeren" and "Vorige nummer" and "Volgende nummer" (second word smallcaps to follow Apple's conventions).

The menu should thus read:
- Afspelen/pauzeren
- Stoppen
- Vorige nummer
- Volgende nummer

Do you want me to send an updated nib?