Currently: gtk2 Use gtk+-2.0.0 over gtk+-1.2 in cases where a program supports both. Beware that gtk+-2 support can be bad. Could do with also stating that 'gtk' should *not* be unset when using this USE var. Also, these days, Gtk2 support is usually not 'bad'. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Actually, Mozilla 1.4: gtk2 support works, but some graphical glitches in preferences and menus gftp: Slightly messy where gtk2 interface tends to fall off the earth at times. But yes, the phrasing should change, I added that flag for the esoteric few cases where an application had both interfaces, and I couldn't decide which to use for defaults, if any, and still wanted to incorporate an as small change as possible into the USE flag body. perhaps this wording instead: gtk2 : (Requires USE="gtk" ) Tells an application that has both gtk+-1.x and 2.x interface to build the gtk-2.x interface instead of gtk-1.x. gtk-2 support may be in beta state.
Add a 'don't set -gtk if using this' just for idiots like me who have done and wondered why occasionally an application breaks.
Well i doubt the flag descriptions get read in the first place, the current message isn't ambigious. I think a lot of people decide on USE flags to set without ever reading a description. Making it a little more explicit about leaving 'gtk' set probably isn't gonna help one bit. And may i add that i really wonder why this goes to zhen ? These flags are by and for the gnome team.
Foser is correct; the dynamic use-index.xml page is created based on use.desc which isn't written by documentation team. Foser, I'm assigning this to you; do with it whatever you like.
I have to disagree with this entire thread for the following reason: The way the use variables are defined there is no way right now to have a gtk2 only system. I have gnome2 and I have never installed gnome1 on this box. I also haven't installed gtk1 and I would like to keep it that way, Gentoo was supposed to be about flexibility and having a system configured and optimized the way you want it, so I should be able to do that. So then I go to emerge gvim and because my flags are "-gtk gtk2" It wants to build the gtk1 version even though there is a perfectly good gtk2 version in portage. So I change my flags to "gtk gtk2" and now mplayer wants to build a gui gtk1 gui. Why is there no way to say "I want gtk2 only, I don't want QT, motif, gtk1, fltk, athena, anything but gtk2." Instead the best you can do is to say "I want only gtk" not caring about which version it is. Frankly this is just stupid, and will get worse as more people find that they can have a gtk2 based system and want to be free of the un-anti-aliased, bitmapped font crude that is gtk1. (I know the toolkit isn't crude but when you have a gtk1 window next to a gtk2 window it just looks like absolute crude.) Either add a new use flag called gtk1 and allow people to have "gtk -gtk1 gtk2" in their use flags which means "gtk2 only please." Or redefine gtk to mean gtk1 and allow the "-gtk gtk2" flag. The second choice seems much simpler to me since all we have to do is change a few tests by either changing && to || or by removing the gtk test. In the vim.eclass we would have either: if use gtk || use gtk2; then myconf=" --enable-gui=gtk2 --enable-gtk2-check" elif use gtk; then myconf=" --enable-gui=gtk" or if use gtk2; then myconf=" --enable-gui=gtk2 --enable-gtk2-check" elif use gtk; then myconf=" --enable-gui=gtk" both of which would work as expected with a "-gtk gtk2" flag. In the end Spider and Foser know more about what is going on in the portage tree w.r.t. these use variables and so maybe the solution which allows "-gtk gtk2" causes problems. If it does I beg you to put a gtk1 flag in and let me -gtk1 in my use variables. The way things are currently set up this is just a pain in the butt. David
This has recently been heavily discussed on the gentoo-dev ml, please read up on that. In short : this behaviour will not be changed anymore. We believe that changing it now will only cause more confusion. The gtk2 flag will be phased out over time and only gtk will exist, gtk2 was only meant as a transition flag. The problems you describe are with wrong interpretations of these USE flags by non-gnome devs, these are being adressed and are considered bugs. And on a personal note, i really dislike it when people start talking like 'cause this is what Gentoo is supposed to be about...' and all that. It sort of shuts off all real discussion and takes it to a level of 'if you aren't with us, you are against us'. Gentoo gives choice and power, but we also try to keep it simple and accessible to the general user. There is an everexisting tension between the one and other. With this i also like to close this bug while i'm at it, your comment is not really relevant to this bug anyway. The USE flag descriptions are sufficient.
This should be added to an faq. If you don't want gtk 1 or gnome 1 libs, then add <=gnome2 and <=gtk2 to your /etc/portage/package.mask and you'll get a healthy warning about any non-gtk2 apps. I agree completely with foser. This was probably a bad application of USE vars in the first place. Are we going to have to introduce a gtk3 USE flag when gtk3 is released? Or maybe people will only want gtk2.4 applications since there's some nice new changes? What's silly about this is that it is so easy to get around using appropriate masking.
Good idea for a FAQ entry yep. We're working on a Gentoo gnome specific page, i'll try and keep this suggestion in mind when we put it up.
I read the thread and I have two comments: As to the FAQ suggestion, Sure it would be nice to have a FAQ but it would be nicer to have it "just work". In order to take advantage of masking there is a lot to do. There is a 4 step loop over ever package that has a gtk1 but not a gtk2 interface: 1. Add the appropriate lines to /etc/portage/package.mask [tricky syntax here "<x11-libs/gtk+-2*" will do] 2. Then try to build the packages you want. 3. When you see portage complain remove the lines from package.mask. 4. Emerge the complaining package with USE="-gtk". 5. Goto 4. Then when you are done you have to finish with the lines in package.mask and then you wait until emerge -up world bugs out on you only to repeat again. Second I understand why you would want gtk to mean all gtk interfaces and so I understand why you don't want to change the meaning of the current gtk flag, but I still don't like the existing situation. I really think it would be best to have a long term plan for major library upgrades like these. And I don't think the gtk2 use flag was a bad idea. I think what really messed it up was the absence of a gtk1 flag and a system of flag heirarchies. It shouldn't be that hard to add something to portage so that flags can be inherited. So we have a meta-flag gtk which turns on all flags of the form gtk* or perhaps just a specified list of flags via some table lookup (with versioning like we have in the gtk* case this there probably won't be more than one or two of them in active use at a time). The user could then if they had specific demands add in a -gtk1 flag to ensure that a gtk1 version is never built while still allowing other gtk versions. The novice user wouldn't have to know about this, all they need to know is that the gtk flag builds a stable graphical interface, but for users with more specific demands this is an excellent tool to control exactly what is installed. In addition a use flag heirarchy would be helpful in making things more for the end user. There could be a desktop flag which turns on the most popular desktop environment. A server flag which turns on options appropriate for servers, etc... PS Foser, when I say "Gentoo was supposed to be about..." I mean it in the "this is frustrating and unexpectedly hard" way. I am not trying to shutoff discussion, just trying to express the feelings I suspect would be common among users trying to figure out how to do this "the right way" only to find that there really isn't "a right way" at all just a way of working around the limitations of a temporary fix. When every- thing else in the gentoo install and customization works so elegantly you begin to expect that dealing with which version of a gtk interface to build is also going to be handled as elegantly as everything else.
