media-video/gnome-mplayer-1.0.4 depends on Gtk+ 3 and forced the "--enable-gtk3" configure option. There's no reason for that, since it's optional. I am attacking an ebuild patch that makes building against gtk3 optional. Reproducible: Always
Created attachment 279075 [details, diff] Patch against gnome-mplayer-1.0.4.ebuild Use a "gtk3" USE flag to enable building against Gtk 3.
Thanks, I was looking for this. Tested working on amd64.
I don't see any reason for adding support for deprecated toolkit in the ebuild.
(In reply to comment #3) > I don't see any reason for adding support for deprecated toolkit in the ebuild. I do. Because Gtk 2 is still in portage. And because Gtk 3 doesn't integrate into KDE as well as Gtk 2. And because Gtk 3 support in this package is new and not well tested. When Gtk 2 gets removed from portage, then please feel free to remove support for it.
I agree with Nikos. Running LXDE here, which depends on Gtk 2. gnome-mplayer would be the only ebuild requiring Gtk 3 where gnome-mplayer from SVN builds also fine with Gtk 2...
(In reply to comment #4) > (In reply to comment #3) > > I don't see any reason for adding support for deprecated toolkit in the ebuild. > > I do. Because Gtk 2 is still in portage. And because Gtk 3 doesn't integrate > into KDE as well as Gtk 2. That's specific theming issue with KDE, feel free to open bug for the KDE guys. > And because Gtk 3 support in this package is new and not well tested. > > When Gtk 2 gets removed from portage, then please feel free to remove support > for it. GTK+-1.2 is in Portage too, so is Linux 2.4 and lots of other deprecated stuff. It doesn't mean the packages need to support them until such time. Closing, don't reopen again
This is not KDE specific but gnome 2 has a problem too. Gnome 3 is not in tree yet so by enabling gtk3 there is no theming in the program and does not integrate with gnome. The patch above seems to me the only proper way to solve this.
I will reopen this for as long as the ebuild is buggy.
1. How may gtk2 be "deprecated" while beeing the very latest stable version available in tree ? 2. I thought gentoo was all about choice, why force an optionnal dependency on an unstable library, while giving the choice to users is so trivial ? 3. installing gtk3 for gnome-mplayer on a mostly stable system leads to an ugly GUI (default gtk3 engine) which is ridiculous by itself. This ebuild in its current state is useless, except maybe for the rare who have time to play with gnome3...
Someone who is on Gnome, please post the output of "emerge -pv --depclean gtk+:2" so that we can all see the "deprecated status" of Gtk 2.
As I said, stop reopening the bug. You can easily get matching gtk+:2 and gtk+:3 theming by, for example, installing: emerge x11-themes/gnome-themes-standard And selecting "Adwaita" as GTK theme, then both will look the same. There are plenty more themes available out there... google, anyone? Also don't be in illusion there will be slotted GNOME 2 and GNOME 3 in tree when it hits tree, it will be replacement in same SLOT. Same policy with the apps, use latest available graphical toolkit that works for the app.
Samuli, I'm sorry, but I will reopen this bug. I don't know what inspired you to go mad here over a non-issue that is trivial to fix. An ebuild should provide USE flags for ./configure options. --enable-gtk3 is such a configure option. No one asked you to add support for Gtk 2. The package already supports it. What we ask is to not *remove* that support from the ebuild. There's a big difference between the two. You can also reverse this and use a "gtk2" USE flag while building with Gtk 3 by default. But there is no sane justification for what you're doing here. You're taking away one of the reasons people use Gentoo: the ability to rebuild a package with different ./configure flags in order to suit their needs. Users want this and it's trivial to support (it's only a ./configure option, nothing more than that). I do not want to use "Adwaita" or whatever. I also do not want to have another library loaded into RAM. All programs here use Gtk 2 and Qt. I don't want Gtk 3 too in the mix. Not right now. Maybe next year. Your proposed work-arounds are a burden. Simply supporting --disable-gtk3 in the ebuild is much easier for anyone. Again, I'm terribly sorry, but I will reopen this. And I will keep reopening it indefinitely. Every time you close it, I will open it again. I hope you snap out of it and start considering user needs; you've been one of the most helpful Gentoo devs.
They simply ignore this. Then why reopen this?
emerge -p gnome-themes-standard These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] x11-themes/gnome-themes-standard-3.0.2 [blocks B ] x11-themes/gnome-themes ("x11-themes/gnome-themes" is blocking x11-themes/gnome-themes-standard-3.0.2) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (x11-themes/gnome-themes-standard-3.0.2::gentoo, ebuild scheduled for merge) pulled in by gnome-themes-standard (x11-themes/gnome-themes-2.32.1::gentoo, installed) pulled in by >=x11-themes/gnome-themes-2.32.1 required by (gnome-base/gnome-2.32.1::gentoo, installed) It's funny how something so trivial becomes so complicated in gentoo because the maintainer doesn't want to admit he is wrong.
Then at least give that option, but mask that option so the users will know that this option is no longer supported officially.
I would add that forcing a dependency on unstable gtk3 obviously prevents gnome-mplayer-1.0.4+ from entering the stable tree /before/ gtk3.
I'm certainly with Nikos and others on this. I don't want to pull in and build Gtk3 because one single package needlessly depends on it. ebuilds should support configure flags of the upstream package. For me and many others this is the kind of flexibility that we use Gentoo for, don't take it away!
Moving to userrel then for disabling bugzilla account realnc@gmail.com per Comment #12.
@gnome: What's your take on this? I'd assume dropping gtk+-2 support at this stage is way *too* early, but I don't do or use GNOME, so please let us know your opinion.
@Nikos The 'power of choice' in Gentoo is that you can copy the ebuild to your overlay and do whatever you like to it. In this case it is a small patch (which you have already authored.) Gentoo will not take the patch so you will have to apply it yourself. The bug is public and other users looking for the same fix have the option of using it. As it was explained to me, the gtk2 -> gtk3 transition will ideally be quick and the teams involved do not want to repeat the fiasco that was the pair of gtk / gtk2 use flags. I agree that those flags were a bad idea. I do not ban people for disagreeing with developers. However if the bug is reopened 'indefinitely' as you claim in comment #12 you will find your ability to use bugzilla restricted. In the end it is the developers who decide which patches to take and they will not take this patch; you need to adhere to their decision. -A
To make it short (not much time to read), in order to avoid the gtk/gtk2 USE flag fiasco, what the gnome team expects is that maintainers of any package using gtk just choose either gtk2 or gtk3 support. This applies well to applications only packages, for other packages providing libs, please slot/split them if possible. If it's too complicated or there is too little users in tree, the package can have a gtk3 useflag. Examples of this: libcanberra, gtk-vnc and avahi. For now, the only hold up for gtk3 not going to stable is that the gnome team feels strongly about providing a default theme that does not suck (ie: enable adwaita by default).
(In reply to comment #21) Thanks Gilles for the feedback and for the explanation. Nikos, please read Alec's reply. Samuli, I'm going to close the bug as wontfix following the reasoning presented.
Gentoo development flow is still way too slow even you move to gtk3 so fast ....
(In reply to comment #20) > @Nikos > The 'power of choice' in Gentoo is that you can copy the ebuild to your overlay > and do whatever you like to it. In this case it is a small patch (which you > have already authored.) Gentoo will not take the patch so you will have to > apply it yourself. The bug is public and other users looking for the same fix > have the option of using it. No, this is not the "power of choice" in Gentoo. I have that power in every other distro. I can simply build the source deb or rpm. You're putting the maintenance burden of this on every user. And you expect all users read bugzilla as if it was the New York Times or something. > As it was explained to me, the gtk2 -> gtk3 transition will ideally be quick The what? There is no transition. Or do you claim Gentoo devs will port application software to Gtk 3? You will port Firefox to Gtk 3? What transition are you talking about? If you mean the Gnome transition, then you have been tricked. Gnome != Gtk. Samuli wanted to move this to userrel. Great dude. I suggest users to move this to devrel then? > and the teams involved do not want to repeat the fiasco that was the pair of > gtk / gtk2 use flags. I agree that those flags were a bad idea. I do not ban > people for disagreeing with developers. If those flags were a bad idea, then that doesn't mean you have to repeat the same method. We can use a "deprecated_gtk" USE flag instead. Seriously dude, it's a ./configure option which means it can have a USE flag. There's no hacking involved here. > In the end it is the developers who decide which patches to take and they will > not take this patch; you need to adhere to their decision. This is fascism.
I've been always helping out Gentoo by providing patches, backports and whatnot in bug reports. If this is how you treat your users, then goodbye. No more help from me. It seems Gentoo devs forget that they're not the only ones working on Gentoo. Users are not something to wipe your asses with, devs. Remember that.
well, this turned out really, really great... my lesson learned is that I will continue compiling from source or SVN because the ebuild is useless for me in it's present stage. most probpably for others too.
(In reply to comment #21) [...] > For now, the only hold up for gtk3 not going to stable is that the gnome team > feels strongly about providing a default theme that does not suck (ie: enable > adwaita by default). If anybody knows how to make Adwaita be the default theme for gtk3 apps, please let us (gnome@g.o) know as we are having problems with it as explained in https://bugzilla.gnome.org/show_bug.cgi?id=654108 :-)
(In reply to comment #23) > Gentoo development flow is still way too slow even you move to gtk3 so fast > .... What is preventing you from trying to become a Gentoo dev and help to move things faster? It's really disappointing to see comments like this, we are all volunteers that try to help when we have enough time to do :-/
(In reply to comment #24) > (In reply to comment #20) > > @Nikos > > The 'power of choice' in Gentoo is that you can copy the ebuild to your overlay > > and do whatever you like to it. In this case it is a small patch (which you > > have already authored.) Gentoo will not take the patch so you will have to > > apply it yourself. The bug is public and other users looking for the same fix > > have the option of using it. > > No, this is not the "power of choice" in Gentoo. I have that power in every > other distro. I can simply build the source deb or rpm. > > You're putting the maintenance burden of this on every user. And you expect > all users read bugzilla as if it was the New York Times or something. I expect users to do an internet search if they experience a problem, just like they would for a problem in any other distribution. > > > > As it was explained to me, the gtk2 -> gtk3 transition will ideally be quick > > The what? There is no transition. Or do you claim Gentoo devs will port > application software to Gtk 3? You will port Firefox to Gtk 3? The complaint is that few packages use gtk3 and that the default theme is ugly. As more packages are changed to use gtk3 and when Gnome Team fixes the default theme, those arguments will hold less water. > > What transition are you talking about? If you mean the Gnome transition, then > you have been tricked. Gnome != Gtk. > > Samuli wanted to move this to userrel. Great dude. I suggest users to move > this to devrel then? Devrel is only when developers disagree and I don't think that is the case on this bug. > > > > and the teams involved do not want to repeat the fiasco that was the pair of > > gtk / gtk2 use flags. I agree that those flags were a bad idea. I do not ban > > people for disagreeing with developers. > > If those flags were a bad idea, then that doesn't mean you have to repeat the > same method. We can use a "deprecated_gtk" USE flag instead. Seriously dude, > it's a ./configure option which means it can have a USE flag. There's no > hacking involved here. You can feel free to talk to the gnome team about better methods. > > > > In the end it is the developers who decide which patches to take and they will > > not take this patch; you need to adhere to their decision. > > This is fascism. http://en.wikipedia.org/wiki/Fascism ? I think not. You want us to make a change that we don't agree with. Disagreeing is not fascism. Not taking your patch is not fascism. Making your demands over and over again will not get them committed. I am not sure what your experience is regarding open source projects but projects reject patches all the time.
(In reply to comment #29) > (In reply to comment #24) > > (In reply to comment #20) > > > @Nikos > > > The 'power of choice' in Gentoo is that you can copy the ebuild to your overlay > > > and do whatever you like to it. In this case it is a small patch (which you > > > have already authored.) Gentoo will not take the patch so you will have to > > > apply it yourself. The bug is public and other users looking for the same fix > > > have the option of using it. > > > > No, this is not the "power of choice" in Gentoo. I have that power in every > > other distro. I can simply build the source deb or rpm. > > > > You're putting the maintenance burden of this on every user. And you expect > > all users read bugzilla as if it was the New York Times or something. > > I expect users to do an internet search if they experience a problem, just like > they would for a problem in any other distribution. You're still putting the burden on the user over what is a trivial change. > > > As it was explained to me, the gtk2 -> gtk3 transition will ideally be quick > > > > The what? There is no transition. Or do you claim Gentoo devs will port > > application software to Gtk 3? You will port Firefox to Gtk 3? > > The complaint is that few packages use gtk3 and that the default theme is ugly. > As more packages are changed to use gtk3 and when Gnome Team fixes the default > theme, those arguments will hold less water. This is about Gtk, not Gnome. I'm on KDE anyway. Others are on LXDE or whatever. Gtk is *not* Gnome. Gtk 1.x is still in portage, even. There is no valid justification for not accepting the change other than "I'm the dev and therefore Portage is my personal playground". > > What transition are you talking about? If you mean the Gnome transition, then > > you have been tricked. Gnome != Gtk. > > > > Samuli wanted to move this to userrel. Great dude. I suggest users to move > > this to devrel then? > > Devrel is only when developers disagree and I don't think that is the case on > this bug. "2. [devrel] Project Goals The stated goal for developer relations is to act as a meeting point for Gentoo developers and advanced users both." I would have assumed that Gentoo devs would at least glance over the devrel project description before trying to correct others about what devrel is and isn't. > > > and the teams involved do not want to repeat the fiasco that was the pair of > > > gtk / gtk2 use flags. I agree that those flags were a bad idea. I do not ban > > > people for disagreeing with developers. > > > > If those flags were a bad idea, then that doesn't mean you have to repeat the > > same method. We can use a "deprecated_gtk" USE flag instead. Seriously dude, > > it's a ./configure option which means it can have a USE flag. There's no > > hacking involved here. > > You can feel free to talk to the gnome team about better methods. I don't have anything to do with Gnome. This is Gtk. And what's this "fiasco" you're talking about? > > This is fascism. > > http://en.wikipedia.org/wiki/Fascism ? I think not. I take that back then. It's just "I'm the leet dev that pulls the strings here" attitude. > You want us to make a change that we don't agree with. Exactly. You don't agree so it doesn't happen. You don't consider the user's needs and think that they don't have the right to drive Gentoo's development alongside the devs. Ultimate authority with no consideration for people who aren't in the circle of Gods.
Maybe we should summarize things a bit: - gtk+-2 development is stalled and it will only include some bugfixes for apps still not ported, the way to go is to port things to use gtk+-3, that is the currently actively maintained version. And this is a GTK+ upstream decision, not a Gnome one. - Because of that, we want apps to try to use gtk+-3 when possible and try to reduce gtk+-1 and 2 consumers as both versions won't be maintained in the future (for example, gtk+-1 is only there because of it being still needed by a few unported apps) - If gnome-mplayer upstream has already developed a proper gtk-3 GUI, we will switch to use it instead of keep it using old gtk+-2. This is also done because upstream will likely fix things faster on updated gtk-3 GUI than old gtk2 one.
As a side note, I thing that you can also pass desired configure option using EXTRA_ECONF, that could help you to prevent gtk+3 installation for a bit more time (without our support and, then, don't report us bugs related with gtk2 gui ;)): EXTRA_ECONF="--disable-gtk3" emerge foo But please remember that gtk2 is dead and, sooner or later, most of gtk based software will be ported to gtk3 instead.
(In reply to comment #31) > Maybe we should summarize things a bit: > - gtk+-2 development is stalled and it will only include some bugfixes for apps > still not ported, the way to go is to port things to use gtk+-3, that is the > currently actively maintained version. And this is a GTK+ upstream decision, > not a Gnome one. And? gnome-mplayer can be built with both version 2 and 3. And that is an upstream decision too. When the gnome-mplayer upstream declares Gtk 2 deprecated, I will let you guys know about it. > - Because of that, we want apps to try to use gtk+-3 when possible and try to > reduce gtk+-1 and 2 consumers as both versions won't be maintained in the > future Yes, "try" to use. Which this ebuild can do. It can try to use Gtk 3 by default, unless the user tells it not to. One thing Gentoo devs are spouting around all the time is the phrase "user knows best." So what the hell is going on here? > - If gnome-mplayer upstream has already developed a proper gtk-3 GUI, we will > switch to use it instead of keep it using old gtk+-2. Good, I fully support this. Unless the user switched off the default and goes for Gtk2. > This is also done because > upstream will likely fix things faster on updated gtk-3 GUI than old gtk2 one. Yes, obviously, since Gtk 3 is expected to be the buggy one that actually needs fixing. Gtk 2 support has been mostly rock-stable for a long time now. So why would that need any "fixing"?
(In reply to comment #32) > As a side note, I thing that you can also pass desired configure option using > EXTRA_ECONF, that could help you to prevent gtk+3 installation for a bit more > time (without our support and, then, don't report us bugs related with gtk2 gui > ;)): > EXTRA_ECONF="--disable-gtk3" emerge foo > > But please remember that gtk2 is dead and, sooner or later, most of gtk based > software will be ported to gtk3 instead. This still wants to pull-in Gtk 3 as a dependency. I *don't want* to install Gtk 3.
(In reply to comment #31) > - If gnome-mplayer upstream has already developed a proper gtk-3 GUI, we will > switch to use it instead of keep it using old gtk+-2. I personnaly agree with the idea of moving to gtk3 wherever it is possible. In fact as soon as gnome3 hits the stable tree, i'll switch to using it and starts to feel upset by all thoses "old crapy" apps still depending on gtk2... And i won't argue on keeping both gtk2/3 support as i remember the gtk1/2 stuff and fully understand the work involved. But i for sure disagree with the timing : gtk3 does not seems to be ready for regular use yet (no default theme, and no easy way to theme it especially when gnome is installed and generates portage blocks). As a user, i try to upgrade gnome-mplayer, installs the now required gtk3 and get an ugly GUI. I know i probably may fix this by googling, trying to change the default theme, deal with my own local ebuild, etc.. But is it not part of the maintainer's job to try to avoid that pain to users, as much as it is possible/reasonable ? Do a maintainer maintains for himself of for users ?
(In reply to comment #30) > (In reply to comment #29) > > (In reply to comment #24) > > > (In reply to comment #20) > > The complaint is that few packages use gtk3 and that the default theme is ugly. > > As more packages are changed to use gtk3 and when Gnome Team fixes the default > > theme, those arguments will hold less water. > > This is about Gtk, not Gnome. I'm on KDE anyway. Others are on LXDE or > whatever. Gtk is *not* Gnome. Gtk 1.x is still in portage, even. The team responsible for maintaining gtk+ on Gentoo is the GNOME team - http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/gtk%2B/metadata.xml?revision=1.3 That's why I asked feedback from the GNOME team. > There is no valid justification for not accepting the change other than "I'm > the dev and therefore Portage is my personal playground". Gentoo developers are volunteers that work on the tree on their own time. They became developers because they had "an itch to scratch" and while working on the tree they try to address users requests. However, there's no requirement that developers do what every user wants. Also, the best way to get what you need / want in the tree is to work closely with developers and help out, not to attack or rant with a developer. > > Devrel is only when developers disagree and I don't think that is the case on > > this bug. > > "2. [devrel] Project Goals > > The stated goal for developer relations is to act as a meeting point for Gentoo > developers and advanced users both." > > I would have assumed that Gentoo devs would at least glance over the devrel > project description before trying to correct others about what devrel is and > isn't. Alec is well aware of DevRel's goals and what it does. As he said, DevRel is only involved for issues between developers. Issues between users and developers are dealt with by UserRel. As both Alec and me have been doing most of the UserRel work for a long time now, you may want to rethink how you address him. > > You can feel free to talk to the gnome team about better methods. > > I don't have anything to do with Gnome. This is Gtk. And what's this "fiasco" > you're talking about? Again, it's the GNOME team who works on gkt+ on Gentoo. > > > This is fascism. > > > > http://en.wikipedia.org/wiki/Fascism ? I think not. > > I take that back then. It's just "I'm the leet dev that pulls the strings > here" attitude. > > > You want us to make a change that we don't agree with. > > Exactly. You don't agree so it doesn't happen. You don't consider the user's > needs and think that they don't have the right to drive Gentoo's development > alongside the devs. Ultimate authority with no consideration for people who > aren't in the circle of Gods. We (Gentoo) take users input seriously. That doesn't mean that we always agree with users or that we'll end up implementing things as requested - Gentoo developers are the ones that will have to maintain the tree. If you want to "influence" Gentoo development, than establish a connection with the developers, irc is still the best method to do that, help out, present ideas and better yet patches and help testing. What you should avoid to do is to antagonize members of the community. We don't expect everyone to agree on everything, but having divergent opinions doesn't mean we should go around attacking others. PS - I hope you'll understand that having so many developers commenting on this bug and addressing your posts is a sign of how much we care - we didn't just "ignore you".
(In reply to comment #36) > (In reply to comment #30) > > > Devrel is only when developers disagree and I don't think that is the case on > > > this bug. > > > > "2. [devrel] Project Goals > > > > The stated goal for developer relations is to act as a meeting point for Gentoo > > developers and advanced users both." > > > > I would have assumed that Gentoo devs would at least glance over the devrel > > project description before trying to correct others about what devrel is and > > isn't. > > Alec is well aware of DevRel's goals and what it does. > As he said, DevRel is only involved for issues between developers. Issues > between users and developers are dealt with by UserRel. As both Alec and me > have been doing most of the UserRel work for a long time now, you may want to > rethink how you address him. "for Gentoo developers and advanced users both." I didn't write that myself. It's written on the devrel project page. I just quoted the thing. > We (Gentoo) take users input seriously. That doesn't mean that we always agree > with users or that we'll end up implementing things as requested - Gentoo > developers are the ones that will have to maintain the tree. > If you want to "influence" Gentoo development, than establish a connection with > the developers, irc is still the best method to do that, help out, present > ideas and better yet patches and help testing. In this bug, I provided ideas, a patch and helped testing. > What you should avoid to do is to antagonize members of the community. We don't > expect everyone to agree on everything, but having divergent opinions doesn't > mean we should go around attacking others. What other option is there? "RESOLVED - WONTFIX" means "I don't care about your ideas, patches and help, go fuck yourself." How am I supposed to respond to that? No, it's clearly not "RESOLVED". It's just "WONTFIX". Which is not acceptable. > PS - I hope you'll understand that having so many developers commenting on this > bug and addressing your posts is a sign of how much we care - we didn't just > "ignore you". If addressing my posts means repeating that "devs work on their free time", then yeah, you're right. Btw, everyone seems to forget that I also work here on my free time. I'm no different.
(In reply to comment #33) > (In reply to comment #31) > > Maybe we should summarize things a bit: > > - gtk+-2 development is stalled and it will only include some bugfixes for apps > > still not ported, the way to go is to port things to use gtk+-3, that is the > > currently actively maintained version. And this is a GTK+ upstream decision, > > not a Gnome one. > > And? gnome-mplayer can be built with both version 2 and 3. And that is an > upstream decision too. When the gnome-mplayer upstream declares Gtk 2 > deprecated, I will let you guys know about it. > gtk-2 is deprecated, if both GUIs are supported, better use the one using maintained gtk+ version > > > - Because of that, we want apps to try to use gtk+-3 when possible and try to > > reduce gtk+-1 and 2 consumers as both versions won't be maintained in the > > future > > Yes, "try" to use. Which this ebuild can do. It can try to use Gtk 3 by > default, unless the user tells it not to. > Please don't try to change the sense of my sentence, it has been explained already why we don't want to offer both options, but try to use either gtk2 or gtk3 only depending on how good GUIs work on affected applications > One thing Gentoo devs are spouting around all the time is the phrase "user > knows best." So what the hell is going on here? > > > > - If gnome-mplayer upstream has already developed a proper gtk-3 GUI, we will > > switch to use it instead of keep it using old gtk+-2. > > Good, I fully support this. Unless the user switched off the default and goes > for Gtk2. > > > > This is also done because > > upstream will likely fix things faster on updated gtk-3 GUI than old gtk2 one. > > Yes, obviously, since Gtk 3 is expected to be the buggy one that actually needs > fixing. Gtk 2 support has been mostly rock-stable for a long time now. So why > would that need any "fixing"? This assumption is wrong, gtk+3 also fixes a lot of bugs that are currently unresolved in gtk-2 branch and won't be solved on it. (In reply to comment #34) > (In reply to comment #32) > > As a side note, I thing that you can also pass desired configure option using > > EXTRA_ECONF, that could help you to prevent gtk+3 installation for a bit more > > time (without our support and, then, don't report us bugs related with gtk2 gui > > ;)): > > EXTRA_ECONF="--disable-gtk3" emerge foo > > > > But please remember that gtk2 is dead and, sooner or later, most of gtk based > > software will be ported to gtk3 instead. > > This still wants to pull-in Gtk 3 as a dependency. I *don't want* to install > Gtk 3. Even if I won't recommend you to skip gtk3 installation, maybe you could use /etc/portage/profile/package.provided to make portage think gtk3 is installed, but I would suggest you to simply let it install gtk3 as many other apps will start to use it in the near future.(In reply to comment #35) > (In reply to comment #31) > > - If gnome-mplayer upstream has already developed a proper gtk-3 GUI, we will > > switch to use it instead of keep it using old gtk+-2. > > I personnaly agree with the idea of moving to gtk3 wherever it is possible. In > fact as soon as gnome3 hits the stable tree, i'll switch to using it and starts > to feel upset by all thoses "old crapy" apps still depending on gtk2... And i > won't argue on keeping both gtk2/3 support as i remember the gtk1/2 stuff and > fully understand the work involved. > Be sure gtk+3 and apps using it will go to stable when ready ;), for now, you can, for example, stick with stable gnome-mplayer version still using gtk2 gui. > But i for sure disagree with the timing : gtk3 does not seems to be ready for > regular use yet (no default theme, and no easy way to theme it especially when > gnome is installed and generates portage blocks). > About this blocks, I think I fixed them yesterday, but not sure if we are talking about the same problem :( > As a user, i try to upgrade gnome-mplayer, installs the now required gtk3 and > get an ugly GUI. I know i probably may fix this by googling, trying to change > the default theme, deal with my own local ebuild, etc.. For now I think that the easier way to get it themed using Adwaita is to install x11-themes/gnome-themes-standard and, if you are using Clearlooks for gtk2, switch to Adwaita theme. If you are using a different theme, one option is to do the following in your home: $ ln -s /usr/share/themes/Adwaita/gtk-3.0/ .config/. But this is a workaround until we fix the theming problem, until then, I would suggest you to stick with stable versions (also for gnome-mplayer) for now and be a bit patient. > But is it not part of > the maintainer's job to try to avoid that pain to users, as much as it is > possible/reasonable ? Do a maintainer maintains for himself of for users ? When you are using packages from "testing" you are exposed to these problems. Even me being one of the people hating the gtk3 theming problem, we must admit it's really a cosmetic one. If you don't want even this kind of "pain", use gnome-mplayer from stable then :) Regards
(In reply to comment #38) > (In reply to comment #33) > > (In reply to comment #31) > > > Maybe we should summarize things a bit: > > > - gtk+-2 development is stalled and it will only include some bugfixes for apps > > > still not ported, the way to go is to port things to use gtk+-3, that is the > > > currently actively maintained version. And this is a GTK+ upstream decision, > > > not a Gnome one. > > > > And? gnome-mplayer can be built with both version 2 and 3. And that is an > > upstream decision too. When the gnome-mplayer upstream declares Gtk 2 > > deprecated, I will let you guys know about it. > > gtk-2 is deprecated, if both GUIs are supported, better use the one using > maintained gtk+ version Gtk 2 is maintained. You're jumping the gun way too quick on this one. It's impossible to comprehend why you're not seeing that. > > > - Because of that, we want apps to try to use gtk+-3 when possible and try to > > > reduce gtk+-1 and 2 consumers as both versions won't be maintained in the > > > future > > > > Yes, "try" to use. Which this ebuild can do. It can try to use Gtk 3 by > > default, unless the user tells it not to. > > Please don't try to change the sense of my sentence, it has been explained > already why we don't want to offer both options It's not you who needs to offer both options. It's upstream gmone-mplayer. *They* offer both options. What you do not offering something, but crippling something already offered. Again, it's impossible to understand your reasoning. It seems arbitrary, random, counter intuitive. And annoying :-) > but try to use either gtk2 or > gtk3 only depending on how good GUIs work on affected applications Again, it's a mystery why you choose "either or". Allowing both makes everyone happy. In this discussion, we're trying to find a compromise solution that works for everyone. The problem is, you're not interested in any compromise. You've cast your decisions in stone. > > > This is also done because > > > upstream will likely fix things faster on updated gtk-3 GUI than old gtk2 one. > > > > Yes, obviously, since Gtk 3 is expected to be the buggy one that actually needs > > fixing. Gtk 2 support has been mostly rock-stable for a long time now. So why > > would that need any "fixing"? > > This assumption is wrong, gtk+3 also fixes a lot of bugs that are currently > unresolved in gtk-2 branch and won't be solved on it. And introduces new bugs, like the GUI looking like ass. And when the bugs get resolved in the Gtk 3 branch, *then* we can decide whether to drop Gtk 2, right? And why doesn't an *unsupported* USE flag that only takes 3 lines of code to implement get the job done? You can even mask it if you wanted. > Even if I won't recommend you to skip gtk3 installation, maybe you could use > /etc/portage/profile/package.provided to make portage think gtk3 is installed, > but I would suggest you to simply let it install gtk3 as many other apps will > start to use it in the near future.(In reply to comment #35) Yes, in the near future. It hasn't arrived yet. We're in a transitional phase, and that means we need both Gtk2 and 3 to work. And the only thing required is 3 extra lines of code in the ebuild. It's a big deal. > > (In reply to comment #31) > > > - If gnome-mplayer upstream has already developed a proper gtk-3 GUI, we will > > > switch to use it instead of keep it using old gtk+-2. > > > > I personnaly agree with the idea of moving to gtk3 wherever it is possible. In > > fact as soon as gnome3 hits the stable tree, i'll switch to using it and starts > > to feel upset by all thoses "old crapy" apps still depending on gtk2... And i > > won't argue on keeping both gtk2/3 support as i remember the gtk1/2 stuff and > > fully understand the work involved. > > Be sure gtk+3 and apps using it will go to stable when ready ;), for now, you > can, for example, stick with stable gnome-mplayer version still using gtk2 gui. And you can, for example, allow both gtk2 and 3 for this version, and deprecate the gtk2 version later, which is the intuitive way to handle transitions. And besides, Gtk 2 will not be removed from portage and it's still maintained upstream. No new features, but maintained. Bit rot will start to kick-in in *at least* several months from now, so why don't you want to allow building gnome-mplayer against Gtk2? Last month it was working fine. Today it's already broken? I seriously doubt that. > > As a user, i try to upgrade gnome-mplayer, installs the now required gtk3 and > > get an ugly GUI. I know i probably may fix this by googling, trying to change > > the default theme, deal with my own local ebuild, etc.. > > For now I think that the easier way to get it themed using Adwaita is to > install x11-themes/gnome-themes-standard and, if you are using Clearlooks for > gtk2, switch to Adwaita theme. If you are using a different theme, one option > is to do the following in your home: > $ ln -s /usr/share/themes/Adwaita/gtk-3.0/ .config/. The *only* choice for KDE integration is oxygen-gtk. Period. > But this is a workaround until we fix the theming problem, until then, I would > suggest you to stick with stable versions (also for gnome-mplayer) for now and > be a bit patient. Again, what's the problem with allowing gtk2 for just a little while longer? We're asking you to do this for all eternity. Just for now, until most upstream projects get a chance to flesh out Gtk 3 support. When people whine about Gentoo not picking up the latest and greatest releases from upstream fast enough on ~arch, you're claiming that Gentoo is not about bleeding edge package. Yet now you're jumping the gun *way* too fast. What's it gonna be? Always gonna reply with false statements according to what currently suits you? > > But is it not part of > > the maintainer's job to try to avoid that pain to users, as much as it is > > possible/reasonable ? Do a maintainer maintains for himself of for users ? > > When you are using packages from "testing" you are exposed to these problems. > Even me being one of the people hating the gtk3 theming problem, we must admit > it's really a cosmetic one. If you don't want even this kind of "pain", use > gnome-mplayer from stable then :) Or put 3 lines of bash code in the ebuild with a possible mask on gtk2 and make everyone happy?
(In reply to comment #39) [...] > Or put 3 lines of bash code in the ebuild with a possible mask on gtk2 and make > everyone happy? Or people willing to update their gtk+ version to the developed one instead of wanting to stick with deprecated one even if gnome-mplayer gtk3 gui is as good as gtk2 -> that compromise option will also make everyone happy as won't require us to start flooding the tree with applications supporting both gtk versions (like occurred with gtk/gtk2 USE flags problems in the past) that will need to be dropped again in the future.
(In reply to comment #40) > (In reply to comment #39) > [...] > > Or put 3 lines of bash code in the ebuild with a possible mask on gtk2 and make > > everyone happy? > > Or people willing to update their gtk+ version to the developed one instead of > wanting to stick with deprecated one No, I don't want to stick with deprecated one. But not a single application on my system uses Gtk 3. Clearly, it's not *me* sticking to Gtk 2. It's the applications. > even if gnome-mplayer gtk3 gui is as good > as gtk2 No, it's not. > that compromise option will also make everyone happy No, it won't as of right now. In the near future it will. But not now. > as won't > require us to start flooding the tree with applications supporting both gtk versions You won't flood the tree with them. They are already in the tree. > (like occurred with gtk/gtk2 USE flags problems in the past) that will > need to be dropped again in the future. Which means you can leave the "gtk" USE flag as-is (meaning not "gtk3" flag) and only allow a "gtk2" or even a "deprecated-gtk" or "unsupported-gtk" or whatever, that you don't even need to officially support. From my point of view, if you can't even do that, you're lazy. It's trivial to do it, only takes exactly 3 lines of code, which you don't even need to write yourself since I've done it for you.
(In reply to comment #41) > > From my point of view, if you can't even do that, you're lazy. It's trivial to > do it, only takes exactly 3 lines of code, which you don't even need to write > yourself since I've done it for you. You significantly underestimate the amount of time that goes into testing these things, even in the unstable branch. You're asking for lots of work, and new dependencies that must be tracked and coordinated. If it were trivial, I would agree with you. But it isn't.
(In reply to comment #42) > (In reply to comment #41) > > > > From my point of view, if you can't even do that, you're lazy. It's trivial to > > do it, only takes exactly 3 lines of code, which you don't even need to write > > yourself since I've done it for you. > > You significantly underestimate the amount of time that goes into testing these > things, even in the unstable branch. You're asking for lots of work, and new > dependencies that must be tracked and coordinated. > > If it were trivial, I would agree with you. But it isn't. Offering an unsupported configuration *is* trivial. Because you don't need to test it. *I* need to test it.
(In reply to comment #43) > > Offering an unsupported configuration *is* trivial. Because you don't need to > test it. *I* need to test it. There's no such thing as an unsupported configuration; a maintainer is responsible for what he or she commits. That rule has been around forever, and the devs do catch shit when they commit something broken. Personally, I think that we should have something like ~~arch where you don't expect anything to work; but, as it stands, ~arch is pretty stable and these changes have to be tested. Furthermore, *somebody* would have to keep track of gtk2's progress and stable status in-tree, since future changes to gnome-mplayer would depend on them. Even if users could chip in to do the arch testing (now, and for all version bumps!), would any of them volunteer to be on the hook for all future problems? And if the volunteer goes MIA, it's the maintainer who's going to take the blame.
*** Bug 374509 has been marked as a duplicate of this bug. ***
Rethink your decisions: It makes the application look bad: * All non-builtin gtk theme engines (I depend on nodoka) are gtk2, so any app using gtk3 is not theme-conformant and will look alien (ugly as hell in most cases) in any gtk2 environment (which currently is KDE, XFCE, LXDE, IceWM, ...). * All of the desktop environments listed above only support gtk2 theme and accessability configuration in their system settings, not gtk3 theme configuration, so configuring the look and feel of a gtk3 is impossible. Your argument about bugs in gtk2 is wrong: * The gtk2 bugs are on my system anyway as long as I'm forced to use gtk2 by my desktop and applications, no matter if gnome-mplayer uses gtk2 or not. * If the newest gnome-mplayer depends on gtk3, I'll have to mask it and stay with the old version, which means even more bugs (those in the old version of gnome-mplayer). Forcing gtk3 (in addition to their gtk2) onto the users just for one such single minor application like gnome-mplayer is insane: * XFCE (the desktop I use) is gtk2 only, including the settings dialogs for GUI theme configuration. * LXDM (my display manager) is gtk2 only. * LibreOffice is gtk2 only. * Firefox and thunderbird are gtk2 only, Adobe flash plugin is gtk2 only and will stay so for quite some time. * >90 % of the gtk-dependent apps I have on my system are gtk2 only. Hence, gtk2 systems will be a fact for quite some time, especially on all low-ressource platforms (LXDE, XFCE, ... - as long as Gnome 3 requires OpenGL, it is a no-go for many users). So you better make your apps well-behaved citizen's in gtk2 worlds, *** adopting their theme and native look and feel ***. It is the job of a maintainer to make most of its users happy, and most of the users are gtk2 now.
*** Bug 376837 has been marked as a duplicate of this bug. ***
*** Bug 382967 has been marked as a duplicate of this bug. ***
> I don't see any reason for adding support for deprecated toolkit in the ebuild. I don't like to say this, but there still a lot of apps in the portage the that are supposed to support gtk+-1. I can understand that it would be better not to be in the same situation in ten years with only-gtk2 apps. But the transition shouldn't be as sharp it is done there.
*** Bug 395613 has been marked as a duplicate of this bug. ***
*** Bug 401039 has been marked as a duplicate of this bug. ***
*** Bug 385159 has been marked as a duplicate of this bug. ***
*** Bug 402515 has been marked as a duplicate of this bug. ***
The situation with the transition to GTK+3 is pretty unclear. I suggest that a Gentoo developer who is familiar with the situation creates a wiki page, covering: * themes (I am using gtk-engines-murrine - what are my options?) * dconf/gconf/libmcs/gsettings-data-convert Right now only lxpolkit does not make gtk3 optional on my system. This change was introduced in an -r1 update of the ebuild, no less. Can I expect the previous version of the ebuild to be removed from the tree soon, or will it stay for a while?
Some guys are trying to support both gtk2 and gtk3 for some packages in stuff overlay. You can try use their ebuilds :-)
(In reply to comment #55) > * themes (I am using gtk-engines-murrine - what are my options?) If you have designed your own gtkrc, expect to invest some hours of manual conversion. The syntax and structure has changed significantly. Feature-wise, the unico engine can do everything murrine did, and seems to be the one and only widely used gtk3 engine (there will be no murrine). If you are willing to use already-existing themes, you have two choices: * Install both the gtk2 and gtk3 xfce engine. It comes with some predefined themes and looks almost identical in gtk2 and gtk3, but is visually primitive compared to murrine or unico. * Install murrine for gtk2 and unico for gtk3, and download a theme which contains similar configurations for both, like "Hope" or "Yoda" or "Bluebird". If you want to use an ebuild, there is "zukitwo", which also uses murrine for gtk2 and unico for gtk3. And if you also have KDE on your box, oxygen-gtk is the perfect gtk2+gtk3 engine. > * dconf/gconf/libmcs/gsettings-data-convert Can't say anything about that. > Right now only lxpolkit does not make gtk3 optional on my system. This change > was introduced in an -r1 update of the ebuild, no less. Can I expect the > previous version of the ebuild to be removed from the tree soon, or will it > stay for a while? That depends on the package maintainer. The gtk2 version of nemiver was removed immediately when the gtk3 version was released, the gtk2 version of some other gtk3 ebuilds has been preserved for months...
(In reply to comment #57) Thanks Klaus, your comment has been very helpful. I am using a rather simple gtkrc (basically, importing MurrinaCandy from murrine-themes), so zukitwo seems like the most viable upgrade path. zukitwo depends on ubuntu-font-family for some reason, but that can be dealt with. So far the system can be kept gtk3-clean rather easily, but I guess that in 6 months or so, introducing gtk3 will become inevitable. Hopefully, the relevant packages will stabilize by then.
Personally, I am now using x11-themes/light-themes (with a more Gentoo color style than default ubuntu orange ;)) to get gtk2 and gtk3 apps look fine :)
*** Bug 406647 has been marked as a duplicate of this bug. ***
*** Bug 396539 has been marked as a duplicate of this bug. ***
*** Bug 409791 has been marked as a duplicate of this bug. ***
*** Bug 410841 has been marked as a duplicate of this bug. ***
*** Bug 454268 has been marked as a duplicate of this bug. ***
*** Bug 449774 has been marked as a duplicate of this bug. ***
*** Bug 468294 has been marked as a duplicate of this bug. ***
*** Bug 489630 has been marked as a duplicate of this bug. ***
*** Bug 493492 has been marked as a duplicate of this bug. ***
Created attachment 364848 [details, diff] corrected gmtk-1.0.7
Created attachment 364850 [details, diff] corrected gnome-mplayer ebuild
This whole thing is so sad.. You should be obeying the package developers wishes as long as gnome-mplayer supports gtk2 so should you.. do not confuse your own personal agenda with that of the application developer..
(amd64 team are not involved with this kind of issues)
*** Bug 512978 has been marked as a duplicate of this bug. ***
*** Bug 512974 has been marked as a duplicate of this bug. ***
*** Bug 581466 has been marked as a duplicate of this bug. ***
The same thing happens here with galculator. Supports both GTK3 and GTK2 and GTK3 is enabled only. Also, I maintain a MATE overlay, and I think galculator must support GTK2 too. I tried it here with GTK2 and it's working. Also, being GTK3 relatively new, that's not an excuse to drop GTK2 in some applications that support it, such as galculator. Let users choose what to do. That's the Gentoo's way, anyone have the freedom of choice of what to enable and what not.
(In reply to jorgicio from comment #81) > The same thing happens here with galculator. Supports both GTK3 and GTK2 and > GTK3 is enabled only. Also, I maintain a MATE overlay, and I think > galculator must support GTK2 too. I tried it here with GTK2 and it's working. > > Also, being GTK3 relatively new, that's not an excuse to drop GTK2 in some > applications that support it, such as galculator. Let users choose what to > do. That's the Gentoo's way, anyone have the freedom of choice of what to > enable and what not. The _maintainer_ has the last word because if they feel they only want to support gtk3, it's their decision. There's a list of perfectly valid reasons why a maintainer would choose to do so. If you don't like it, no-one is preventing you from copying the ebuild in a local overlay. Making or modifying your own packages is extremely easy. _That's_ the real power in Gentoo. "Infinite user choices" is not. As for Gtk3 being new, 3.0.0 was released in February 2011 and 3.0.6 was added to portage in March that same year, over _5_ years ago.
(In reply to Rémi Cardona from comment #82) > The _maintainer_ has the last word because if they feel they only want to > support gtk3, it's their decision. There's a list of perfectly valid reasons > why a maintainer would choose to do so. > > If you don't like it, no-one is preventing you from copying the ebuild in a > local overlay. Making or modifying your own packages is extremely easy. > _That's_ the real power in Gentoo. "Infinite user choices" is not. That's a valid argument... > As for Gtk3 being new, 3.0.0 was released in February 2011 and 3.0.6 was > added to portage in March that same year, over _5_ years ago. ... and that's not. The initial goal and assumption was that gtk3 will replace gtk2 quickly: If you listened to the forums, the hope in 2011 was to get completely rid of gtk2 within a year or two, much faster than the gtk1/gtk2 switch. This assumption also caused the "RESOLVED WONTFIX" here. However, the assumption turned out to be wrong: gtk2 is here to stay, for at least another three to five years, and will remain an important platform (e.g. Xfce desktops), especially on small systems (e.g. arm). Mate tried migrating to gtk3 and it turned out to be much harder than expected, Xfce has dropped gtk3 plans completely as far as I know. So perhaps its time for maintainers to rethink their decisions made years ago based on wrong assumptions?
Also: the "infinite choices" means for all Gentoo users that does not know how to know some developers knowledge, such as creating an ebuild or an overlay. Not everybody knows how to do that. And a local overlay is not always a good idea, less when is because one does what some lazy developers must do but does not and uses lot of excuses such as "GTK2 is being dropped and obsolete" and all that crap. So not, that's NOT a valid argument. As so as the issue being "RESOLVED WONTFIX". PS: I maintain 2 overlays, and I'm being tired that some people, because of their laziness that MUST maintain their respective packages, does not do the work they must and let other people (like me) do some forks of ebuilds. I had to do this with lots of packages, such as galculator and giving the GTK2 support as an alternative. I did not want to fork those ebuilds, but I had to.
