Created attachment 374138 [details] Diff for spacefm-0.9.3.ebuild SpaceFM has support for both GTK2 and GTK3 in its build system. The project developer has mentioned that this may not always be this way [1], but for now it supports both. This should be reflected in a USE flag of some sort. I took a stab at implementing a `gtk2` USE flag, but repoman complains about it not being in use.desc. I'm not sure what the correct way to proceed (or implement the USE flag) is, but I wanted to show that there is user interest in SpaceFM retaining gtk2 support and I personally attempted to implement it. Thanks for your time and consideration. [1]: http://igurublog.wordpress.com/2014/03/22/gtk-3-10-drops-menu-icons-and-mnemonics/ ¶ 11: "At some point, I believe I may need to drop GTK3 support entirely from SpaceFM, but we haven’t reached that point yet."
Created attachment 374140 [details, diff] Unified diff for spacefm-0.9.3.ebuild Updated patch to be unified as per recommendation from another user.
> [1]: http://igurublog.wordpress.com/2014/03/22/gtk-3-10-drops-menu-icons and-mnemonics/ > ¶ 11: "At some point, I believe I may need to drop GTK3 support entirely from SpaceFM, but we haven’t reached that point yet." Well, gtk3 devs *are* being stupid about quite a few topics. Yet, unless upstream *actually* drops the support, this 'problem' has already been dealt with in bug 489810.
(In reply to Rafał Mużyło from comment #2) > > [1]: http://igurublog.wordpress.com/2014/03/22/gtk-3-10-drops-menu-icons and-mnemonics/ > > ¶ 11: "At some point, I believe I may need to drop GTK3 support entirely from SpaceFM, but we haven’t reached that point yet." > > Well, gtk3 devs *are* being stupid about quite a few topics. > Yet, unless upstream *actually* drops the support, this 'problem' has > already been dealt with in bug 489810. Wow. This seems odd. If the maintainer refuses to support choice, then is my only option to maintain my own version of the ebuild(s) in a local overlay? This seems like a step backwards...
It was a decision, also see bug #420493. Move on, don't fight the gtk+-3 train.
(In reply to Daniel Campbell from comment #3) > (In reply to Rafał Mużyło from comment #2181) > > > [1]: http://igurublog.wordpress.com/2014/03/22/gtk-3-10-drops-menu-icons182 and-mnemonics/ > > > ¶ 11: "At some point, I believe I may need to drop GTK3 support entirely from SpaceFM, but we haven’t reached that point yet." > > > > Well, gtk3 devs *are* being stupid about quite a few topics. > > Yet, unless upstream *actually* drops the support, this 'problem' has > > already been dealt with in bug 489810183. > > Wow. This seems odd. If the maintainer refuses to support choice, then is my > only option to maintain my own version of the ebuild(s) in a local overlay? > This seems like a step backwards... USE flags were never meant to pass all possible configure-switches in the world to the end user. We pick USE flags from a number of considerations. This use case is not supported and that's what the gnome team advises. gtk+-3 is in stable arch.
(In reply to Julian Ospald (hasufell) from comment #5) > (In reply to Daniel Campbell from comment #3) > > (In reply to Rafał Mużyło from comment #2181) > > > > [1]: http://igurublog.wordpress.com/2014/03/22/gtk-3-10-drops-menu-icons182 and-mnemonics/ > > > > ¶ 11: "At some point, I believe I may need to drop GTK3 support entirely from SpaceFM, but we haven’t reached that point yet." > > > > > > Well, gtk3 devs *are* being stupid about quite a few topics. > > > Yet, unless upstream *actually* drops the support, this 'problem' has > > > already been dealt with in bug 489810183. > > > > Wow. This seems odd. If the maintainer refuses to support choice, then is my > > only option to maintain my own version of the ebuild(s) in a local overlay? > > This seems like a step backwards... > > USE flags were never meant to pass all possible configure-switches in the > world to the end user. We pick USE flags from a number of considerations. > This use case is not supported and that's what the gnome team advises. > gtk+-3 is in stable arch. Thanks for the clarification and transparency. In your other comment you told me "don't fight the GTK 3 train." Do you agree with Gentoo's GNOME team's stance to only support GTK 3 moving forward, or were there many discussions had that they simply wouldn't move on? I ask this because upstream GNOME developers are known for disregarding legitimate user concerns and requests, and downstream GNOME maintainers seem to adopt the same attitude. To clarify, my intent isn't to fight, but to understand so I can decide what I will do as a user. Is this something the Council has voted on?
(In reply to Daniel Campbell from comment #6) > (In reply to Julian Ospald (hasufell) from comment #5200) > > (In reply to Daniel Campbell from comment #3201) > > > (In reply to Rafał Mużyło from comment #2181202) > > > > > [1]: http://igurublog.wordpress.com/2014/03/22/gtk-3-10-drops-menu-icons182203 and-mnemonics/ > > > > > ¶ 11: "At some point, I believe I may need to drop GTK3 support entirely from SpaceFM, but we haven’t reached that point yet." > > > > > > > > Well, gtk3 devs *are* being stupid about quite a few topics. > > > > Yet, unless upstream *actually* drops the support, this 'problem' has > > > > already been dealt with in bug 489810183. > > > > > > Wow. This seems odd. If the maintainer refuses to support choice, then is my > > > only option to maintain my own version of the ebuild(s) in a local overlay? > > > This seems like a step backwards... > > > > USE flags were never meant to pass all possible configure-switches in the > > world to the end user. We pick USE flags from a number of considerations. > > This use case is not supported and that's what the gnome team advises. > > gtk+-3 is in stable arch. > > Thanks for the clarification and transparency. > > In your other comment you told me "don't fight the GTK 3 train." Do you > agree with Gentoo's GNOME team's stance to only support GTK 3 moving > forward, or were there many discussions had that they simply wouldn't move > on? I ask this because upstream GNOME developers are known for disregarding > legitimate user concerns and requests, and downstream GNOME maintainers seem > to adopt the same attitude. > > To clarify, my intent isn't to fight, but to understand so I can decide what > I will do as a user. Is this something the Council has voted on? That is nothing the council has to decide on. I can decide that for my own packages. However, there was disagreement about the naming of gtk USE flags and there still is confusion about it, including QA not communicating properly with the affected library maintainers, council not making any decision... the usual stuff. Anyway, I don't want to support different set of bugs and I doubt that spacefm upstream will care too much about non-trivial gtk+2 related bugs anymore. I do some gtk+ development myself, so I know that the codepaths can diverge a lot.
@comment 7: I think the very problem here is that the upstream (due to some dumb moves on gtk+ upstream side) is considering taking a step back and dropping gtk3 in favor of gtk2.
(In reply to Rafał Mużyło from comment #8) > @comment 7218: > I think the very problem here is that the upstream (due to some dumb moves > on gtk+ upstream side) is considering taking a step back and dropping gtk3 > in favor of gtk2. In that case the whole ebuild will be reverted to gtk+2, obviously.
