http://mplayerplug-in.sourceforge.net/ Upstream has been dead for almost a year now. gecko-mediaplayer has really step'd up to replace the unmaintained mplayerplug-in. Reproducible: Always
I don't think that's a valid reason by itself if it doesn't have serious bugs, security issues.
(In reply to comment #1) > I don't think that's a valid reason by itself if it doesn't have serious bugs, > security issues. > It really is unmaintained, a few developers have worked on it long enough to keep it going, gecko-mediaplayer is the successor.
Don't see how you can call something based GNOME MPlayer a successor to a plugin which uses vanilla mplayer. People on this planet are using KDE you know. mplayerplug-in works well, why remove it from the tree? They can coexist.
I agree with Viktor, I do not have Gnome installed and have no interest in installing a bunch of dependencies particularly gnome-mplayer for gecko-mediaplayer. gecko-mediaplayer is not a successor to mplayerplug-in.
gnome-mplayer has USE="gnome" to control it's dependencies, including gconfd. get real.
(In reply to comment #3) > Don't see how you can call something based GNOME MPlayer a successor to a > plugin which uses vanilla mplayer. People on this planet are using KDE you > know. mplayerplug-in works well, why remove it from the tree? They can coexist. > just installed gecko-mediaplayer and the only dep required was gnome-mplayer. ok, is a bloat dep but it is nicer to see than mplayerplug-in gui. besides, mplayerplug-in will not build any more once you install firefox 3.5 and xulrunner 1.9.1
(re-assigning to maintainer) (In reply to comment #1) @Serkan: The fact is, eventually mplayerplug-in will be removed due to bitrot of no upstream. That time is approaching soon. @Patrick, thanks for testing.
(In reply to comment #3 and comment #4) Well, even though there is 'gnome' in the name. It doesn't mean much for, even a kde system. This is a kde system: Calculating dependencies ... done! [ebuild N ] x11-libs/libsexy-0.1.11-r1 USE="-debug -doc" 0 kB [ebuild N ] x11-libs/libwnck-2.26.2 USE="-doc" 669 kB [ebuild N ] gnome-base/orbit-2.14.17 USE="-doc" 0 kB [ebuild N ] gnome-base/gconf-2.26.2-r1 USE="-debug -doc -ldap -policykit" 0 kB [ebuild N ] x11-libs/libnotify-0.4.5 USE="-doc" 356 kB [ebuild N ] x11-misc/notification-daemon-0.4.0-r1 USE="-debug -gstreamer" 395 kB [ebuild N ] media-video/gnome-mplayer-0.9.6 USE="alsa libnotify -gnome -ipod -musicbrainz" 796 kB [ebuild N ] www-plugins/gecko-mediaplayer-0.9.6 USE="-gnome" 381 kB This is a kde system with USE=-libnotify: Calculating dependencies ... done! [ebuild N ] media-video/gnome-mplayer-0.9.6 USE="alsa -gnome -ipod -libnotify -musicbrainz" 796 kB [ebuild N ] www-plugins/gecko-mediaplayer-0.9.6 USE="-gnome" 381 kB My xfce only system falls into the second category with USE=libnotify. For the record, there is media-video/kmplayer that I am awaiting a kde team member to report back on, I will update the bug when I hear about that.
I'd be thrilled to see this go, the additional gnome deps are minor for kde users and it's badly broken at this point.
Seeing how people seem to dispise mplayerplug-in I'm considering taking over maintainership of it. I would hardly consider it badly broken, afaik it's about 1 line in the configure script that needs fixing. I can probably do that. Not at home right now but I've set up a local overlay in order to fix this regression (xpidl not being found during configure-phase). I still don't see how something based on Gnome's HID standards can be seen as a successor to something based on vanilla mplayer. That may be fine for GTK+ based desktop environments, but I'd rather not.
(In reply to comment #10) > Seeing how people seem to dispise mplayerplug-in I'm considering taking over > maintainership of it. I would hardly consider it badly broken, afaik it's about > 1 line in the configure script that needs fixing. I can probably do that. Not > at home right now but I've set up a local overlay in order to fix this > regression (xpidl not being found during configure-phase). > > I still don't see how something based on Gnome's HID standards can be seen as a > successor to something based on vanilla mplayer. That may be fine for GTK+ > based desktop environments, but I'd rather not. > You need to become upstream then. And fix all the bugs, not just one.
(In reply to comment #10) > Seeing how people seem to dispise mplayerplug-in I'm considering taking over > maintainership of it. I would hardly consider it badly broken, afaik it's about > 1 line in the configure script that needs fixing. I can probably do that that is just one little bug and pretty easy to fix. the other issue is header file npupp.h which was removed in latest xulrunner. copying this file from older xulrunner will make mplayerplug-in compile but firefox will crash every time this plugin is activaed. once firefox 3.5 will be marked stable mplayerplug-in should go. it is pointless to have a firefox plugin that cannot work with latest stable firefox
This is strange. I have the latest Firefox (3.5.1) and mplayerplug-in and it works perfectly well. It does not crush. Please either explain in what cases plugin crushes Firefox. (In reply to comment #12) > (In reply to comment #10) > > Seeing how people seem to dispise mplayerplug-in I'm considering taking over > > maintainership of it. I would hardly consider it badly broken, afaik it's about > > 1 line in the configure script that needs fixing. I can probably do that > that is just one little bug and pretty easy to fix. the other issue is header > file npupp.h which was removed in latest xulrunner. copying this file from > older xulrunner will make mplayerplug-in compile but firefox will crash every > time this plugin is activaed. once firefox 3.5 will be marked stable > mplayerplug-in should go. it is pointless to have a firefox plugin that cannot > work with latest stable firefox >
(In reply to comment #13) > This is strange. I have the latest Firefox (3.5.1) and mplayerplug-in and it > works perfectly well. It does not crush. Please either explain in what cases > plugin crushes Firefox. > mplayerplug-in will not build with >xulrunner-1.9.1 (which is a dep for firefox 3.5) because of the missing npupp.h header file. using an old npupp.h header to build mplayerplug-in will make firefox crash every time the plugin is used
I have both firefox 3.5.1 and xulrunner 1.9.1-r1 installed and mplayerplug-in works fine. How can you explain that? My only guess is that I also have xulrunner 1.8.1.19 installed in another slot.
Having played with gecko-mediaplayer, I must admit, it is quite good. Unfortunately, it doesn't always work (e.g. ninjavideo site). I'll stick to mplayerplug-in (compiles and runs fine with the latest version of firefox and two slots of xulrunner).
I would like to remind you of one thing: NPAPI != Firefox; mplayerplug-in isn't only for Mozilla browsers. Although gecko-mediaplayer seems to work fine in Opera, it's navigation bar is ugly-huge and wastes a lot of space. Maybe mplayerplug-in doesn't work fine with latest Firefox but there are other browsers with which it works great, remember that.
(In reply to comment #15) > I have both firefox 3.5.1 and xulrunner 1.9.1-r1 installed and mplayerplug-in > works fine. How can you explain that? My only guess is that I also have > xulrunner 1.8.1.19 installed in another slot. that is an explanation. you need an older release of xulrunner for building mplayerplug-in
I would also resist the change from mplayerplug-in to gecko-mediplayer + gnome-mplayer, but the author of mplayerplug-in (Kevin DeKorte) also happens to be the author of gnome-mplayer and gecko-mediaplayer. Mplayerplug-in upstream is not dead, but alive and well in the form of user submitted patches that are still being actively committed to it's svn tree by Kevin. However the author does have a vision towards the new gecko-mediaplayer, see http://kdekorte.blogspot.com/2007/02/mplayerplug-in-being-changed-to-gecko.html As you can see, the current situation has been over 2 years in the making.
(In reply to comment #19) > I would also resist the change from mplayerplug-in to gecko-mediplayer + > gnome-mplayer, but the author of mplayerplug-in (Kevin DeKorte) also happens to > be the author of gnome-mplayer and gecko-mediaplayer. > > Mplayerplug-in upstream is not dead, but alive and well in the form of user > submitted patches that are still being actively committed to it's svn tree by > Kevin. > > However the author does have a vision towards the new gecko-mediaplayer, see > http://kdekorte.blogspot.com/2007/02/mplayerplug-in-being-changed-to-gecko.html > > As you can see, the current situation has been over 2 years in the making. > You are quoting a 2+ years old post. The svn repo has had some ~5 commits during 365 days, so I'd describe it as "inactively" instead of "actively". Anyhow, enough noise on this bug already.
What is not clear to me is that why people are not given a choice. Instead we are forced to use an application that (not only in my opinion) is worse than mplayerplug-in. mplayerplaug-in perfectly works on my system with the latest version of firefox and xulrunner because I also have an older version of xulrunner in another slot. Why can't we keep mplayerplug-in?
(In reply to comment #21) > What is not clear to me is that why people are not given a choice. Instead we > are forced to use an application that (not only in my opinion) is worse than > mplayerplug-in. mplayerplaug-in perfectly works on my system with the latest > version of firefox and xulrunner because I also have an older version of > xulrunner in another slot. Why can't we keep mplayerplug-in? > Noone is saying you can not keep it. You can keep it in a seperate overlay where you have access to modify it if you so wish. This is being removed as mozilla team does not want it as it does not compile with latest versions of xulrunner. The current maintainer JoseJX also has no interest in the package as the upstream has already laid it out that plans are to move forward with gecko-mediaplayer.
If anyone would like to talk to me about co-maintainership of mplayerplug-in I'm open to that. To move it forward, it really needs to be converted to XPCom, which is probably a good week of work. Also I see below that there is a problem with gecko-mediaplayer and ninjavideo? Care to elaborate in the gecko-mediaplayer bug tracker? Unless I know about sites that don't work... I can't fix them... http://code.google.com/p/gecko-mediaplayer/issues/list
Hi Kevin, I am currently away from my Gentoo computer, but will be back next week and will add a bug report. Thanks for your work!
(In reply to comment #3) > Don't see how you can call something based GNOME MPlayer a successor to a > plugin which uses vanilla mplayer. People on this planet are using KDE you > know. mplayerplug-in works well, why remove it from the tree? They can coexist. > The requirements for gnome-mplayer are pretty much the same as mplayerplug-in unless you are using it in X mode and that is pretty aweful. In fact rpmfusion releases a stripped down version of gnome-mplayer (basically just GTK/GLIB) specifically for KDE users that don't want extra dependencies, but if you are using Firefox, you already have everything gnome-mplayer needs and more.
(In reply to comment #0) emerge -pv gecko-mediaplayer These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] sys-apps/dbus-1.3.0 USE="X -debug -doc (-selinux) -test" 1,482 kB [ebuild N ] dev-libs/dbus-glib-0.80 USE="-bash-completion -debug -doc -test" 673 kB [ebuild N ] media-video/gnome-mplayer-0.9.7 USE="alsa -gnome -ipod -libnotify -musicbrainz" 673 kB [ebuild N ] www-plugins/gecko-mediaplayer-0.9.7 USE="-gnome" 250 kB Total: 4 packages (4 new), Size of downloads: 3,077 kB Why I need D-Bus for using this new plugin? With www-plugins/mplayerplug-in I don't needed it.
Architecture change. gecko-mediaplayer is the in process browser plugin, that uses gnome-mplayer to play the media and the plugin controls gnome-mplayer via dbus. Should keep the browser more stable since the majority of the application is out of the browser process. http://kdekorte.blogspot.com/2007/02/mplayerplug-in-being-changed-to-gecko.html
(In reply to comment #27) Thus, if I want to view video in browser sometimes, I must to have the daemon always works and uses my processor vainly. I like Gentoo for a freedom. Gentoo always allows me to make a decisions. I decide to not use a DE-related features. D-Bus is one of them. However, I successfully use many desktop-applications without dbus: app-editors/gvim app-editors/leafpad app-emulation/virtualbox-ose app-emulation/wine app-misc/emelfm2 app-office/dia app-office/lyx app-office/mozilla-sunbird app-office/openoffice app-office/texmaker app-text/djview4 app-text/epdfview dev-db/mysql-gui-tools dev-db/mysqlnavigator dev-util/eclipse-sdk lxde-base/lxde-meta media-sound/easytag media-sound/mpd media-sound/qmpdclient media-video/cinelerra media-video/minitube media-video/mplayer net-ftp/filezilla net-im/pidgin net-im/psi net-im/qutim net-im/twinkle net-misc/rdesktop net-voip/ekiga net-voip/linphone sci-mathematics/qtoctave sci-visualization/qtiplot sys-block/gparted www-client/mozilla-firefox www-plugins/adobe-flash www-plugins/moonlight www-plugins/mplayerplug-in x11-misc/googleearth x11-wm/compiz-fusion x11-wm/ion3
(In reply to comment #28) > Thus, if I want to view video in browser sometimes, I must to have the daemon > always works and uses my processor vainly. > I like Gentoo for a freedom. Gentoo always allows me to make a decisions Gentoo only gives you as much choice as upstream leaves you. If upstream chooses not to give you this choice, feel free to report it to them. Thanks.
I know it is your machine but I think you are making a bigger deal out of the dbus requirements than it actually is. My maching has been running for 6 days and during that time dbus has used about 7mins of processor time which is 3/10000's of the time available and that is on a full gnome desktop where many things are controlled with dbus on a machine like yours is setup I'm pretty sure it would be less than that.
Bye.
Does www-plugins/mplayerplug-in still work in people's local overlays? It looks like the OpenSUSE people are maintaining it: http://packman.links2linux.org/package/319 emerge tries to pull a great deal of bloat into KDE installations to support gecko-mediaplayer, so if mplayerplugin-in still works, it might be a good idea to revisit its removal: # emerge -av gecko-mediaplayer * IMPORTANT: 1 news items need reading for repository 'gentoo'. * Use eselect news to read news items. These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild NS ] x11-libs/gtk+-3.2.2 [2.24.7] USE="cups introspection xinerama (-aqua) -colord -debug -doc -examples -packagekit -test -vim-syntax" 12,367 kB [ebuild N ] gnome-base/dconf-0.10.0 USE="X -doc -vala" 169 kB [ebuild N ] media-video/gnome-mplayer-1.0.4 USE="alsa dbus libnotify -gnome -ipod -musicbrainz -pulseaudio" 1,045 kB [ebuild N ] www-plugins/gecko-mediaplayer-1.0.4 USE="-curl" 269 kB Total: 4 packages (3 new, 1 in new slot), Size of downloads: 13,848 kB Would you like to merge these packages? [Yes/No]
