On Tue, 2005-09-13 at 13:59 -0400, John (J5) Palmieri wrote: > On Tue, 2005-09-13 at 10:02 -0700, Adam Williamson wrote: > > On Tue, 2005-09-13 at 17:10 +0100, Bill Haneman wrote: > > > John Palmieri wrote: > > > > > > >...People will ask why is my favorite xyz > > > >multimedia app not an option. I think it comes down to select one media > > > >player and use that. If it is not good enough to do everything you need > > > >then that should be fixed - not the applet/notification icon. > > > > > > This seems wildly unlikely, thinking historically. I am far from convinced > > > that one app to play them all is even a good fit for user needs in all > > > situations. It's a nice goal, but IMO we shouldn't be making desktop-wide > > > design decisions based on this premise. There are just too many reasons > > > why people both want and need multiple media players on their desktops. > > > > Practically speaking, I think Bill is right. The applet I'm proposing > > shouldn't take more than a couple of days to code and have working and > > useful for the next GNOME unstable release. Writing the One Media Player > > That Everyone Wants To Use For Everything is going to take a lot longer > > than that. Heck, there's currently only one GNOME media player that I > > know of which will both act as a library-based audio player and also > > play CDs, and that's Banshee, which is very new, based on Mono and has > > dependencies many distros don't yet meet. And besides, it doesn't play > > video. Right now I use sound-juicer to play/rip CDs, Muine to play audio > > files, and Totem to play videos; it'll be a while before there's an app > > I'm comfortable using to replace all three, I think. And that's just me, > > who likes modern apps and doesn't mind using mono. There's plenty of > > people out there who still use xmms (and yes, a panel applet could > > support xmms; xmms has console remote-control commands). > > > > If, one day, we have the One True Media Player, it can have its own > > panel applet and we can happily throw this thing in the trashcan. In the > > meantime, I still think it'll be useful... > > Audio and video are quite different. I would not suspect having an > applet for video really all that useful (video needs to be up front so > the controls are always accessible). However having more than one app > for music running at the same time seems like we have bigger issues. > How many people run Minue and xmms at the same time? Sound-juicer is a > different beast and doesn't benefit from having an applet unless of > course you are using it for a cd-player. Which I thought was how it was supposed to be used, at least these days. It certainly beats the stuffing out of gnome-cd. :) > Personally I think RhythmBox > should treat a CD as part of the library if it doesn't already. Right, that would be nice. But still, not everyone is going to use it. It's too 'big' for some people. Too resource intensive for others. Too buggy for still others. And some just don't like its UI. > As I said in an earlier post having one interface design seems good to > me though having one applet that can control all these apps doesn't > sound all that usable (a person would have to configure it among other > things). Having a library to make it easier might also be good but > having the projects agree on one applet interface sounds like the best > option. That would be fine too, though I still don't see why duplicating the code in every application is better than separating it out. If the applet is sufficiently simple there'd be no need to configure it. AFAIK, the current players don't go much beyond play, pause, skip forward, skip back in their current notification-area-icon interfaces; what's to configure there? But yes, these are the things that need to be in the solution, for me: consistency optionalability (er, what I mean is, I can turn it off or move it somewhere else if I want to) If $SOMETHING_ELSE fits these goals and is preferable to a shared applet for code monkey reasons I don't understand, that's perfectly fine. :) -- adamw
Attachment:
signature.asc
Description: This is a digitally signed message part