Nice music player control docklet

[Michele De Pascalis]

It would be nice to see a prettier music-player control graphically integrated in docky, with buttons for commands that appear clicking on an icon, like the details of the weather applet (have you ever seen the player control in iOS 4, in the multitasker dock?).
Perhaps it would have a setting to decide the player to control (would be pointless to have a docklet per player, don't you think?).

[Daniel Rodrigues (danyr)]

This could be achieved with a generick docklet controling every MPRIS[1]-compliant player (MPRIS is the same dbus interface used by Ubuntu's sound menu). Newest versions of Rhythmbox, Deadbeef, Banshee, Clementine and others support it, so any of these players would be supported out-of-the-box by this generick docklet.

Also, I really like the idea of an iOS style music controller. Maybe with the album art integrated, highlighted, and the controls next to it. Another question is how this should be accessed: Click-and-swipe to left? That would be really nice ;)
Or maybe just by clicking in the icon of a supported music player?

But I totally agree with this, music controls should have an independent pane in Docky. Maybe in the future even playlist selection could be integrated (MPRIS also has playlist support, not yet stable AFAIK).

[1] http://www.randomguy3.me.uk/mpris/

[Michele De Pascalis (glaedr-il-drago)]

I made some kind of mockup (music controls got by google img). See the attachment.?field.comment=I made some kind of mockup (music controls got by google img). See the attachment.

[Robert Dyer (psybers)]

Wonderful, and Im sure Dan could come up with something just as nice or nicer. Too bad it isn't possible to do that with a dock painter. And never will be.

[Michele De Pascalis (glaedr-il-drago)]

I would code personally the applet, but I don't know C#, personally I miss a C++ api...Is it possible?

[Robert Dyer (psybers)]

In theory as long as the assembly is .Net, it doesnt matter what language was used to generate it. I do not know if there is a Mono based C++ compiler or not.

Also as I said, what you mocked up is not even possible with our API (nor will it ever be).

[Daniel Rodrigues (danyr)]

@Michelis

That was exactly was I was thinking.
Too bad it's technically impossible.

[Michele De Pascalis (glaedr-il-drago)]

Why not? Isn't it possible to draw some clickable buttons in a docklet space (see Weather)?

[Robert Dyer (psybers)]

No. Painters (e.g. weather, calendar) are just how they sound: you paint on them. There is no way to get feedback and thus no way to do buttons.

The buttons you see for left/right are part of the framework and internal to Docky. They are specifically for painters with multiple pages.

[Michele De Pascalis (glaedr-il-drago)]

Hmm...sounds bad...I think that we'll need them soon. Maybe somebody should implement it.
Which GL toolkit was used to build Docky up?

[Robert Dyer (psybers)]

It is exactly as they were designed. There is no ability for buttons because we wanted that, not because someone failed to implement it.

Docky does not use GL. It draws using GTK and Cairo.

[Michele De Pascalis (glaedr-il-drago)]

> It is exactly as they were designed. There is no ability for buttons because we wanted that, not because someone failed to implement it.

I still can't get this decision: what's evil in buttons? And I did not say that somebody failed to implement, I just said that perhaps it would be a nice thing to get clickable items on the docklets. It could be still possible to get back on docky, maybe simply clicking on the docklet icon on the left...

[Robert Dyer (psybers)]

I never said buttons are evil. It was just a design decision we made. We wanted to avoid the temptation to basically implement entire programs inside docklets. If we allow buttons (or other controls) then that would happen, and we dont want that.

[Michele De Pascalis (glaedr-il-drago)]

Docky could never replace applications: correct me if I'm wrong, but it should be a shortcut to them. My idea is: if docky can launch apps, it should also interact with them, and that's why assistants exist. But your choice simply every interaction in tedious rigth-click menus.

[Michele De Pascalis (glaedr-il-drago)]

Sorry, I mean "But your choice simply forces to implement every interaction as items in tedious rigth-click menus."

[Rico Tzschichholz (ricotz)]

@Robert: It might be reasonable to abtract the MenuListItem class a bit and use a similiar implementation to add "action items" at defined positions (placed from right to left) like the hotseat idea to add custom actions presented as full dock-icon-sized icons - the original item icon would be placed as painter-icon and the hovertext is drawn besides it?

[Robert Dyer (psybers)]

@RIco: I have no idea what you are saying. Mock it up?

[Rico Tzschichholz (ricotz)]

@Robert: It would exactly look like the existing mockup (in this bug report).
The "ActionPainter" gets a list of actionitems (a structure like menuitem) without any drawing information and it will know its dockitem. So we have the ApplicationIcon (at the left), Hovertext (text) and the actionitem (starting from the right) with its action and icon which would be added a clickable area.

[Robert Dyer (psybers)]

Then in that case, no. We will not be doing that. That is exactly what hotseats will be for.

[Michele De Pascalis (glaedr-il-drago)]

Is there a project anywere?

[Michele De Pascalis (glaedr-il-drago)]

I mean a project structure, a design or something like this..

[Robert Dyer (psybers)]

We had a branch at one point. It never quite felt 'right' so it is more or less abandoned for now.