On 1/11/06, Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote: > And rhythmbox is not the only Fedora audio app. You have totem/helixplayer > which allow someone to play music without importing it in the rhythmbox > db. I have consistently suggested the removal of Helixplayer on what I consider to be strong grounds of duplicate functionality. We can start another thread on this specific topic if you like. Please if anyone has a good technical reason why Helixplayer should continue to be in Core that doesn't invoke an unshippable realmedia codec plugin, please start a side thread. Totem doesn't actually advertise itself as a music player in the menus.. nor in its package description. It advertises itself as a "movie" player. I seriously doubt totem is in the distribution on the strength of its audio playback features. > Just as there is significant overlap between totem and rhythmbox, gimp and > inkscape. In other words, if you simplify the picture too much yes they do > the same thing. inkscape is in Extras and gimp is in Core totem's self-described primary functionality is movie playing and not music. > That's an overly restrictive view, esp when we are not talking about > packages that weight hundreds of megs like openoffice. Or (in the gthumb > case) packages that do not pull in a ton of deps. No.. im talking about the view point of the primary functionality as communicated through mechanisms that users are going to see. Things like the menu entry: Gthumb image viewer (Core) image viewer (eog Core) GQView image viewer (Extras) F-spot photo manager (Core) > It will be soonish. > Most people haven't have the time to accumulate big mounds of photos yet, > because digital cameras are new. My wife has about 8 gigs of photos right now.. i consider that a big mound...and she has chosen on her own to use a mechanism that looks a hell of a lot more like "management" than "browsing." She got so sick of "browsing" that she has resorted to booting into windows to use picasa instead of using gthumb or any other image program available in Fedora Core or Extras because it does a very good job of "managing" and "organizing" photos regardless of location in the diskspace matrix. This isn't the only "not me" user I've watched the usage pattern for. I've had discussions with macusers concerning what they like about iPhoto. The searchable "library" was always something they brought up in the discussion. I honestly have never spoken to anyone... face to face...using any operating system... that had more than 2 gigs of photos that liked browsing photos in a directory/filesystem sense. In my experience talking to "users who are not me" that own and uses a digital camera enough to produce gigs of personal photos has become frustrated with the browse for photos concept and prefer an indexed library approach. > Remember, the average user will only zero his flash when he's forced to, > ie when it's nearly full. I know very well, my wife does this.. and yet she doesn't prefer to "browse".. she prefers to dump and then import into picasa's "library" so she can then "manage" photos into overlapping collections. I seen exactly the usage pattern as an observer and "browsing" is not the chosen technical solution here.. "management" has consistently been the technical solution that the "average user" that I know have reached for. Liberal arts college students to parents with small children.. to retirees with a new fangled digital camera on Alaskan cruises... all have migrated to technical solutions that look a hell of a lot like centralized "management" to index and search their photo collection when they have been given the choice. Now f-spot might really really suck at implementing a good centralized management solution which I'm sure I'll find out is true or not after I introduce my wife to f-spot. But I'm hardpressed to agree with you that "browsing" is what the "average users" I know want to do with their piles of photos. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
