Re: [gentoo-dev] Re: www-client/chromium gtk3 support
В письме от Чт, 10 сентября 2015 17:43:30 пользователь Duncan написал:
> So I've learned (the hard way) to use *stars* or _underlines_ (or for
> lower levels, /italics/) for emphasis, and only use ALL CAPS when I
> really do intend to SHOUT, which isn't often.
Ok. Thank you for netiquette reminder.
I apologize to everyone who might be hurt by that my statement.
And, actually, imagine that speech in IRL, I'd really say that sentence part
("we've no right to dictate") a bit louder than the rest. Alhough, yes, I
didn't mean the loud shoud.
--
Best regards,
mva
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: www-client/chromium gtk3 support
Rich Freeman posted on Sat, 12 Sep 2015 06:48:13 -0400 as excerpted: > On Sat, Sep 12, 2015 at 6:00 AM, Duncan <1i5t5.dun...@cox.net> wrote: >> >> Just bite the bullet and create entire USE flag families such that an >> ebuild can choose the flag appropriate to how it actually uses it. >> AFAIK this would need EAPI help, for reasons given below, but it should >> be doable. >> >> gui >> gui-gtk >> gui-gtk-2 >> gui-gtk-3 >> gui-qt >> gui-qt-4 >> gui-qt-5 > > I'm going to have to read the rest of your email about 14 times to fully > grok it, LOL. I started with a paragraph describing each setting, and very quickly decided /that/ wasn't going to work! I was "in a maze of twisty passages, all different!"[1] So I tried the matrix/table. That was bad enough, but at least with the table, I could cover all possibilities systematically without losing track of where I was. Luckily, the logic can be written once and used by many. Additionally, once setup, ordinary ebuild maintainers won't have to worry about the logic matrix, they'll simply setup the vars describing the candidates, call the function, get a result, and act on it. To ordinary ebuild maintainers it can be as effectively black-box as a call to any EAPI/PM supplied function is, today. > but one thing that strikes me about this approach, and perhaps > mine as well, is that this assumes that USE=-gui should imply USE="-gtk > -qt" or similar. > > What if qt or gtk is used for more than just the GUI. What if the > console version of the program still uses other functions in these > toolkits besides window decoration/etc? You're expanding my realm of possibilities here, thanks! =:^) Good point, particularly since qt5 is modularized with the specific intent of making it useful for CLI-only as well. Except that no, the proposal does /not/ necessarily assume USE=-gui means USE=-qt and -gtk as well. While my example had nothing suggesting CLI, keep in mind that these are effectively hierarchy flags, with gui-* used as the example. This was a (possibly abridged, there's other GUI toolkits...) example of the use and logic of the gui-* flags, but use of other flags and flag- families in the same ebuild would certainly be possible. Presumably one such flag (and perhaps eventually flag-family, if called for) could be cli-qt-5. Meanwhile, keep in mind that as described, the ebuild would set the candidates, then call a function which would return the selected candidates to build. But that doesn't prevent the ebuild from using further logic with other flags, etc. So taking your example, the ebuild would do the whole gui-* flag family thing as I described, get the results for that, and could then either do another family setup and get more results, or could throw in more conventional flags. And one such flag, possibly individual at first, wold be cli-qt-5, controlling this option separately. If later there were enough such flags to make a cli-* family, existing ebuilds using cli- qt-5 would continue to use that individual flag, while revision-bumps or new versions could start using the cli-* family, setting it up using UH-* variables and calling the function again, getting a CLI result which could be used, just as they got a GUI result to use. --- [1] https://en.wikipedia.org/wiki/Colossal_Cave_Adventure -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: www-client/chromium gtk3 support
On Sat, Sep 12, 2015 at 6:00 AM, Duncan <1i5t5.dun...@cox.net> wrote: > > Just bite the bullet and create entire USE flag families such that an > ebuild can choose the flag appropriate to how it actually uses it. AFAIK > this would need EAPI help, for reasons given below, but it should be > doable. > > gui > gui-gtk > gui-gtk-2 > gui-gtk-3 > gui-qt > gui-qt-4 > gui-qt-5 I'm going to have to read the rest of your email about 14 times to fully grok it, but one thing that strikes me about this approach, and perhaps mine as well, is that this assumes that USE=-gui should imply USE="-gtk -qt" or similar. What if qt or gtk is used for more than just the GUI. What if the console version of the program still uses other functions in these toolkits besides window decoration/etc? Granted, I suspect that in such a case turning off any of this stuff is probably not build-time-configurable. If you want the console-only version you'd just pass the appropriate command line option (like deluge's --ui option). However, it is conceivable that you could design a build system so that the GUI requires qt and libfoo, spell check requires qt only, and you could build the program with GUI support, spell check support, or neither. If you built with USE="-gui spellcheck" then you'd want qt enabled but libfoo disabled. That is obviously a highly contrived example and perhaps we don't need to worry about this scenario. However, it does illustrate the general danger of making USE flags a strict hierarchy. A hierarchy like qt/qt4 is probably fairly safe, but when you generalize to gui/qt/qt4 you're making the assumption that qt is only used for guis. But I do like the concept, well, conceptually. -- Rich
[gentoo-dev] Re: www-client/chromium gtk3 support
Rich Freeman posted on Fri, 11 Sep 2015 08:13:48 -0400 as excerpted: > USE=gui or something like that if the main effect is to have a gui or > not. > That is the sort of thing that SHOULD go in make.conf or in a profile. > If disabling gtk makes it a console-only application then use the gui > flag. I like the general proposal, but since it's going to council, can we try to kill another bird with the same stone? This USE=gui helps... Wayland's coming, and to the extent that USE=X has previously indicated a GUI, much like USE=gtk and USE=qt indicating the same thing, we're going to have problems. Can we make USE=gui the generic policy for that, and deprecate more specific forms for choosing /any/ gui, so they can be used for choosing /which/ gui? Then of course ordain both X and wayland USE flags for choosing specific gui platform, like gtk and qt did at their level traditionally. The question then remains whether ncurses, etc, should be treated as a gui. Maybe make mention of that one way or the other in the policy as well. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: www-client/chromium gtk3 support
On Fri, Sep 11, 2015 at 1:11 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Rich Freeman posted on Fri, 11 Sep 2015 08:13:48 -0400 as excerpted: > >> USE=gui or something like that if the main effect is to have a gui or >> not. >> That is the sort of thing that SHOULD go in make.conf or in a profile. >> If disabling gtk makes it a console-only application then use the gui >> flag. > > I like the general proposal, but since it's going to council, can we try > to kill another bird with the same stone? This USE=gui helps... > > Wayland's coming, and to the extent that USE=X has previously indicated a > GUI, much like USE=gtk and USE=qt indicating the same thing, we're going > to have problems. > > Can we make USE=gui the generic policy for that, and deprecate more > specific forms for choosing /any/ gui, so they can be used for choosing > /which/ gui? That was exactly why I used "gui" and not "X". We're going to run into the exact same problem once Wayland comes along with the way things have been done so far. > > The question then remains whether ncurses, etc, should be treated as a > gui. Maybe make mention of that one way or the other in the policy as > well. > I actually was pondering that and left it out of my email. My gut feeling is that ncurses should be left alone for now. USE=-gui would mean console-only, whether that happens to include support for ncurses, aa, or whatever. Are there any applications out there which behave dramatically differently if they do/don't have ncurses support built-in? If you set TERM=dumb I imagine that software which actually supports this would just behave accordingly (ie if it is just using colors or moving progress bars or whatever it will drop the decorations). Usually though dumb terminal software tends to be somewhat dedicated (for things like editors and the like). I don't want to complicate things if nobody really cares about them. However, in theory you could treat various console-enhancing libraries in the same way. There is also svgalib and the like. -- Rich
[gentoo-dev] Re: www-client/chromium gtk3 support
hasufell posted on Thu, 10 Sep 2015 10:47:26 +0200 as excerpted: > On 09/10/2015 08:21 AM, Daniel Campbell wrote: >> >> For me to not support gtk2 in the spacefm ebuild would be providing a >> package inferior to upstream. > > That sounds like spacefm with gtk3 is lacking anything. It is not. > Providing choice for the sake of choice is not always a good idea. Nothing personal, but... Seeing this coming from a gentoo dev, where user choice and control is viewed as a virtue, is a shame. There's a reason gentoo has USE flags and doesn't default to binaries. Particularly where upstream is deliberately providing the choice, specifically to allow the users that choice, having gentoo abort that choice seems to stand in the way of everything gentoo and Larry the cow is about. (Tho I must say, it does sound like typical upstream gnome think. Restrict user choice, it's for their own good! I've never understood how some gentooers could tolerate such an attitude and use gnome as a preference, as it really is antithetical to gentoo's whole stance on choice, but of course given that there are devs willing to make it available, removing gnome as a choice for those who wish to go that way would be antithetical to that ideal as well, so there you have it.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: www-client/chromium gtk3 support
hasufell posted on Thu, 10 Sep 2015 17:35:53 +0200 as excerpted: >> Again, I'm saying that maintainers should be free to support multiple >> versions if they wish to do so. They should not be required to do so. >> And yes, I do realize that this limits options for users, but they're >> welcome to proxy-maintain packages that do support the versions they >> wish to use. If they want to fork upstream they're even welcome to do >> that, but obviously that isn't going to happen often. >> >> I just don't think we should be in the business of saying "no" here. > > Again, your proposed use case is 1) imaginary 2) currently impossible to > support, because there are lots of applications which either force gtk3 > in the ebuild or have only gtk3 supported upstream. It will be pretty > much impossible to not have gtk3 installed or loaded into RAM, unless > you don't use a DE in the first place and stick to terminals. Pretty much impossible? For a kde and gtk2-based software user? Not so much. I've only one package here using gtk3, a relatively recent addition to a set in my world-sets file, and it's a rather optional package (solaar, for managing my Logitech wireless devices), with a CLI- only option, so I've been thinking about disabling gtk3 support just to avoid having to hassle the gtk3 and supporting software updates. One thing I learned fairly quickly with gentoo is that unlike binary distros, over time there's a real cost to one-off or two-off dependencies, because they aren't just single-time builds, but are generally updated and must be repeatedly rebuilt over time. For things you /might/ use, or do use occasionally, but only perhaps yearly or less often, it's often more efficient to merge on-demand, then unmerge again, until they happen to be needed again, than it is to keep them and dependencies current the whole time. (Tho obviously, this applies more to ~arch users who do --deep updates, than others.) In that context, given the current usage of gtk3 in-tree, it's quite realistic for a user to wish to avoid gtk3, if they've a number of gtk2- only apps (as I do). Similarly the other way of course, for those with a number of gtk3 apps, they may wish to avoid gtk2 and gtk2-only apps, if they can, to avoid it being on their system, tho AFAIK with both chromium and firefox being gtk2 at this point, that's a bit more difficult. Unfortunately, gentoo/gtk's attitude makes this much more difficult than it should be. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: www-client/chromium gtk3 support
hasufell posted on Thu, 10 Sep 2015 18:57:43 +0200 as excerpted: > On 09/10/2015 04:31 PM, Vadim A. Misbakh-Soloviov wrote: >> WE HAVE NO RIGHT TO DICTATE users what they should use and what they >> should not. @ Vadim in particular: FWIW, some people are much more sensitive to short runs of ALL CAPS than others. To some, ALL CAPS is ALWAYS SHOUTING, while to others (me, apparently you/Vadim), ALL CAPS can also mean emphasis, as long as the run isn't too long. (I do think that most would agree that whole sentences and certainly whole paragraphs in all caps is shouting, and just as uncomfortable to read as shouting tends to be to listen to.) So I've learned (the hard way) to use *stars* or _underlines_ (or for lower levels, /italics/) for emphasis, and only use ALL CAPS when I really do intend to SHOUT, which isn't often. Given that, many will interpret the above as a SHOUTED DEMAND, which probably isn't what you intended, even if you (as I) feel rather strongly about it in general. > You should really either reconsider your understanding of opensource or > start to pay me. hasufell has a point here, particularly when the above is interpreted as a SHOUTED DEMAND due to the all caps. It is said that he who codes, makes the rules, and that really does tend to be the case. Yes, the code is open to others to do with as they wish (including fork, etc, as hasufell suggests), but the coder could have just done something else instead, and it's their time they're taking, often as volunteers, to make it available to you in the first place. Thus, as you'll see, the argument from most supporting the choice position is that it's the package maintainer's choice, that should the package maintainer choose to support both toolkits, particularly in view of upstream specifically doing the same, he should be encouraged to do so. No demands of the maintainer, and the argument would be entirely different, should the maintainer choose not to support both toolkits. (Which, BTW, is why when gentoo/kde temporarily decided not to support turning off semantic-desktop in kde4 any longer, despite upstream kde continuing to support that choice at least thru the kde4 series, I did actually fork the kde ebuilds, maintaining my own patches in ordered to continue to support kde without the semantic-desktop, when gentoo/kde would no longer do so. I even opened a discussion on the desktop list on the topic of trying to get a user supported overlay going, similar to the kde-sunset overlay used for kde3, when it was removed from the tree. However, shortly after I did so, someone in the gentoo/kde project decided they needed the no-semantic-desktop option and were thus willing to support it in the project, so the USE flag was brought back and the overlay discussion could be dropped. No DEMANDING continued gentoo/kde support, despite continued upstream support, and had I DEMANDED it, I believe it quite possible the gentoo/kde project would have voted the other way when the one dev actually decided it /was/ worth supporting, and we'd probably be having to do it in an overlay, today.) But when the maintainer himself is willing to support it, no demands, as others have argued and I agree, gentoo and the gentoo/gtk project shouldn't stand in the way. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
