On Fri, 2005-01-21 at 14:14 -0500, Colin Walters wrote:

On Fri, 2005-01-21 at 11:49 -0700, Trever L. Adams wrote:

...

So, why is grip being removed?

Sound Juicer does not yet allow quality selection.

It will; grip is a good candidate for extras.

Will and does are very different. IF it isn't there by FC4, FC4 should include grip. However, I see all critical functionality, and most non- critical, in RhythmBox. xmms uses gtk1 and doesn't seem to be needed; should it be removed?

Trever -- "One Woman can make you fly like an eagle Another can give you the strength of a lion But only One in the cycle of life can fill your heart with wonder And the wisdom that you have known a singular joy." -- Unknown

Second that - lose xmms.

On Tue, 25 Jan 2005 15:14:11 -0500, seth vidal skvidal@phy.duke.edu wrote:

...

Will and does are very different. IF it isn't there by FC4, FC4 should include grip. However, I see all critical functionality, and most non- critical, in RhythmBox. xmms uses gtk1 and doesn't seem to be needed; should it be removed?

Yes, it should. -sv

-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, 2005-01-25 at 22:07 +0100, Enrico Scholz wrote:

tadams-lists@myrealbox.com ("Trever L. Adams") writes:

...

xmms uses gtk1 and doesn't seem to be needed; should it be removed?

No, there is no other nice-looking mp3/ogg/... player in FC.

Enrico

I think xmms is ugly, no matter what theme you put on it. RhythmBox is at least organized in a nice way.

Trever -- "I do not fear computers. I fear the lack of them." -- Isaac Asimov

tis 2005-01-25 klockan 23:03 +0100 skrev Casper Pedersen:

...

I think xmms is ugly, no matter what theme you put on it. RhythmBox is at least organized in a nice way.

Depends on how you see it; xmms is nice, small, and might not be pretty, but it works. RythmBox is big and slow to use with very large collections of files, but it is pretty.

It's a personal opinion, and there should be a choice for all. Sometimes there have to be compromises.

I for example would not be happy to loose Grip and xmms, but then again, I might be old fasion:-)

Regards/Casper

For a Gtk2 replacement of xmms, take a look at Beep Media Player:

http://www.sosdg.org/~larne/w/BMP_Homepage

It's in QA over at livna:

http://bugzilla.livna.org/show_bug.cgi?id=54

mp3 subpackage could be created if it's decided that it replaces xmms, or is included in Extras. It even uses the Bluecurve xmms skin :-)

/Peter

On Tue, 25 Jan 2005 15:14:11 -0500, seth vidal skvidal@phy.duke.edu wrote:

...

Will and does are very different. IF it isn't there by FC4, FC4 should include grip. However, I see all critical functionality, and most non- critical, in RhythmBox. xmms uses gtk1 and doesn't seem to be needed; should it be removed?

Yes, it should.

I'm clueless... but is there an application in Core for playing audio cds that can duplicate xmms's "digital audio extraction" option? I still notice a lot of people who run into this problem when trying to play audio cds and the only application I know in Core that doesn't require the analog audio cable from the cd drive to the sound card is xmms. Right now the best workaround I know of is to use xmms for audio cd playing and configuring xmms to do digital audio extraction instead of analog. Seems gnome's cd player in fc3 doesn't know anything about this which makes keeping xmms somewhat compelling as a cd player even if rhythmbox has equivalent media library capabilities.

-jef"yeah i know.. actually using audio cds instead of ripping them to oggs is sooooo 1990's"spaleta

On Tue, 2005-01-25 at 18:22 -0500, Jeff Spaleta wrote:

I'm clueless... but is there an application in Core for playing audio cds that can duplicate xmms's "digital audio extraction" option? I still notice a lot of people who run into this problem when trying to play audio cds and the only application I know in Core that doesn't require the analog audio cable from the cd drive to the sound card is xmms.

Totem should be able to do that. Even though it's labeled 'Movie player' it plays all kinds of media stuff.

/Per

On Tue, 2005-01-25 at 19:21 -0500, Jeff Spaleta wrote:

On Tue, 25 Jan 2005 17:10:29 -0700, Trever L. Adams tadams-lists@myrealbox.com wrote:

...

For someone who understands gstreamer, this should be a VERY simple plugin to write I would think.

shrug.. i was just pointing out one of the primary reasons i see fc3 users are still using xmms. I'll let other people decide if this is an important enough reason to keep xmms in Core or not. Perhaps the gtk2 based beep can be used instead to fill the same role so that the older gtk libs can be removed from core.

That was my intent, the old libraries would be nice to lose.

And i'm not even sure this is a simple gst plugin fix. Does rhythmbox even play audio cds? Typically what i see happening when novice users try to play cds on their gnome fc3 desktops is gnome-cd will open up and start accessing the audio cd. If their system doesn't have an analog audio connection between the soundcard and the cd unit .... there is no sound.... gnome-cd plays.. but there is no sound. Seems to afflict a number of users who have integrated audio hardware instead of an actual soundcard.. but I can't speak first hand since I don't have any systems with integrated audio. And doing a quick ldd against gnome-cd and i'm not seeing any obvious libgst* references that would indicate gnome-cd is actually using gst at all. So I'm not sure this is an easy gst plugin fix.

-jef

I am afraid you are right, but gnome-cd could be rewritten to use gst framework and play both ways.

Trever -- "There is great value in disaster. All our mistakes are burned up. Thank God we can start anew." -- Thomas Alva Edison, December 9, 1914

On Tue, 25 Jan 2005 23:31:37 -0500, Jeremy Katz katzj@redhat.com wrote:

Aha, looking at the source, it was done but disabled right before the GNOME 2.8 release. Looking in CVS, it looks to be re-enabled [1] for gnome-media 2.9.x (which, since we should be including GNOME 2.10 in FC4, will be included) so we actually should be good on this count for FC4.

if its not disabled again right before release you mean.... mutter, grumble.

hopefully when the gnome-media 2.9.x packages hit rawhide.. someone using the affected hardware will test this to make sure the issue is dead.

-jef"if I had a nickel for every time this 'my cds won't play' issue has come up...."spaleta

On Tue, 2005-01-25 at 19:21 -0500, Jeff Spaleta wrote:

On Tue, 25 Jan 2005 17:10:29 -0700, Trever L. Adams tadams-lists@myrealbox.com wrote:

...

For someone who understands gstreamer, this should be a VERY simple plugin to write I would think.

shrug.. i was just pointing out one of the primary reasons i see fc3 users are still using xmms.

personally, I still use grip because I have all my music sorted neatly into folders with M3U's for each album and xmms lets me just double click the file and play the album.

I really don't like the interface for Rhythmbox.

However, I'd be more than happy to see xmms slip into extras. Assuming Extras is done well it should still be easy to install, and I usually use 3rd party xmms installs anyway because of the lack of MP3 support in FC3.

Rodd.

PS. And I hope this PS doesn't start a riot but I'm going to ask anyway,

I understand and respect Redhats' decision not to include MP3 support due to licensing issues. RHEL is after all a 'paid for' product and the licensing regarding MP3's is somewhat vague.

However, given that Fedora Core is a download only product and that no money is exchanged for it, I can't understand why MP3 support isn't included in FC as the licensing issues for FC shouldn't be an issue.

The only sane reason I can think of is that FC is used as a feeder for RHEL. This concerns me, because if this is the case, then I'm not sure how this whole community process thing for FC is going to work. It seems to me that there is a conflict if the community wants support for MP3 (which FC could have due to it being 'free of charge', or am I wrong) and RH's needs to have FC ready for use in RHEL. This is only one example, but I just wonder how this will be managed in the future as it's more than like that the 'community' will want things included that RHEL doesn't.

Anyhow, I'm tuck my head in and try not to open any more cans of worms (like the whole community participation stuff which has been discussed occassionally on this list ;-] )

Hi

what would be the alternatives? Some Gnome UI crap where half of the important options can be configured with regedit only?

there is no such thing as regedit in gnome. gconf is not even close.

BMP looks good on the first glance (the screenshots); I just hope that it is a 1:1 gtk2 rewrite of xmms, and not something which tries to bring Gnome2 ideas into it (like galeon 1.3 vs. 1.2)...

bmp seems worse than xmms other than looks from the discussions we had previously in this list

===== Regards Rahul Sundaram

__________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

peter.backlund@home.se (Peter Backlund) writes:

...

I looked at rhythmbox and it is catastrophic for simple music listening... a huge window which requires at least the half of my screen width (the minimal window size seems to be 670x293). No way to turn off the window title, no 'pause' control, no control to influence the position within the song, a volume control where 3 small curves show the volume... As said... a typical Gnome2 application which tries to follow blindly a UI guideline without taking care about ergonomic.

http://petrix.se/fedora/rb.png

It has a pause button, it has a slider for controlling position in the songs, and the size of the window is 350x85.

Pause and the slider do not appear until you play a song, which is in line with the UI guidelines.

Oh... I never brought rhythmbox to play a sound -- it segfaulted shortly before (probably related with the gconf error-messages and the failed %post scriptlet).

But: UI guidelines which allow that a start-button becomes a stop-button are crap (probably copied from M$ Windoze). I do not want to count how often I pressed 'stop': there should be silence regardless if I pressed 1, 23 or 42 times the 'stop' button.

Enrico

On Wed, 26 Jan 2005 13:11:26 +0100, Enrico Scholz wrote:

Oh... I never brought rhythmbox to play a sound -- it segfaulted shortly before (probably related with the gconf error-messages and the failed %post scriptlet).

Damn. There are various reports about such incidents with other packages, too. Maybe related. And I think it's still not known under which circumstances gconf post-install scripts fail. When that happens, gconf defaults are not created, and applications which are programmed to not handle missing defaults, give fatal errors or segfault.

The quite common practise to redirect stdout/stderr of scriptlets to /dev/null is not helpful in such cases.

Le mercredi 26 janvier 2005 à 12:12 +0000, Dariusz J. Garbowski a écrit :

and 1280x1024@17" LCD (96 dpi).

A real 1280*960@17" screen is 100dpi (you can do the math if you want). The reason windows is stuck at 96dpi is lots of first-gen 17" makers cheated and their products were either a bit smaller or could not fill all the glass space (you were stuck with a black band around the picture)

At 100dpi AA looks good in all reasonable sizes (I'm not talking about the people that burn their eyes on < 10pt fonts)

Le mercredi 26 janvier 2005 à 12:51 +0000, Dariusz J. Garbowski a écrit :

On 01/26/2005 12:28 PM, Nicolas Mailhot wrote:

...

Le mercredi 26 janvier 2005 à 12:12 +0000, Dariusz J. Garbowski a écrit :

...

and 1280x1024@17" LCD (96 dpi).

A real 1280*960@17" screen is 100dpi (you can do the math if you want).

I did the math ;-) Looks like:

displaysize should be 13.58" x 10.19" (assuming 4:3 display ratio).

Don't assume, measure it yourself ;) What this means of course is not all 17" screens are created equal, and sometimes the manufacturer will round to 17" when it's really a bit smaller.

I have a 17" 322x241 millimeters screen. In 1280*960 thats 101x101 dpi

Regards,

Casper Pedersen wrote:

...

I think xmms is ugly, no matter what theme you put on it. RhythmBox is at least organized in a nice way.

Depends on how you see it; xmms is nice, small, and might not be pretty, but it works. RythmBox is big and slow to use with very large collections of files, but it is pretty.

Personally, I think xmms looks better. It's plain, but displays what it should and doesn't take a lot of screen estate. Rhythmbox is huge, looks really ugly (not exactly itunes in that respect... it manages to be huge and cluttered while not displaying much) and sloooooooow. When trying to add my music collection (5000 songs or so... got way too many CDs), xmms is finished in an instant. Rhythmbox just stays unresponsive for 30 mins using all CPU, not displaying any progress or letting you do anything. Then I just want my system back and puts it out of its misery.

Rhythmbox shouldn't displace better working alternatives until it has gotten useful.

Ivan Gyurdiev wrote:

On Thu, 2005-01-27 at 10:44 +0100, Trond Eivind Glomsrød wrote:

...

Casper Pedersen wrote:

...

Depends on how you see it; xmms is nice, small, and might not be pretty, but it works. RythmBox is big and slow to use with very large collections of files, but it is pretty.

Personally, I think xmms looks better. It's plain, but displays what it should and doesn't take a lot of screen estate.

It has awful skins, does not integrate with the rest of the desktop, and does *not* look better.

Taste differs.

...

it manages to be huge and cluttered while not displaying much)

It's not supposed to be on-screen all the time - you're supposed to choose what to play and minimize it, or run it in mini mode.

I typically just put it on a screen I never visit.

It's a nice browser for music collections. I am just waiting for it to finally integrate with musicbrainz, and support a radio station browser.

I just don't think it does that in a good way...

...

and sloooooooow. When trying to add my music collection (5000 songs or so... got way too many CDs), xmms is finished in an instant.

Does xmms let you search?

Yes.

Does it organize by genre? By album? Does it support drag and drop playlist editing? Radio stations? Does it minimize in the notification area?

Do I like ITunes? Yes. I just happen to think that Rhythmbox does it really badly...

...

Rhythmbox just stays unresponsive for 30 mins using all CPU, not displaying any progress or letting you do anything.

I have about half your collection, and by extrapolating I can tell that this this is a huge exaggeration on any modern machine.

I wish. Unfortunately, I'm not. Maybe its just slower on mp3s? (systems I've tried this on is an Athlon 2200+ and Centrino 1.4 MHz, both with a bit of RAM).

Furthermore you're not supposed to be adding your entire collection every time.

I do it because get fed up and kill it eventually, before it finishes... besides, I would do it often anyway, as I encode new CDs with grip/lame and just think it's easier to add the top dir to scan for new files.

You do that once, so speed is a non-issue.

Not when it is so slow and uninformative that you're convinced it must have crashed.

On Thu, 2005-01-27 at 14:48 +0100, Harald Hoyer wrote:

I did not even manage to import my 6000 files... rhythmbox just hang there after a while doing nothing...

Same here. xmms starts adds 5k files in ~5 seconds and then just works. Jumping works great if files are named "artist-title", and I don't need to enable reading meta-tags in advance.

Trond Eivind Glomsrød wrote:

Personally, I think xmms looks better. It's plain, but displays what it should and doesn't take a lot of screen estate. Rhythmbox is huge, looks really ugly (not exactly itunes in that respect... it manages to be huge and cluttered while not displaying much) and sloooooooow. When trying to add my music collection (5000 songs or so... got way too many CDs), xmms is finished in an instant. Rhythmbox just stays unresponsive for 30 mins using all CPU, not displaying any progress or letting you do anything. Then I just want my system back and puts it out of its misery.

Rhythmbox shouldn't displace better working alternatives until it has gotten useful.

I think we can all agree that no one is against replacing xmms as long as there's a suitable alternative.

Rhythmbox, it sounds, is clearly not that alternative.

Rhythmbox is a media organization program with a built-in player. Xmms is a media player with some organization capability. The focus of the programs are different, so the interface is different. Clearly, neither one is a direct replacement of the other.

Arguments over which one *looks* better are obviously moot--there are enough people on either side of the fence to show that it's simply a matter of taste. If you grew up on Xmms and winamp back in the early days, you'll probably find the Xmms interface perfectly intuitive. If you have a fairly large media collection, you may find Rhythmbox's library-based interface more useful.

So, would there be any serious negative consequences of keeping xmms around until a more suitable replacement could be found? What sort of cost/benefit are we talking about in relation to this change?

On Thu, 27 Jan 2005 09:12:07 -0700, Tyler Larson fedora-devel@tlarson.com wrote:

So, would there be any serious negative consequences of keeping xmms around until a more suitable replacement could be found? What sort of cost/benefit are we talking about in relation to this change?

I think one underlying goal is to get to a point where the underlying gtk1 libraries are no longer needed in core and can be removed. Being able to remove all of the application that are still using the older gtk libs is a much bigger gain over all. If removing the legacy gtk1 libs is an important goal then replacing xmms with the gtk2 based bmp (aka beep) might be a solution which provides close to enough functionality without getting into complicated discussion about the roles specific music applications are providing, since i believe bmp's objective is to be a gtk2 port of xmms. I could be wrong.. someone with experience using both xmms and bmp should comment about how well bmp matches xmms functionality at this point.

If however the goal is to general narrow the number of overlapping applications, thats a tougher discussion, and would have to compare and contrast the music applications in Core across a number of different technical measures...and will end like all of these sorts of discussions end... with a dance dance revolution dance-off between designated champions for each application.

-jef"Core should be including pydance as a community oriented decision making tool"spaleta

Le jeudi 27 janvier 2005 à 11:38 -0500, Dimitrie O. Paun a écrit :

On Thu, Jan 27, 2005 at 11:26:16AM -0500, Jeff Spaleta wrote:

...

I think one underlying goal is to get to a point where the underlying gtk1 libraries are no longer needed in core and can be removed. Being able to remove all of the application that are still using the older gtk libs is a much bigger gain over all.

I beg to differ. I think this is a rather technical argument with zero user benefit.

The non-latin support of gtk2 (vs gtk1) alone is a clear user benefit. So this is *very* far from an abstract argument with no tangible end- user incidence.

And I could easily write a page about gtk1 shortcomings from an end-user POW without even getting into specific xmms problems (that deserve at least a page themselves). I appreciate some people are used to xmms and resigned themselves to its behaviour long ago. That doesn't make it a good app, nor does it mean that someone not exposed to another media player before would chose xmms over rythmbox (which has its own problems, but it's doubtful they are much worse than the problems of xmms and at least rythmbox is still in heavy development and not stagnating like xmms)

On Thu, 2005-01-27 at 12:34 -0500, Bill Nottingham wrote:

Dariusz J. Garbowski (thuforuk@yahoo.co.uk) said:

...

...

It's a database-backed music player, and cannot be compared to xmms, which is totally different.

Therefore is not an alternative nor replacement. It's rather different application class that happens to play music.

Someone mentioned playing a file from filesystem. This is waht I do -- select files or directory from the filesystem and play it. I don't care about database backend.

You may be interested in totem as well.

Totem's a video player. Using it for music doesn't make sense, since it has a screen that doesn't accomplish anything, and you can't get rid of.

On 01/27/2005 05:34 PM, Bill Nottingham wrote:

Dariusz J. Garbowski (thuforuk@yahoo.co.uk) said:

...

...

It's a database-backed music player, and cannot be compared to xmms, which is totally different.

Therefore is not an alternative nor replacement. It's rather different application class that happens to play music.

Someone mentioned playing a file from filesystem. This is waht I do -- select files or directory from the filesystem and play it. I don't care about database backend.

You may be interested in totem as well.

Just tried it again (couldn't use it in any meaningful way on FC2 due to a nasty bug in XOrg 6.7.x that was fixed in 6.8.x).

I'm sorry to report that it crashes on my system (up-to-date FC3 + some additional packages from dag's and other repos) when I select no longer existing "recently used" file: error dialog pops up, CPU usage tops 100% and on totem window close I get bug buddy (which I just used to report this problem).

One more try, this time avoiding "recently used". Selected open file, and in my foolishness chosen bunch of mp3s. Totem went completely berserk! For some reason it started opening endless number of error dialogs reporting that it doesn't know what to do with those files and before I relised it managed to render my desktop into oblivion. I couldn't select any of the open xterms because new dialogs kept grabbing focus, Alt+F4 to close the dialogs was futile. What saved me from hard reboot was logging from my laptop via ssh and kill -9 the evil app.

There must have been dozens if not hundreds of those dialogs because it's taken 45 seconds before the last one vanished from my desktop.

- Why does totem keep opening so many dialogs? - Can it be configured to simply ignore (skip) unknown files without displaying error dialog? (like xmms does) - Why does it try to open last successfully (?) used file on startup? The effect is that when I removed that file totem welcomes me with error dialog stating that it could play that file.

I am afraid that with this kind of bugs it's hardly usable :(

I also agree with Ivan that it feels more like a movie player than generic multimedia player.

I think we may need to look closer at beepmp if we really think of replacing xmms. I can't comment much on it since I used it only for a few hours so far. It feels quite like xmms to me. First missing thing I noticed is no double size feature. I'd like to hear what other users of xmms think about beepmp. Is it ready to replace xmms?

Regards, Dariusz

On Thu, Jan 27, 2005 at 06:26:05PM +0100, Nicolas Mailhot wrote:

The non-latin support of gtk2 (vs gtk1) alone is a clear user benefit. So this is *very* far from an abstract argument with no tangible end- user incidence.

I don't dispute that. But this is all tangential to the main purpose of the freaking thing: to play music. You can get me the best non-latin support, perfect HIG compliance, etc. but it it doesn't do a good job playing music, it can't replace xmms.

And by now it's painfully obvious that rhythmbox is not, by any measure, an acceptable alternative. It works for some, but it's far from working for all. As such, it's just a bad idea to remove xmms at this point. So what are we debating here?

Le jeudi 27 janvier 2005 à 14:21 -0500, Dimitrie O. Paun a écrit :

On Thu, Jan 27, 2005 at 06:26:05PM +0100, Nicolas Mailhot wrote:

...

The non-latin support of gtk2 (vs gtk1) alone is a clear user benefit. So this is *very* far from an abstract argument with no tangible end- user incidence.

I don't dispute that. But this is all tangential to the main purpose of the freaking thing: to play music. You can get me the best non-latin support, perfect HIG compliance, etc. but it it doesn't do a good job playing music, it can't replace xmms.

If you can't even read your playlist because xmms displays garbage, do you really think you'll appreciate the music you can't find ? (and btw xmms is not better at playing music than any other linux player - they all use the same backend libraries for christsakes. In fact the argument could easily be made that xmms is *worse* at playing music - all the stupid badly written eye-candy has been known to load systems enough to cause music skips)

I'm not too fond of the rhythmbox UI myself. I'm the last one who'd say it doesn't have room for improvement. I'll even admit there are some parts of xmms' garbage heap of an ui that are better thought than the rhythmbox one. But even if xmms and rhythmbox were on the same level (and they're not - xmms' few qualities do not redeem its numerous problems) rhythmbox is getting better and xmms - not. Which means xmms will leave FC sooner or later and rhythmbox will stay (till it's relegate to history too). If it doesn't happen in FC4 it'll happen in FC5. So I'll stop loosing my time arguing about it here and let software obsolescence follow its natural course.

My main complaint is that for me is starts leaking memory when I try to add that many songs at once, eventually using up all system resources, and getting killed by the OOM killer. Happens 2/3 times. That is a bug, not normal behavior. I'll file a bugzilla some day when I get sufficiently annoyed.

Its been fixed I believe in the devel version, unfortunately there has been no 0.9 release yet so it a go and get a copy out of arch fix.

P

On Thu, 2005-01-27 at 18:52 -0500, Dimitrie O. Paun wrote:

On Fri, Jan 28, 2005 at 12:40:38AM +0100, Nicolas Mailhot wrote:

...

FC5. So I'll stop loosing my time arguing about it here and let software obsolescence follow its natural course.

Which is the only decent course of action. To argue for xmms' removal *now* because rhythmbox will eventually be as good/better then xmms is just plain silly. And completely non-productive.

just to be clear. We're talking about 'non-productive' in scope of mp3/ogg players? :)

-sv

On Thu, 27 Jan 2005 19:47:33 -0700, Tyler Larson fedora-devel@tlarson.com wrote:

If we were to replace xmms with bmp, I doubt anyone would complain. I doubt anyone would even be able to tell the difference. Plus, we'd be able to get rid of the old gtk1 libs. Everyone wins!

I dont know if xmms is the only thing keeping the old gtk1 libs in. Is it? If it is the only thing in Core that is using the gtk1 stuff that would be a strong reason to take a serious look at bmp as a replacement. Unless of course its deemed that the functionality bmp/xmms needs to be pulled out.

So now there are two questions on the table. Is it worth removing xmms from Core? Thats a tough question... and prone to trench warfare. How about we all install scrotched3d and fight it out until there is a clear winner. Or Is it worth replacing xmms with bmp in Core? I think this is an easier question to answer and has a technical win if this allows for the dropping of the gtk1 libs or gets us a step closer to dropping the gtk1 libs. How about more avid xmms users in this discussion give bmp a try and see if its good enough replacement.

-jef

How about more avid xmms users in this discussion give bmp a try and see if its good enough replacement.

I'd characterize myself as a "resigned" XMMS user rather than an "avid" XMMS user, but I do use it. I think its UI sucks, but I find that it works.

So I tried out BMP, and got nowhere.

1) The fact that it does not have a "double size" option is pretty much a showstopper, because I can't read a damned thing on that sub-postage-stamp-sized window.

2) Perhaps I could fix this by wasting hours finding a less horrid theme to use but A) in five minutes of clicking and googling, I didn't see any easy-to-find collection of BMP themes, and B) I'd really really rather claw out my eyes than dig through those anyway. (Can someone recommend one that isn't totally 'l33t and awful?)

3) and this may be related to "1: can't read the window", I couldn't figure out how to play an Icecast stream at all. xmms has "Play Location" on the menu, BMP does not. Perhaps if I could read the window, the answer would be obvious, but I can't so it's not.

4) "BMP" is a monumentally stupid name (hey, let's name the MP3 player "JPEG"!) and "beep-media-player" is both dumb and too much typing.

So then I tried Totem, and it suffers from the canonical Red Hat braindamage of "oh, you haven't installed the mystery secret MP3 plugin, and no, I won't even hint to you where to find it." Frankly, I can't be bothered to go on this snark hunt again, I've done that enough times.

So, I'd be thrilled to try out an alternative MP3 player to XMMS, just as soon as someone can point me to one that actually plays MP3s!

How about more avid xmms users in this discussion give bmp a try and see if its good enough replacement.

I'd characterize myself as a "resigned" XMMS user rather than an "avid" XMMS user, but I do use it. I think its UI sucks, but I find that it works.

So I tried out BMP, and got nowhere.

1) The fact that it does not have a "double size" option is pretty much a showstopper, because I can't read a damned thing on that sub-postage-stamp-sized window.

2) Perhaps I could fix this by wasting hours finding a less horrid theme to use but A) in five minutes of clicking and googling, I didn't see any easy-to-find collection of BMP themes, and B) I'd really really rather claw out my eyes than dig through those anyway. (Can someone recommend one that isn't totally 'l33t and awful?)

3) and this may be related to "1: can't read the window", I couldn't figure out how to play an Icecast stream at all. xmms has "Play Location" on the menu, BMP does not. Perhaps if I could read the window, the answer would be obvious, but I can't so it's not.

4) "BMP" is a monumentally stupid name (hey, let's name the MP3 player "JPEG"!) and "beep-media-player" is both dumb and too much typing.

So then I tried Totem, and it suffers from the canonical Red Hat braindamage of "oh, you haven't installed the mystery secret MP3 plugin, and no, I won't even hint to you where to find it." Frankly, I can't be bothered to go on this snark hunt again, I've done that enough times.

So, I'd be thrilled to try out an alternative MP3 player to XMMS, just as soon as someone can point me to one that actually plays MP3s!

Hi

So then I tried Totem, and it suffers from the canonical Red Hat braindamage of "oh, you haven't installed the mystery secret MP3 plugin, and no, I won't even hint to you where to find it." Frankly, I can't be bothered to go on this snark hunt again, I've done that enough times.

thats not a redhat stupidity. its patent issues over mp3 and pointing out where to find it is a potential patent and DMCA violation for redhat to do

===== Regards Rahul Sundaram

__________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

Hi

You may be interested in totem as well.

Bill

though totem is a media player, its generally thought of as a video player and many people install winamp to hear songs in windows instead of using windows media player for similar reasons. totem as a integrated all in one media player will not much acceptance from the users for many use cases

===== Regards Rahul Sundaram

__________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

On Thu, 27 Jan 2005 22:28:29 -0800, Jamie Zawinski wrote:

So then I tried Totem, and it suffers from the canonical Red Hat braindamage of "oh, you haven't installed the mystery secret MP3 plugin, and no, I won't even hint to you where to find it." Frankly, I can't be bothered to go on this snark hunt again, I've done that enough times.

Totem uses GStreamer, and hence gstreamer-plugins-mp3 from the same old http://rpm.livna.org repository works just fine.

So, I'd be thrilled to try out an alternative MP3 player to XMMS, just as soon as someone can point me to one that actually plays MP3s!

Amarok (KDE application) as provided in Fedora pre-Extras is quite nice, but needs kdemultimedia-extras as provided by rpm.livna.org before it would play mp3s.

--- Jamie Zawinski jwz@jwz.org wrote:

Rahul Sundaram wrote:

...

thats not a redhat stupidity. its patent issues

over mp3

You know what? Trying to care; failing.

ok. you dont have to care but finding fault with redhat when there is none is a bad thing to do. how do you expect them to resolve the mp3 issue. you tell me

===== Regards Rahul Sundaram

__________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

On Thu, 27 Jan 2005 22:28:29 -0800, Jamie Zawinski jwz@jwz.org wrote:

1. The fact that it does not have a "double size" option is pretty much a showstopper, because I can't read a damned thing on that sub-postage-stamp-sized window.

I Personally don't consider this a showstopper, but it would be interesting to know if the bmp developers have this feature or similar functionality on their development roadmap.

2. Perhaps I could fix this by wasting hours finding a less horrid theme to use but A) in five minutes of clicking and googling, I didn't see any easy-to-find collection of BMP themes, and B) I'd really really rather claw out my eyes than dig through those anyway. (Can someone recommend one that isn't totally 'l33t and awful?)

bmp's website has a menu entry for skins here's the url http://www.sosdg.org/~larne/w/Skins I think bmp is designed to use most if not all of the available xmms themes out there. So pick your fav xmms theme and drop it into bmp's Skins directory. And the 'default is crap' issue is a red herring, because "if" its going to be re-packaged for core, I'm sure the bluecurve xmms theme core is now using would be used for bmp... which works just fine for bmp from what i can tell.

3. and this may be related to "1: can't read the window", I couldn't figure out how to play an Icecast stream at all. xmms has "Play Location" on the menu, BMP does not. Perhaps if I could read the window, the answer would be obvious, but I can't so it's not.

At the moment this is available functionality in the playlist window, as an 'add' option. We'd have to peek into bmp development discussions to see if there are plans and interest to place this functionality back into the

4. "BMP" is a monumentally stupid name (hey, let's name the MP3 player "JPEG"!) and "beep-media-player" is both dumb and too much typing.

No Comment.

-jef

fre 2005-01-28 klockan 08:20 -0500 skrev Jeff Spaleta:

On Thu, 27 Jan 2005 22:28:29 -0800, Jamie Zawinski jwz@jwz.org wrote:

...

1. The fact that it does not have a "double size" option is pretty much a showstopper, because I can't read a damned thing on that sub-postage-stamp-sized window.

I Personally don't consider this a showstopper, but it would be interesting to know if the bmp developers have this feature or similar functionality on their development roadmap.

Right-click the clock area, or click the down-arrow in the upper left corner of the player for a context menu.

...

2. Perhaps I could fix this by wasting hours finding a less horrid theme to use but A) in five minutes of clicking and googling, I didn't see any easy-to-find collection of BMP themes, and B) I'd really really rather claw out my eyes than dig through those anyway. (Can someone recommend one that isn't totally 'l33t and awful?)

bmp's website has a menu entry for skins here's the url http://www.sosdg.org/~larne/w/Skins I think bmp is designed to use most if not all of the available xmms themes out there. So pick your fav xmms theme and drop it into bmp's Skins directory. And the 'default is crap' issue is a red herring, because "if" its going to be re-packaged for core, I'm sure the bluecurve xmms theme core is now using would be used for bmp... which works just fine for bmp from what i can tell.

Yes, it works fine with the Bluecurve xmms skin. There is an environment variable that lists additional directories to look for skins in, which conveniently contains /usr/share/xmms/Skins in the livna.org package (through an /etc/profile.d/ file), so that the BC skin can be used immediately. Same goes for the Industrial skin, from ximian- artwork.

...

3. and this may be related to "1: can't read the window", I couldn't figure out how to play an Icecast stream at all. xmms has "Play Location" on the menu, BMP does not. Perhaps if I could read the window, the answer would be obvious, but I can't so it's not.

At the moment this is available functionality in the playlist window, as an 'add' option. We'd have to peek into bmp development discussions to see if there are plans and interest to place this functionality back into the

...

4. "BMP" is a monumentally stupid name (hey, let's name the MP3 player "JPEG"!) and "beep-media-player" is both dumb and too much typing.

Well, if you run a reasonably modern shell such as bash or zsh, you could type "be" and then press tab to automatically complete to "beep- media-player". You may need to supply a few additional letters, if you have more than one binary in your $PATH beginning with "be".

/Peter

Tyler Larson wrote:

Except, of course, the gnome open-file dialog box. Makes me angry every time I see it. Grrr.

I would like to start a flame war because of this *grins evil* , but this has been discussed enough internal and external.

On Fri, 28 Jan 2005 14:56:22 +0100, Peter Backlund wrote:

Yes, it works fine with the Bluecurve xmms skin. There is an environment variable that lists additional directories to look for skins in, which conveniently contains /usr/share/xmms/Skins in the livna.org package (through an /etc/profile.d/ file), so that the BC skin can be used immediately. Same goes for the Industrial skin, from ximian- artwork.

Would be good if something like this could be added to the profile.d:

skin=$(gconftool-2 --get /apps/bmp/skin 2> /dev/null) if [ -z "$skin" -a -f /usr/share/xmms/Skins/Bluecurve-xmms.zip ]; then gconftool-2 --set /apps/bmp/skin --type string \ /usr/share/xmms/Skins/Bluecurve-xmms.zip &> /dev/null fi

What it does is to make the Bluecurve skin the default if user has not set a different one already.

On Fri, 2005-01-28 at 08:25 -0600, Chris Adams wrote:

Once upon a time, Rahul Sundaram rahulsundaram@yahoo.co.in said:

...

I do. Fedora core should only include one default program for each kind of task overall. there might be a few exceptions like including say nano as well as vim but having 5 different browsers and calling in fedora "core" doesnt make any sense at all

The #1 objective of Fedora Core is "Create a complete general-purpose operating system with capabilities equivalent to competing operating systems". There is _nothing_ in the objectives about providing a minimal OS that pushes all the optional packages to Fedora Extras.

Right. "Operating System." XMMS is not part of an OS, it's an application that nobody strictly needs. You don't need to put XMMS in Fedora Core in order for Core to use or run XMMS, and its removal will not reduce Core's audio capabilities in the least.

It seems that a lot is being read into the word "Core" in the distribution that is not meant (at least according to the Fedora website).

It also seems that some people want to push every package they don't personally use 20 times a day to Extras, despite the fact that many others use those packages and that there are not always good alternatives in the distribution.

Quite a few of us would like to see software we do personally use pushed to Extras. I use Epiphany over Firefox, for example, but if Firefox is the official Fedora Browser, then I want Epiphany in Extras. That would in no way stop me from using Epiphany, since I could just install it from Extras. The impact on my life by moving Epiphany is essentially nil, but it does result in a smaller, leaner, easier to manage, faster to download _Operating System_ for others.

-- Chris Adams cmadams@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

On Fri, 2005-01-28 at 16:52 +0100, Harald Hoyer wrote:

Sean Middleditch wrote:

...

Right. "Operating System." XMMS is not part of an OS, it's an application that nobody strictly needs. You don't need to put XMMS in Fedora Core in order for Core to use or run XMMS, and its removal will not reduce Core's audio capabilities in the least.

hmm, OS... let's deliver the kernel only, the rest is just bloat :)

Sounds like a plan. Though maybe we should throw in the boot loader, too. I think those together plus the initial ramdisk should be enough for most Linux users. They can grab auxillary things like binutils and rpm from Extras. ~_^

Manual system bootstrapping is k00l.

Sean Middleditch wrote:

On Fri, 2005-01-28 at 16:52 +0100, Harald Hoyer wrote:

...

Sean Middleditch wrote:

...

Right. "Operating System." XMMS is not part of an OS, it's an application that nobody strictly needs. You don't need to put XMMS in Fedora Core in order for Core to use or run XMMS, and its removal will not reduce Core's audio capabilities in the least.

hmm, OS... let's deliver the kernel only, the rest is just bloat :)

Sounds like a plan. Though maybe we should throw in the boot loader, too. I think those together plus the initial ramdisk should be enough for most Linux users. They can grab auxillary things like binutils and rpm from Extras. ~_^

Manual system bootstrapping is k00l.

Bootloader? Think "boot disk"! :)

Sean Middleditch wrote:

On Fri, 2005-01-28 at 17:04 +0100, Harald Hoyer wrote:

...

Bootloader? Think "boot disk"! :)

The PPC users might have an issue with that. ;-)

PPC? Bloat! :-)

On Fri, 2005-01-28 at 17:15 +0100, Harald Hoyer wrote:

Sean Middleditch wrote:

...

On Fri, 2005-01-28 at 17:04 +0100, Harald Hoyer wrote:

...

Bootloader? Think "boot disk"! :)

The PPC users might have an issue with that. ;-)

PPC? Bloat! :-)

Hmm, good point. You know, now that I think on it, the kernel itself is pretty big. Got a lot of them drivers in it. Nobody needs all of 'em. I say we compile all drivers as modules and put them all in Extras, too.

Then we should be able to ship Fedora Core on a 5,1/4" floppy.

(This joke is getting stale, isn't it? ~_^ )

fre 2005-01-28 klockan 09:17 -0700 skrev Ivan Gyurdiev:

...

Quite a few of us would like to see software we do personally use pushed to Extras.

Hi, I haven't been following this discussion, but I'd like to say that I don't want to see software I use pushed to extras due to the fact that Extras is not sync-ed to Rawhide. I am a rawhide beta tester, and extras is a pain for me to use. Do you know what kind of hackery is required to get the Nvidia driver from livna properly installed on a rawhide system? That's because Livna, like extras, is not sync-ed to rawhide.

Would you mind sharing exactly what you had to do? Or perhaps open a bug on bugzilla.livna.org.

P.S. Speaking of the Nvidia driver, will somebody please consider splitting xorg-x11-Mesa-libGL-devel and xorg-x11-Mesa-libGLU-devel in their own packages where they belong. I tried discussing this with the maintainer, but he disappeared in the middle of the discussion and the bug was left unresolved, pending FC4, which makes no sense to me.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145287

I'm not 100% sure of how runtime linking works, but if you look at a binary like /usr/X11R6/bin/glxgears, it links to the Nvidia libraries when they are installed through the livna.org package, like this:

[peter@localhost]~% ldd /usr/X11R6/bin/glxgears libGL.so.1 => /usr/lib/nvidia/libGL.so.1 (0x4a8b4000) libGLcore.so.1 => /usr/lib/nvidia/libGLcore.so.1 (0x4a16d000) libnvidia-tls.so.1 => /usr/lib/nvidia/tls/libnvidia-tls.so.1 (0x4a8b0000)

This is accomplished by a file in /etc/ld.so.conf.d/ making libGL* load from /usr/lib/nvidia/ first.

AFAIK there are no OpenGL applications in FC that don't pick up the Nvidia libGL.so.1 when it's installed via the livna.org rpms.

/Peter

On Fri, 28 Jan 2005 09:54:29 -0700, Ivan Gyurdiev ivg2@cornell.edu wrote:

Furthermore the driver distributed is not patched for well-known bugs with the patches here: http://www.minion.de/files/1.0-6629/

Or you can work with the livna packager.. to get those patches integrated into the livna rpm. I doubt competent help wouldn't be turned away. thanks for volunteering to help with the packaging effort.

-jef

• some sort of alternatives system or post-install scripts to find correct provider of libGL.so.1

That should be libGL.so.

Let me demonstrate. After today's X upgrades:

[root@cobra phantom]# rpm -q --whatprovides libGL.so.1 nvidia-glx-1.0.6629-0.lvn.3.3 [root@cobra phantom]# rpm -qf /usr/lib/libGL.so xorg-x11-devel-6.8.1.902-7 [root@cobra phantom]# ls -l /usr/lib/libGL.so lrwxrwxrwx 1 root root 28 Jan 28 09:43 /usr/lib/libGL.so -

../../usr/X11R6/lib/libGL.so

[root@cobra phantom]# ls -l /usr/X11R6/lib/libGL.so lrwxrwxrwx 1 root root 12 Jan 28 09:43 /usr/X11R6/lib/libGL.so -> libGL.so.1.2 [root@cobra phantom]# ls -l /usr/X11R6/lib/libGL.so.1.2 ls: /usr/X11R6/lib/libGL.so.1.2: No such file or directory [root@cobra phantom]# ld -lGL ld: cannot find -lGL [root@cobra phantom]# ln -sf /usr/lib/nvidia/libGL.so /usr/lib/libGL.so [root@cobra phantom]# cd /usr/include/GL [root@cobra GL]# mv gl.h glx.h glx.h glxext.h glxint.h glxmd.h glxproto.h glxtokens.h osmesa.h mesa -f mv: cannot stat `glx.h': No such file or directory [root@cobra GL]# ln -sf /usr/include/nvidia/GL/* . [root@cobra GL]# cd /usr/X11R6/lib [root@cobra lib]# mv libGL.* libOSMesa* mesa -f [root@cobra lib]# ldconfig bash: ldconfig: command not found [root@cobra lib]# /sbin/ldconfig [root@cobra lib]# ld -lGL ld: warning: cannot find entry symbol _start; not setting start address [root@cobra lib]# rm -f a.out

Repeat this every time X is upgraded or don't upgrade X.

On Fri, 2005-01-28 at 11:00 -0600, Rex Dieter wrote:

Ivan Gyurdiev wrote:

...

Really to resolve this the following is needed:

• updated livna nvidia package to include more patches

agreed. I'd suggested poking at bugzilla.livna.org

All right, maybe I will. I like focusing on one bug at a time. Currently I'm messing with SElinux stuff.

...

• Livna.org sync-ed against Rawhide.

It's not too hard for rawhide'rs to 'rpmbuild --rebuild'. is it?

Well had the livna package been patched I suppose I could do that. That creates incentive to help get it patched :)

...

• updated xorg-x11 packaging to separate the Mesa GL stuff
• some sort of alternatives system or post-install scripts to find correct provider of libGL.so.1

Why are these necessary? Just because you don't like the fact they're merely installed, but not used?

No - because they prevent building things against libGL. libGL.so.1 is a typo - should have been libGL.so - see other mail for detail.

I doubt competent help wouldn't be turned away.

Well, if that's the Fedora way then I'm surprised it has gotten this far :) I get what you mean though.

fre 2005-01-28 klockan 10:07 -0700 skrev Ivan Gyurdiev:

...

• some sort of alternatives system or post-install scripts to find correct provider of libGL.so.1

That should be libGL.so.

Let me demonstrate. After today's X upgrades:

[snip]

[root@localhost ~]# rpm -qa *nvidia* *Mesa* kernel-module-nvidia-2.6.10-1.741_FC3-1.0.6629-0.lvn.6 kernel-module-nvidia-2.6.9-1.724_FC3-1.0.6629-0.lvn.6 xorg-x11-Mesa-libGLU-6.8.1-12.FC3.21 xorg-x11-Mesa-libGL-6.8.1-12.FC3.21 nvidia-glx-1.0.6629-0.lvn.6 nvidia-glx-devel-1.0.6629-0.lvn.6

Both nvidia-glx and Mesa are installed.

Follow libGL.so:

[root@localhost ~]# ls -l /usr/lib/libGL.so lrwxrwxrwx 1 root root 28 5 jan 18.41 /usr/lib/libGL.so -

../../usr/X11R6/lib/libGL.so

[root@localhost ~]# ls -l /usr/X11R6/lib/libGL.so lrwxrwxrwx 1 root root 12 5 jan 18.41 /usr/X11R6/lib/libGL.so -> libGL.so.1.2

[root@localhost ~]# ls -l /usr/X11R6/lib/libGL.so.1.2 -rwxr-xr-x 1 root root 474388 1 dec 08.36 /usr/X11R6/lib/libGL.so.1.2

Now, a test program that links to libGL:

[root@localhost ~]# cat test.c #include <GL/gl.h> #include <GL/glx.h>

int main() { return 0; }

Compile and look for runtime providers (snipped for brevity):

[root@localhost ~]# gcc test.c -lGL [root@localhost ~]# ldd a.out libGL.so.1 => /usr/lib/nvidia/libGL.so.1 (0x4a8b4000) libGLcore.so.1 => /usr/lib/nvidia/libGLcore.so.1 (0x4a16d000) libnvidia-tls.so.1 => /usr/lib/nvidia/tls/libnvidia-tls.so.1 (0x4a8b0000)

What's the problem with this setup?

/Peter

On Fri, 2005-01-28 at 18:26 +0100, Peter Backlund wrote:

fre 2005-01-28 klockan 10:07 -0700 skrev Ivan Gyurdiev:

...

...

• some sort of alternatives system or post-install scripts to find correct provider of libGL.so.1

That should be libGL.so.

Let me demonstrate. After today's X upgrades:

[snip]

[root@localhost ~]# rpm -qa *nvidia* *Mesa* kernel-module-nvidia-2.6.10-1.741_FC3-1.0.6629-0.lvn.6 kernel-module-nvidia-2.6.9-1.724_FC3-1.0.6629-0.lvn.6 xorg-x11-Mesa-libGLU-6.8.1-12.FC3.21 xorg-x11-Mesa-libGL-6.8.1-12.FC3.21 nvidia-glx-1.0.6629-0.lvn.6 nvidia-glx-devel-1.0.6629-0.lvn.6

Both nvidia-glx and Mesa are installed.

Try this: glxinfo|grep version

Are the versions the same?

fre 2005-01-28 klockan 10:28 -0700 skrev Ivan Gyurdiev:

On Fri, 2005-01-28 at 18:26 +0100, Peter Backlund wrote:

...

fre 2005-01-28 klockan 10:07 -0700 skrev Ivan Gyurdiev:

...

...

• some sort of alternatives system or post-install scripts to find correct provider of libGL.so.1

That should be libGL.so.

Let me demonstrate. After today's X upgrades:

[snip]

[root@localhost ~]# rpm -qa *nvidia* *Mesa* kernel-module-nvidia-2.6.10-1.741_FC3-1.0.6629-0.lvn.6 kernel-module-nvidia-2.6.9-1.724_FC3-1.0.6629-0.lvn.6 xorg-x11-Mesa-libGLU-6.8.1-12.FC3.21 xorg-x11-Mesa-libGL-6.8.1-12.FC3.21 nvidia-glx-1.0.6629-0.lvn.6 nvidia-glx-devel-1.0.6629-0.lvn.6

Both nvidia-glx and Mesa are installed.

Try this: glxinfo|grep version

Are the versions the same?

No:

[peter@localhost]~% glxinfo| grep version server glx version string: 1.2 client glx version string: 1.3 OpenGL version string: 1.2 (1.5 Mesa 6.1) glu version: 1.3

What problems would that create? I've played a number of OpenGL games, such as Quake3 and Doom3, and never seen any glitches in them or in any screensaver, and I always keep Mesa installed btw.

Could you provide a real-world example of code that does not build and run the way you want it, so that I can test it?

/Peter

fre 2005-01-28 klockan 18:40 +0100 skrev Peter Backlund:

fre 2005-01-28 klockan 10:28 -0700 skrev Ivan Gyurdiev:

...

On Fri, 2005-01-28 at 18:26 +0100, Peter Backlund wrote:

...

fre 2005-01-28 klockan 10:07 -0700 skrev Ivan Gyurdiev:

...

...

• some sort of alternatives system or post-install scripts to find correct provider of libGL.so.1

That should be libGL.so.

Let me demonstrate. After today's X upgrades:

[snip]

[root@localhost ~]# rpm -qa *nvidia* *Mesa* kernel-module-nvidia-2.6.10-1.741_FC3-1.0.6629-0.lvn.6 kernel-module-nvidia-2.6.9-1.724_FC3-1.0.6629-0.lvn.6 xorg-x11-Mesa-libGLU-6.8.1-12.FC3.21 xorg-x11-Mesa-libGL-6.8.1-12.FC3.21 nvidia-glx-1.0.6629-0.lvn.6 nvidia-glx-devel-1.0.6629-0.lvn.6

Both nvidia-glx and Mesa are installed.

Try this: glxinfo|grep version

Are the versions the same?

Actually, I was running the nv driver. With the nvidia driver, I have the same version:

[peter@localhost ~]$ glxinfo | grep version server glx version string: 1.3 client glx version string: 1.3 OpenGL version string: 1.5.2 NVIDIA 66.29 glu version: 1.3

/Peter

Ivan Gyurdiev wrote:

...

nvidia should *not* be the provider for libGL.so, but MesaGL. Else you end up with binaries that work only on/for nvidia users.

You fail to see that libGL.so is a dead link on systems which don't have Mesa GL installed.

But Mesa GL *should* be installed if you intend to compile anything. That's the point.

So, requiring me to go install Mesa GL is already a bug.

I fail to see how/why requiring MesaGL to compile anything is a bug.

rpm -ql xorg-x11-Mesa-libGL* -p

/usr/X11R6/lib/libGL.so.1 /usr/X11R6/lib/libGL.so.1.2 /usr/lib/libGL.so.1

How is this supposed to work? /usr/lib/libGL.so.1 takes precedence over the nvidia folder with the same lib.

...

Even if it didn't, relying on which libGL.so.1 came first seems like a very fragile setup. I recall redirecting that link,

The nvidia folder is supposed to take precedence at runtime. That is how it is *supposed* to work.

Fragile or not, it works for most folks, and is certainly better than what the nvidia installer does.

-- Rex

Ivan Gyurdiev wrote:

Why would you split a library off from xorg-x11, but not split the headers?

As I said previously, the MesaGL .so link and headers are required, else you end up with proprietary-ized binaries that work *only* when the nvidia GL libs are installed. MesaGL-linked binaries wor on both MesaGL and Nvidia-GL (supposedly) systems.

I say (supposedly) because I don't have/use NVidia cards myself, but I've heard enough success stories from reputable sources to trust the conclusion.

-- Rex

On Fri, 2005-01-28 at 11:56 -0600, Rex Dieter wrote:

Ivan Gyurdiev wrote:

...

Why would you split a library off from xorg-x11, but not split the headers?

As I said previously, the MesaGL .so link and headers are required, else you end up with proprietary-ized binaries that work *only* when the nvidia GL libs are installed. MesaGL-linked binaries wor on both MesaGL and Nvidia-GL (supposedly) systems.

I say (supposedly) because I don't have/use NVidia cards myself, but I've heard enough success stories from reputable sources to trust the conclusion.

I am installing xorg-x11-devel and Mesa-libGL right now to test this "supposedly," because I am almost positive something will break. Will let you know in 10 mins.

In the mean time, why is xorg-x11-devel not requiring xorg-x11-Mesa- libGL if your claim that it's required is true. If it required the Mesa package it wouldn't be able to install a dead link without consequence. Every other -devel package on Fedora seems to require the parent package.

[phantom@cobra ~]$ rpm -q libgtop2-devel --requires glib2-devel >= 2.0.1 libgtop2 = 2.8.0 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 [phantom@cobra ~]$ rpm -q libpng-devel --requires /bin/sh libpng = 2:1.2.8 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 zlib-devel [phantom@cobra ~]$ rpm -q libmng-devel --requires libjpeg-devel libmng = 1.0.8 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 [phantom@cobra ~]$

Rahul Sundaram wrote:

--- Jamie Zawinski jwz@jwz.org wrote:

...

Rahul Sundaram wrote:

...

thats not a redhat stupidity. its patent issues

over mp3

You know what? Trying to care; failing.

ok. you dont have to care but finding fault with redhat when there is none is a bad thing to do. how do you expect them to resolve the mp3 issue. you tell me

So out of curiosity, how do Suse and Mandrake deal with this issue ?

-d

On Fri, 2005-01-28 at 11:56 -0600, Rex Dieter wrote:

Ivan Gyurdiev wrote:

...

Why would you split a library off from xorg-x11, but not split the headers?

As I said previously, the MesaGL .so link and headers are required, else you end up with proprietary-ized binaries that work *only* when the nvidia GL libs are installed. MesaGL-linked binaries wor on both MesaGL and Nvidia-GL (supposedly) systems.

I say (supposedly) because I don't have/use NVidia cards myself, but I've heard enough success stories from reputable sources to trust the conclusion.

Allright. I tested this, it works, so I'll admit you're all right, I'm wrong, and from what I've learned from this discussion I even know exactly why - it has to do with symlinks, linker path precedence, and the nvidia script installer, it's not important.

Conclusions: =============

- Mesa-libGL can work alongside nvidia-glx, and should be installed if I am to build against libGL or it doesn't work at all.

- I should stay away from the nvidia installer, use only livna packages, and rebuild against rawhide.

What needs to be done: ======================

- The -devel package should not install dead links on my system - it should require Mesa-libGL.

- I still say the libGL devel stuff and libGLU should be split from xorg-x11-devel.

- livna needs to be patched for memory leak bug, and other bugs. Patches at www.minion.de/files/1.0-6629/.

- There should be a rawhide-sync'ed livna and extras, and not having them makes moving packages to extras evil.

- SElinux strict policy bug with /etc/udev/devices to be fixed...

Anything else I'm missing?

...

• I still say the libGL devel stuff and libGLU should be split from

xorg-x11-devel.

You keep saying that. But, why? There is no other/alternative GL implementation in Core or Extras (Nvidia's doesn't/shouldn't count in this discussion).

Why do you keep saying that Nvidia's does not count. What exactly is the problem with their GL headers/library?

On the other hand, I thought one of Mike's original motivations for splitting off Mesa-GL was to allow for drop-in replacements. I'm not sure if there is value anymore in packaging these separately.

I heard X will be modularized for FC5 so all libraries will be split up like that. Is that not the case?

On Fri, 28 Jan 2005 13:46:55 -0700, Ivan Gyurdiev ivg2@cornell.edu wrote:

Why do you keep saying that Nvidia's does not count. What exactly is the problem with their GL headers/library?

nvidia's implements their own extentions to opengl. If you build an application against nvidia's headers and libraries it will most likely not work against other opengl implementations such as mesa. You end up compiling programs that need nvidia's libs... and that's burned a few community packagers in the past using system with nvidia drivers installed via nvidia's installer and then trying to hand those packages over to people using non-nvidia hardware. A fun time was had by all. If you compile against the mesa opengl headers and libs... you can run those applications with nvidia's implementation via runtime detection of the nvidia libraries.

But don't take my word for it.. take a some opengl opensource apps and build them using the nvidia headers and libraries.. package them up... give it to someone who runs accelerated non-nvidia 3d hardware and watch as those apps breaks on the non-nvidia hardware.

-jef"i guess there is a reason why history is doomed to repeat itself"spaleta

On Fri, 28 Jan 2005 14:55:28 -0600 (CST), Rex Dieter rdieter@math.unl.edu wrote:

...

I heard X will be modularized for FC5 so all libraries will be split up like that. Is that not the case?

Where did you hear that? So it's going to get even more complicated?

i've been hearing mharris wax eloquent about moving away from the 'monolithic' approach to modular pieces for X related libraries for a while now. Catching him when he's actually using eloquent speech however is a refined skill that takes much practice. I'm pretty sure modularization is on X.org's development roadmap moving foward.. but i'm not sure its wise to give a timeline as to when its ready. I have no idea what state the effort is in i dont keep up with xorg related mailinglists.

-jef

On Fri, 28 Jan 2005 14:08:58 -0700, Ivan Gyurdiev ivg2@cornell.edu wrote:

Does 'extensions' not imply that they're optional? If you don't use extensions would it break?

you would think that... but as soon as you build applications against the nvidia headers.. you see such a rational thought contradicts reality. Building the apps exactly the same way with exactly the same compile time options...gives you exactly what you don't want.. binaries tied to nvidia's libs.

How do you make use of the Nvidia extensions with the Mesa headers?

You dont.

if you really really really want to tie your binary to the existence of nvidia hardware and libs.. you use nvidia's headers and libs at compile time. And with livna's rpms you can do exactly that by setting appropriate -L and -I to point to the nvidia libs and headers when you are building/linking at compile time. This however is seldom something a community contributor wants to do.

I think at this point... your questions are best answered by rebuilding sourcecode into binaries for yourself and watching the truth unfold. Or digging into archives and into old bugtickets that have gone over exact this same ground with community packagers.

-jef

Michael Schwendt (fedora@wir-sind-cool.org) said:

On Fri, 28 Jan 2005 14:56:22 +0100, Peter Backlund wrote:

...

Yes, it works fine with the Bluecurve xmms skin. There is an environment variable that lists additional directories to look for skins in, which conveniently contains /usr/share/xmms/Skins in the livna.org package (through an /etc/profile.d/ file), so that the BC skin can be used immediately. Same goes for the Industrial skin, from ximian- artwork.

Would be good if something like this could be added to the profile.d:

skin=$(gconftool-2 --get /apps/bmp/skin 2> /dev/null) if [ -z "$skin" -a -f /usr/share/xmms/Skins/Bluecurve-xmms.zip ]; then gconftool-2 --set /apps/bmp/skin --type string \ /usr/share/xmms/Skins/Bluecurve-xmms.zip &> /dev/null fi

What it does is to make the Bluecurve skin the default if user has not set a different one already.

There's a suitably gross make-bluecurve-the-default skin patch in xmms. Depending on which bits of the xmms architecture they kept, it may apply (haven't looked at bmp.)

Bill

Le vendredi 28 janvier 2005 à 14:55 -0600, Rex Dieter a écrit :

On Fri, 28 Jan 2005, Ivan Gyurdiev wrote:

...

I heard X will be modularized for FC5 so all libraries will be split up like that. Is that not the case?

Where did you hear that? So it's going to get even more complicated?

Xorg people want to unbundle the big pile of code they inherited from XFree86, so they don't have to ship anymore copies of other people stuff (fontconfig, mesa, xterm...), it builds using mainstream autoconf* scripts, drivers can be released as a different pace than the core package (so no full rebuild each time you need to add a new card), etc

It means packaging will probably get easier because you won't have an enormous srpm that generates scores of packages (with a large part of the big archive content disable to use system libraries instead) but lots of different source archives.

I doubt they manage to pull it out for FC5 though - it's an enormous task and all the OS are not created equal (some do not have their own fontconfig module...), so some port maintainers push for keeping an unified blob.

Regards,

fedora@wir-sind-cool.org (Michael Schwendt) writes:

...

There's a suitably gross make-bluecurve-the-default skin patch in xmms. Depending on which bits of the xmms architecture they kept, it may apply (haven't looked at bmp.)

Had a look. Doesn't apply. But this one does and works, too, because the skin loader falls back to the "Default" skin if Bluecurve skin isn't found.

bmp-0.9.7-default-skin.patch

I hope, this would not reopen https://bugzilla.redhat.com/beta/show_bug.cgi?id=71009

Enrico

Michael Schwendt wrote:

Totem uses GStreamer, and hence gstreamer-plugins-mp3 from the same old http://rpm.livna.org repository works just fine.

Ok, now that Totem can play MP3s, it seems not-totally-unacceptable, but it's still inferior to xmms/bmp in several ways:

- It uses a *huge* amount of CPU. When I was running xmms or bmp, my load was hovering around 0.6; Totem makes it oscillate between 2.8 and 3.8!

- When listening to an icecast stream, there is no indication of what URL you are actually listening to ("Movie/Properties" doesn't show anything.)

- Likewise, no metadata at all - no channel or song titles.

- I don't see a way to turn off the big black "movie display" window.

Jeff Spaleta wrote:

And the 'default is crap' issue is a red herring, because "if" its going to be re-packaged for core, I'm sure the bluecurve xmms theme core is now using would be used for bmp... which works just fine for bmp from what i can tell.

BMP is not so bad with the bluecurve-xmms theme, but it's still way, way too small. You must have either bigger pixels or much better eyes than I do, because I just can't read five-point light-gray-on-white type. (Maybe it would work to just double the size of all the image-files in the theme, if a "Double Size" option isn't to be implemented?)

BMP also has the problem that when you have an Icecast URL in the playlist window, there's no way to tell what its URL is -- all it will show you is the last title or metadata the stream had, so you know the last song you heard on it, but not what station it is.

So, if you want to ditch XMMS, I think some hacking is still needed. Neither of these programs quite cut it yet. (And I don't think I'm making power-user requests here or anything, these are just basic usability regressions.)

Jeff Spaleta wrote:

Thanks for volunteering to help the bmp developers work through the remaining usability issues.

Yes, by all means, let's improve the Linux user experience by replacing working tools with half-working tools.

On Thu, 2005-01-27 at 23:23 -0700, Tyler Larson wrote:

Rodd Clarkson wrote:

Lets face it, if we're really interested in shrinking the size of the distro, cutting a few packages like XMMS isn't going to make a spit of difference. Not even eliminating unused packages is going to do much good.

Sure xmms is small, but it's about 4.8M of RPMS (including devel, flac and skins) On top of this is requires the GTK-1.x libraries so assuming not a lot else uses these libraries you're another step towards not needing them in core anymore.

And while 4.8M doesn't sound like much, that's almost 1% of a CD-ROM. It's a start. You only need to find about 120 more little apps that are duplicated in functionality and your well on your way to a CD-ROM being removed.

If we want to make an appreciable difference in the size of FC, we've got to cut at least enough to remove a CD or two. If we just cut a few redundant packages, we piss some people off, but gain nearly nothing.

Agreed. But as long as these packages are easy to install (yum install package) then this isn't a huge deal.

If we really want to cut the size of the distro by more than a few hundred meg, we've got to start removing functionality. Plain and simple. Something that lots of people *need* has to go. And you're not going to do it without making a whole lot of people really, really mad.

Not if you handle it well. I know that's a big ask, but it can be handled well. There a plenty of distros out there that only use a single CD and these users are more than satisfied with what comes on the disk.

So, what gets the ax? Tough to say. There's only 15 packages in fc3 that are >= 20 Meg. And OOo accounts for almost 200M of that. But can we really ax OpenOffice? Heresy. KDE? Blasphemous.

Sure, stick OOo on a extras CD-ROM. The ISO would be small, so those who want it wouldn't have to download a lot, and most would just yum install it. Since RH really doesn't focus on KDE (all the RH tools use GTK) I don't have any problem with KDE being on a separate Extras disk either.

This may sound arrogant, I'll admit that I'm not a KDE user, but haing to grab a single extras disk for KDE (and a lot of KDE users sound like they get their KDE from somewhere else than RH) instead of everyone having to grab four disks is a big win for everyone, even if you want KDE. KDE users grab two ISOs, others grab one. Users of OOo grab another. Sure you might end up with 9 or 10 extras disks (Java, KDE, OOo, etc) but none would fill a disk so you aren't grabbing huge amounts of stuff your aren't ever going to use.

Imagine how nice is would be if instead of trying to fit everything onto four disks inside four ISOs with a stack of software you are never going to use so you can get the few bits you do use, you could instead grab on CORE ISO and four or five smaller isos that target the stuff you want.

Sure, we could move packages to Extras... if only we had some idea what Extras is. Whatever it is, though, I'm quite certain that the packages *I* use don't belong there, right? But if the Extras CDs are distributed with the core CDs, and if most people will need the Extras CDs to get those last three packages they're rather fond of, what really is the point dividing them up? Other than, of course, to inconvenience the user. I was all for it a few hours ago, but now it doesn't sound like we'll be helping anyone out.

If people need a few extra packages (like the three number you suggest) it's going to be far easier to just yum install them, rather than download three extra 650MB ISOs for these three, or four, or ten, or twenty packages.

The way I see it, we're left with two options: A) Big distro. Deal with it.

Little distro, better deal

B) Piss lots of people off because Fedora no longer includes the software they use. Sorry KDE and OOo users.

Well defined ISOs which target users needs and save dramatically on the amount of downloads they need just to install CORE, KDE and OOo. Everyone wins.

The third option, "remove the stuff people don't use", seems more like a pipe dream than a viable course of action. You can't remove enough fat to keep A from happening without bringing about B. Moving a substantial amount of stuff into an "Extras" category (or whatever it is) seems like a "worst of both worlds" solution. Not only has the total software base not shrunk, but it's now more difficult to find the package you want. What are the chances, really, that the average user *won't* want at least some of the software on the Extras CD(s)?

Everyone uses something different so it just wont happen. Personally I would love to just have to download the CORE disk, and the OOo, Java, and Devel disks and then just yum the few other packages I need. What a dream. Having to download over 2GB of disks is a PITA.

Of course, the Extras concept has to work well and people have to realize that there is value in having ISOs that don't consume a CD. If all you need for OOo is a 200 ISO, then that's all it should be. The temptation to do OOo and KDE on the one disk should be ignored. Both ISOs won't be much more than a single ISO with both, but users who only want one or the other will be much better off.

I don't know. The more I think about it, the less excited I get. Perhaps someone can share a more rosy picture of how moving packages to Fedora Extras is supposed to make the users' lives so much easier. Anyone care to bite?

The more I think about it the more I think this is the way to go. I'd love a distro that offered more than a single disks functionality, but also offered a single disk that functions, along with small(er) downloads to address particular focus areas. Combine this with the ease of using yum to add those one or two other packages and how good would that be.

Rodd

Hi

So out of curiosity, how do Suse and Mandrake deal with this issue ?

-d

afaik suse doesnt ship mp3 stuff anymore. mandrake as a non-US distro might not be affected by the patents enforced in US

===== Regards Rahul Sundaram

__________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

Rex Dieter wrote:

...

• I still say the libGL devel stuff and libGLU should be split from

xorg-x11-devel.

You keep saying that. But, why? There is no other/alternative GL implementation in Core or Extras (Nvidia's doesn't/shouldn't count in this discussion).

On the other hand, I thought one of Mike's original motivations for splitting off Mesa-GL was to allow for drop-in replacements. I'm not sure if there is value anymore in packaging these separately.

The purpose of splitting out libGL and libGLU was indeed to allow 3rd party rpm packages to install alternative implementations of libGL and/or libGLU at the request of a partner. It was a very reasonable request, and so it got implemented a number of OS releases back.

It is entirely preferred, to have -devel packages for the libraries shipped in the OS, and to that effect, having -devel packages for libGL and libGLU is no different. When this was implemented however, -devel packages did not get created, however that was not an intentional decision really. It "just happened that way" essentially, and nobody ever reported any problems, or pointed out the fact that the development bits weren't also split out, so it stayed that way over time.

Eventually someone did point out the problem, but also pointed out it wasn't a big deal because it was only a problem if you were using unsupported 3rd party drivers, and it was pretty easy to work around the issue.

At the time this was discovered in that particular OS development cycle, it was beyond the freeze date to which additional packages or subpackages could be added to the OS, and since it was a low impact issue, which only affected incorrectly installed unsupported 3rd party drivers, it was definitely not a priority to break our freeze for.

I don't remember which OS release that was exactly, but there have only been maybe 3 people in 2 years ever even notice the problem and point it out, so it isn't a major flaw in the OS really, but rather just a minor inconvenience for some systems with unsupported software installed. The issue basically fell between the cracks after that, due to the low number of people reporting the issue and it's relative low priority.

Having given the background now, I do believe the correct solution is to have separate -devel packages for those libs, for consistency if nothing else, and we will indeed do this in a future OS release.

Fixing the issue will have some build dependancy problems in the OS and with some 3rd party rpm packages that do not specify virtual requires for the libGL and libGLU virtual provides, so fixing this in an erratum, will not be considered an option. The time to fix this, is in a development cycle, in which we're updating to a major new release of the X window system (so we can easily share one src.rpm between multiple OS's without major ugly hacks to the spec file for one OS release).

When we jump to X11R7, that will be the right time, and there will be quite a few xorg packaging changes, which make the impact of the change much smaller also, and so that's when we'll make the change.

Hope this helps.

Jeff Spaleta wrote:

...

...

I heard X will be modularized for FC5 so all libraries will be split up like that. Is that not the case?

Where did you hear that? So it's going to get even more complicated?

i've been hearing mharris wax eloquent about moving away from the 'monolithic' approach to modular pieces for X related libraries for a while now. Catching him when he's actually using eloquent speech however is a refined skill that takes much practice. I'm pretty sure modularization is on X.org's development roadmap moving foward.. but i'm not sure its wise to give a timeline as to when its ready. I have no idea what state the effort is in i dont keep up with xorg related mailinglists.

A motion to discuss the modularization of the X.Org X Window System was brought to the table and approved recently by the board of directors.

The project is currently in the initial planning stages, and the modularization working group is currently being formed. A detailed roadmap including timelines is not presently available, but may be forthcoming at a future juncture now that the wherewithal has been obtained.

Parties potentially interested in contributing to the grandoise effort are encouraged to contact the X.Org project and express their intentions and concurrance with limitless exuberance via the xorg@freedesktop.org developmental mailing list.

If there are no further questions or concerns, I'll move on to the next agendum.

Trond Eivind Glomsrød wrote:

Building kernel modules from various external repositories has always been an interesting task. Unfortunately.

True.

Ideally, they'd not ship kernel modules at all but rebuild on boot if not previously compiled for that kernel (DKMS).

Now that would be slick.

-- Rex

Le samedi 29 janvier 2005 à 12:33 -0700, Tyler Larson a écrit :

Jamie Zawinski wrote:

...

Jeff Spaleta wrote:

...

Thanks for volunteering to help the bmp developers work through the remaining usability issues.

Yes, by all means, let's improve the Linux user experience by replacing working tools with half-working tools.

Jamie has a point, you know. Albeit cleverly disguised amidst the sarcasm.

Progress for progress' sake is an absurd motivation. That is, replacing an app with a functionally inferior one just because it uses old libraries isn't sensible. If you replace an app, the new one should be *better* than the old one. The goal isn't to make new programs better, it's to use the best programs.

In this case it's already been explained the library change directly translates in end-user benefits.

On Sat, 29 Jan 2005 12:33:31 -0700, Tyler Larson fedora-devel@tlarson.com wrote:

Jamie has a point, you know. Albeit cleverly disguised amidst the sarcasm.

calling bmp half-working is a bit over the top. The question has never been is this a perfect replacement.. the question has been is it good enough. I don't feel the objections raised so far are significant barriers to replacing xmms. You are free to disagree with me ( until my army of demonic minions steal your soul and rid you of your pesky free will) but I don't think its particularly rational to expect a perfect replacement of any piece of software when the discussion turns to wholesale replacement. Replacements will have their own strengths and weaknesses that need to be compared.

Progress for progress' sake is an absurd motivation.

No one is arguing that. Progress is a messy non-linear business... trade-offs are made among a a number of factors.. 2 steps forward ...1 step back..

That is, replacing an app with a functionally inferior one just because it uses old libraries isn't sensible. If you replace an app, the new one should be *better* than the old one.

are you saying that gtk2 doesnt have improvements over gtk1? 2 steps forward... 1 step back. If you are looking for monotonic forward progress on ALL aspects ALL the time.. i envy your idealism however naive it is.

The goal isn't to make new programs better, it's to use the best programs.

Is it? I'm not particular sure that is THE goal at all. I think there are a number of competing goals which demand compromise and trade-offs. Everything has an opportunity cost.. the 'best' program 2 years from now may not be the 'best' program today.... and its an absolute WASTE of effort to continue to focus testing manhours through test-releases of core on an application that is a dead-end. If bmp is close enough, and it has a development future that appears to provide better integrations and features into the distributions long term... then its worth considering.. even though its not a perfect replacement for xmms. I think its close enough to be a replacement and that its gtk2 provides inherent benefit. Feel free to disagree.

Any decision that meets one of these lesser goals (like shrinking the distro size) but still runs contrary to the more important principle of improving the user experience is a bad decision to make. Don't destroy the forest to save a tree.

A decisions that has a significant and lasting long term benefit can cause short term negative impact. 2 steps forward.. and 1 step back.. is still progress.

-jef"doing the progress cha-cha"spaleta

Hi.

Rodd Clarkson rodd@clarkson.id.au wrote:

Sure xmms is small, but it's about 4.8M of RPMS (including devel, flac and skins) On top of this is requires the GTK-1.x libraries so assuming not a lot else uses these libraries you're another step towards not needing them in core anymore.

I played with rpm a little today to see what prevents gtk1 being removed. After "rpm -e --test"'ing a whole lot of gtk1 and gnome1 gruft it basically comes down to a handful of applications that are currently in FC (and a quite impressive list of applications from external repos, but that's another story):

xmms system-config-proc mtr-gtk and, most important, gnucash.

There are some libraries I had to remove of which I am not sure whether there are gtk2 replacements (and what these things are good for, anyway):

Guppi gal

Please note that the above list just represents what currently is installed on my machine.

system-config-proc

Just delete this one, we won't release a new version of this one. Not included in Fedora Core anymore.

xmms mtr-gtk and, most important, gnucash.

These should really get ported to gtk1. Is there any reason why nobody wants to change them over?

greetings,

Florian La Roche

Kyrre Ness Sjobak (kyrre@solution-forge.net) said:

tir, 25.01.2005 kl. 21.14 skrev seth vidal:

...

...

Will and does are very different. IF it isn't there by FC4, FC4 should include grip. However, I see all critical functionality, and most non- critical, in RhythmBox. xmms uses gtk1 and doesn't seem to be needed; should it be removed?

Yes, it should. -sv

What about simple "play that .mp3, i want to know what's in it" kind of use? I must admit that i still use XMMS for that - it just works. Having a libary isn't always what you want. So i have xmms as my default player for all audio files. When i want to listen to an album i ripped (etc), i fire up rythmbox, import the files if neccessary, and play it.

Commandline? madplay or similar.

I'd assume in the filemanager there would be something small that would launch on doubleclick. But I could be wrong.

Bill

Once upon a time, Bill Nottingham notting@redhat.com said:

Kyrre Ness Sjobak (kyrre@solution-forge.net) said:

...

What about simple "play that .mp3, i want to know what's in it" kind of use? I must admit that i still use XMMS for that - it just works. Having a libary isn't always what you want. So i have xmms as my default player for all audio files. When i want to listen to an album i ripped (etc), i fire up rythmbox, import the files if neccessary, and play it.

Commandline? madplay or similar.

I'd assume in the filemanager there would be something small that would launch on doubleclick. But I could be wrong.

In FC3 (with MP3 support added via livna for xmms and gstreamer)), I opened nautilus and double clicked on an MP3. It brought up the Helix Player Setup Assistant. That just goes through the release notes (kind of dumb), then brings up a box that says that there is a "component missing" with a "Get RealPlayer" button.

With all the discussion that rhythmbox makes xmms unneeded (so it should be removed from Core), why do we also have Helix Player in Core (or is Helix Player supposed to replace rhythmbox and xmms)? Is it possible to add plugins to Helix Player to get MP3 (and other format) support as easily as for rhythmbox and xmms?

Once upon a time, Colin Walters walters@redhat.com said:

On Mon, 2005-01-31 at 13:42 -0600, Chris Adams wrote:

...

With all the discussion that rhythmbox makes xmms unneeded (so it should be removed from Core), why do we also have Helix Player in Core (or is Helix Player supposed to replace rhythmbox and xmms)?

Helix and Rhythmbox are pretty different.

Rhythmbox and xmms are pretty different as well.

...

Is it possible to add plugins to Helix Player to get MP3 (and other format) support as easily as for rhythmbox and xmms?

Not as far as I know.

Hmm, dumb question then: why is Helix Player listed as the default MP3 application?

I tried to do a little research on Helix Player, but the website appears to be down right now. It would be nice if dropping in a plugin of some type was all it took to add MP3 (and Real) support.

On Mon, 2005-01-31 at 20:59 +0100, Nicolas Mailhot wrote:

...

I tried to do a little research on Helix Player, but the website appears to be down right now. It would be nice if dropping in a plugin of some type was all it took to add MP3 (and Real) support.

I'm pretty sure that's the case. Helix + real plugin + mp3 plugin = real player.

Well, it seems like that's basically true, but can you actually get the plugins needed anywhere other than by getting RealPlayer instead?

/Per

I tried to do a little research on Helix Player, but the website appears to be down right now. It would be nice if dropping in a plugin of some type was all it took to add MP3 (and Real) support.

I tried dropping the mp3 plugin files from RealPlayer in the HelixPlayer plugin dir, and voilá! mp3 playback enabled.

I don't think the mp3 component is non-distributable, only the RealAudio/RealVideo ones. A HelixPlayer-mpeg package might be possible to host at rpm.livna.org, for mp3 and mpeg4 playback.

/Peter

On Mon, 2005-01-31 at 14:46 -0500, Colin Walters wrote:

On Mon, 2005-01-31 at 13:42 -0600, Chris Adams wrote:

...

Once upon a time, Bill Nottingham notting@redhat.com said:

...

Kyrre Ness Sjobak (kyrre@solution-forge.net) said:

...

What about simple "play that .mp3, i want to know what's in it" kind of use? I must admit that i still use XMMS for that - it just works. Having a libary isn't always what you want. So i have xmms as my default player for all audio files. When i want to listen to an album i ripped (etc), i fire up rythmbox, import the files if neccessary, and play it.

Commandline? madplay or similar.

I'd assume in the filemanager there would be something small that would launch on doubleclick. But I could be wrong.

In FC3 (with MP3 support added via livna for xmms and gstreamer)), I opened nautilus and double clicked on an MP3. It brought up the Helix Player Setup Assistant. That just goes through the release notes (kind of dumb), then brings up a box that says that there is a "component missing" with a "Get RealPlayer" button.

This is a complex issue, but basically what it boils down to is that /usr/share/applications/defaults.list can only contain one application for each MIME type. Once we fix that, we can ensure that e.g. if you don't have HelixPlayer installed but do have totem, you get totem.

This is supported since gnome-vfs 2.8.3.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an underprivileged white trash cowboy with a winning smile and a way with the ladies. She's a scantily clad green-skinned single mother from a different time and place. They fight crime!

On Fri, 2005-01-28 at 07:21, Jamie Zawinski wrote:

So then I tried Totem, and it suffers from the canonical Red Hat braindamage of "oh, you haven't installed the mystery secret MP3 plugin, and no, I won't even hint to you where to find it." Frankly, I can't be bothered to go on this snark hunt again, I've done that enough times.

Feel free to buy an MP3 decoder license and donate it to rh. http://www.mp3licensing.com/help/developer.html#1 http://www.iis.fraunhofer.de/amm/legal/index.html http://www.mp3licensing.com/royalty/index.html

Regards.

On Mon, 2005-02-14 at 09:14 -0500, Paul A. Houle wrote:

On Mon, 14 Feb 2005 11:58:26 +0100, Iago Rubio iago.rubio@hispalinux.es wrote:

...

Feel free to buy an MP3 decoder license and donate it to rh. http://www.mp3licensing.com/help/developer.html#1 http://www.iis.fraunhofer.de/amm/legal/index.html http://www.mp3licensing.com/royalty/index.html

That's insane.

The decoder license is $60,000. What's that? The revenue RH gets from

Perhaps RH could spend some of the money that it's not spending on quality assurance and support and buy a decoder license and put an end to this nonsense. (Granted, I don't see a 'one-time' licensing fee for the encoder and the encoder licensing really does look stiff.)

it's worse actually. If RH coughed up the $60k we still can't ship it, since all MP3 decoders are GPL licensed. And the GPL doesn't actually allow you to ship code only YOU have a patent license for; you need a patent license for everyone and every possible derived work of that code..... which the licensing guys aren't actually providing.