I just emerged portage-2.1_pre3-r1, and found that the USE flags, when doing a `emerge -pv`, are now separated between activated and desactivated ones... it means we have to check two different places, when trying to find a USE flag, because they now aren't strictly alphabetically sorted, which is a bad idea.
There are several reasons to examine the list of flags that I can think of. 1) Checking if a package supports a certain flag 2) Checking the status of a known supported flag These are easiest done with a sorted list. 3) Checking which flags are enabled 4) Checking which flags are disabled 5) Checking which flags have changed to enabled 6) Checking which flags have changed to disabled 7) Checking which flags are new to the package and are enabled 8) Checking which flags are new to the package and are disabled These six are all easier when the list is sorted by enabled and then disabled. Action 1 is the least likely of all the possible actions. Action 2 can be performed by scanning the smaller of the enabled and disabled lists - if you know the package supports a flag and is not in the smaller of the two lists then it must be in the other. Can you explain a little better why it's a bad idea please?
(In reply to comment #1) > > 3) Checking which flags are enabled > 4) Checking which flags are disabled > Coloring, and the '-' symbol, are enough for the eye to quickly spot enabled and disabled USE flags. > > 5) Checking which flags have changed to enabled > 6) Checking which flags have changed to disabled > Coloring, and the '*' symbol, are enough for the eye to quickly spot the changes. > > 7) Checking which flags are new to the package and are enabled > 8) Checking which flags are new to the package and are disabled > The new coloring, and the new '%' symbol, are enough for the eye to quickly spot the new USE flags (and is indeed a nice enhancement). > > These six are all easier when the list is sorted by enabled and then disabled. > No; for most people, alphabetic order will always be easier and quicker to parse. Breaking the alphabetic order leads to confusion. > > Action 2 can be performed by scanning the smaller of the enabled and disabled > lists - if you know the package supports a flag and is not in the smaller of > the two lists then it must be in the other. > No; most often, you want to be sure, and just have to check the other part... (except if you know the whole list by heart, which shouldn't be the case for most people and for most packages...) > > Can you explain a little better why it's a bad idea please? > I might not be a usability expert (yet), but this separation between activated and desactivated USE flags, is a regression (at least for most people). If some people really feel it is faster and easier to have this separation (we all are different), then you should create a new portage option, like "--sort-enabled-from-disabled-use-flags", so this separation would not be activated by default.
(In reply to comment #2) > (In reply to comment #1) > > 3) Checking which flags are enabled > > 4) Checking which flags are disabled > > Coloring, and the '-' symbol, are enough for the eye to quickly spot enabled > and disabled USE flags. I was talking from an overview perspective. At the moment, it's difficult to tell what's enabled and what's not. > > 5) Checking which flags have changed to enabled > > 6) Checking which flags have changed to disabled > > Coloring, and the '*' symbol, are enough for the eye to quickly spot the > changes. The color and symbol is the same for both so there is no easily distinguishable feature between enabled and disabled. > > 7) Checking which flags are new to the package and are enabled > > 8) Checking which flags are new to the package and are disabled > > The new coloring, and the new '%' symbol, are enough for the eye to quickly > spot the new USE flags (and is indeed a nice enhancement). Again, enabled or disabled status is not easily distinguishable. > > These six are all easier when the list is sorted by enabled and then > > disabled. > > No; for most people, alphabetic order will always be easier and quicker to > parse. Breaking the alphabetic order leads to confusion. By "parse" I believe you mean the 8 actions I listed but I honestly can't see how they are negatively affected. Alphabetic order is not broken, by the way. Flags are sorted alphabetically after being put into one of the two groups. > > Action 2 can be performed by scanning the smaller of the enabled and > > disabled lists - if you know the package supports a flag and is not in the > > smaller of the two lists then it must be in the other. > > No; most often, you want to be sure, and just have to check the other > part... (except if you know the whole list by heart, which shouldn't be the > case for most people and for most packages...) This is the only case that I can see purely alphabetic sorting as being beneficial. You have a specific flag in mind but don't know if the package supports it or not. This would seem to be the rarest pattern of all. > > Can you explain a little better why it's a bad idea please? > > I might not be a usability expert (yet), but this separation between > activated and desactivated USE flags, is a regression (at least for most > people). I'm still not convinced. Can you give an example (other than the case of having a specific flag in mind that you want to check if a package supports) where you can show the mental steps that need to be taken is shorter with the flags being in purely alphabetical order? > If some people really feel it is faster and easier to have this separation > (we all are different), then you should create a new portage option, like > "--sort-enabled-from-disabled-use-flags", so this separation would not be > activated by default. Continuing down this path would cause a usability problem.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > 3) Checking which flags are enabled > > > 4) Checking which flags are disabled > > > > Coloring, and the '-' symbol, are enough for the eye to quickly spot enabled > > and disabled USE flags. > > I was talking from an overview perspective. At the moment, it's difficult to > tell what's enabled and what's not. > > > > 5) Checking which flags have changed to enabled > > > 6) Checking which flags have changed to disabled > > > > Coloring, and the '*' symbol, are enough for the eye to quickly spot the > > changes. > > The color and symbol is the same for both so there is no easily distinguishable > feature between enabled and disabled. > > > > 7) Checking which flags are new to the package and are enabled > > > 8) Checking which flags are new to the package and are disabled > > > > The new coloring, and the new '%' symbol, are enough for the eye to quickly > > spot the new USE flags (and is indeed a nice enhancement). > > Again, enabled or disabled status is not easily distinguishable. > The separation won't help, if the changed/new USE flags are the last of the activated USE flag list, or at the beginning of the desactivated USE flag list... it won't help, and again, confusion will arise. > > > These six are all easier when the list is sorted by enabled and then > > > disabled. > > > > No; for most people, alphabetic order will always be easier and quicker to > > parse. Breaking the alphabetic order leads to confusion. > > By "parse" I believe you mean the 8 actions I listed but I honestly can't see > how they are negatively affected. Alphabetic order is not broken, by the way. > Flags are sorted alphabetically after being put into one of the two groups. > Then, as I said, we have to check two different lists, to find a USE flag... and as the separation between the two lists is not clear (in this case, coloring is not enough), we can't reconize the alphabetic order... (if we don't scan the list linearly, which is the way most people will scan the list) > > > Action 2 can be performed by scanning the smaller of the enabled and > > > disabled lists - if you know the package supports a flag and is not in the > > > smaller of the two lists then it must be in the other. > > > > No; most often, you want to be sure, and just have to check the other > > part... (except if you know the whole list by heart, which shouldn't be the > > case for most people and for most packages...) > > This is the only case that I can see purely alphabetic sorting as being > beneficial. You have a specific flag in mind but don't know if the package > supports it or not. This would seem to be the rarest pattern of all. > Even if you know the USE flag should exist for a specific package (because you saw/set/unset it before), there is always a need to be sure it is there... so you'll have to check the two lists... As I said, people who really know the USE flags by heart (because they emerged the package and checked the USE flags multiple times, because they maintained the package, etc.), may skip checking the other list, but I'm pretty sure it is not common. > > > Can you explain a little better why it's a bad idea please? > > > > I might not be a usability expert (yet), but this separation between > > activated and desactivated USE flags, is a regression (at least for most > > people). > > I'm still not convinced. Can you give an example (other than the case of having > a specific flag in mind that you want to check if a package supports) where you > can show the mental steps that need to be taken is shorter with the flags being > in purely alphabetical order? > 1) USE flags like "sse" and "sse2", in a long list, like media-video/mplayer, would be separated, if one is activated, and not the other... if you don't know there is two similar USE flags, you may stop at the first one, if you don't scan the whole list... (same with "gtk"/"gtk2", "jpeg"/"jpeg2k", "kerberos"/"krb4", "mysql"/"mysqli", "oracle"/"oracle7", "xml"/"xml2", etc.) 2) When you scan the list in a non-linear way (again, as most people will do, most of time, even when trying to find a specific USE flag), like if you wan't to check if there might be an USE flag to activate or desactivate, you can't apprehend the whole list, because the alphabetic order is broken... your eyes will just jump from place to place, without any point of reference, because you can't rely on the alphabetic order... (if you are used to the separation between activated and desactivated USE flags, you won't be confused, but you'll have to check the two lists... (however, as said, if there are new/changed USE flags, at the border between the two lists, you will really have a hard time separating the two lists... even more if there are new/changed USE flags on both sides of the border... the coloring really will confuse you, in this case)) > > If some people really feel it is faster and easier to have this separation > > (we all are different), then you should create a new portage option, like > > "--sort-enabled-from-disabled-use-flags", so this separation would not be > > activated by default. > > Continuing down this path would cause a usability problem. > Well, it's not as if most computer software were usable, to begin with... anyway, people who feel they benefit from the separation will just create an alias, so it really won't matter much for them.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Coloring, and the '*' symbol, are enough for the eye to quickly spot the > > > changes. > > > > The color and symbol is the same for both so there is no easily distinguishable > > feature between enabled and disabled. > > The separation won't help, if the changed/new USE flags are the last of the > activated USE flag list, or at the beginning of the desactivated USE flag > list... it won't help, and again, confusion will arise. Sure, there's always a corner case. I don't see where the confusion comes from though. The way I see it, when a flag with an asterisk, whether it is enabled or not can be immediately be distinguished by it's surrounding flags or it can't. The case where it can't is only when the flag falls on the border between the two groups. In that case, the user must specifically check via other symbols whether the flag is enabled. If the groups aren't sorted, the user must always check for secondary symbols to discern the status of the flag. Yes, this could be alleviated by not sorting the lists and adding yet more colors. There's already four colors to typify flags though and increasing that to six will essentially make the colors useless too. Hmm.. or would it? Okay, presently we have: enabled: red disabled: blue changed: green new: yellow If that were changed to something like: normal: red for enabled, dark red for disabled changed: green for enabled, dark green for disabled new: yellow for enabled, dark yellow for disabled All goals would be achieved, no?
(In reply to comment #5) > normal: red for enabled, dark red for disabled > changed: green for enabled, dark green for disabled > new: yellow for enabled, dark yellow for disabled > > All goals would be achieved, no? Green for changed doesn't work because darkgreen is the color used for package names. normal:blue, changed:red, new:yellow seems to work well though. There's a sample screenshot at http://dev.gentoo.org/~jstubbs/use_output.png
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > (In reply to comment #2) > > > > Coloring, and the '*' symbol, are enough for the eye to quickly spot the > > > > changes. > > > > > > The color and symbol is the same for both so there is no easily distinguishable > > > feature between enabled and disabled. > > > > The separation won't help, if the changed/new USE flags are the last of the > > activated USE flag list, or at the beginning of the desactivated USE flag > > list... it won't help, and again, confusion will arise. > > Sure, there's always a corner case. I don't see where the confusion comes from > though. The way I see it, when a flag with an asterisk, whether it is enabled > or not can be immediately be distinguished by it's surrounding flags or it > can't. The case where it can't is only when the flag falls on the border > between the two groups. In that case, the user must specifically check via > other symbols whether the flag is enabled. > If the groups aren't sorted, the user must always check for secondary symbols > to discern the status of the flag. > > Yes, this could be alleviated by not sorting the lists and adding yet more > colors. There's already four colors to typify flags though and increasing that > to six will essentially make the colors useless too. Hmm.. or would it? > > Okay, presently we have: > > enabled: red > disabled: blue > changed: green > new: yellow > > If that were changed to something like: > > normal: red for enabled, dark red for disabled > changed: green for enabled, dark green for disabled > new: yellow for enabled, dark yellow for disabled > > All goals would be achieved, no? > The new/changed USE flag colors and symbols are meant to be quickly and easily spotted in the list... using two colors, even similar, to differentiate activated from disactivated USE flags, would defeat this purpose. I don't think that having to check the for a '-' symbol, to see if the new/changed USE flag now is enabled or disabled, is that a problem... it is only a temporary measure, and in fact, having the user think a bit more about the status of the new/changed USE flag, is a benefit, as we want to be sure the user understand that functionalities might be removed, added, or not added, from the package...
So... I've been discussing this a bit with developers (users tend to not be handy ;) and seven out of eight (or thereabouts) prefer the output of 2.1_pre3. Not that I mean to throw your opinion away as ignorant. Here's why I made the ordering change: * If it's a new package, all flags need to be scanned regardless of the ordering. If the admin is familiar with what flags are globally enabled, only the disabled flags need to be scanned. * When a package is upgraded, the important flags are those that are changed or new to the package. If what flags are available needs to reconfirmed, a full scan of the list is the only recourse. To be brutally honest, I haven't been able to find any strictly logical reason for purely alphabetical sorting. Continuing the brutal honesty, it seems that you're either relating that which is written in books or fear any change. As I said above, I definitely value your opinion (doubly so seeing one of the devs I spoke to seems to partially agree with you) but I need more than "alphabetic ordering will be quicker and easier". To be specific, please list out, as you see them to be, what the most common use cases are for interpreting the flag list are and why an alphabetic ordering would serve those use cases better than an ordering that is first sorted by status.
Reason for sorting: it's easy to find a flag. Don't want to have to look in six places to see whether fnord is enabled... Also, use.masked flags should still be shown, since knowing that an option is there but not available is important. Also also, drop the USE="" bit and only show names for EXPANDBLAH=.
(In reply to comment #8) > So... I've been discussing this a bit with developers (users tend to not be > handy ;) and seven out of eight (or thereabouts) prefer the output of 2.1_pre3. Well, as said, most computer software are not usable. > > Here's why I made the ordering change: > * If it's a new package, all flags need to be scanned regardless of the > ordering. If the admin is familiar with what flags are globally enabled, > only the disabled flags need to be scanned. > * When a package is upgraded, the important flags are those that are changed > or new to the package. If what flags are available needs to reconfirmed, > a full scan of the list is the only recourse. > Scanning the whole list is quicker and easier to apprehend, when the USE flags are in alphabetic order. Users need sure references; alphabetic order is the most sure reference. > > To be brutally honest, I haven't been able to find any strictly logical reason > for purely alphabetical sorting. > It's not a matter of logic. We are talking about humans, not robots. The alphabetic order is a matter of habit, and we apprehend a list more quickly and easily, when the sorting is clear and simple. We use alphabetic order everywhere, for everything; it is, as with numeric order, the most effective ordering, because fof this. Users don't care about what should be, logically, the most effective order... they care about what is, for them, the most effective order... again, if some people feel separating the activated from the desactivated USE flags, is more clear to them, just make it an option... if people want to learn a new multidimensional ordering, which might be more efficient, they will try it... but is it worth it? (and is it really more efficient? if you can't rely on strict alphabetic order, nor on a somewhat fixed position in the list -when there are no new USE flag-?) > Continuing the brutal honesty, it seems that > you're either relating that which is written in books or fear any change. I don't need book for this, and fear no change (at least when they are good to me). What I fear is less usability, when computer software already are so unusable. > > As I said above, I definitely value your opinion (doubly so seeing one of the > devs I spoke to seems to partially agree with you) but I need more than > "alphabetic ordering will be quicker and easier". > I'm sorry I can't explain this better; it just feel right to me, and I still lack the academic background, which would probably give me the words and arguments to defend to point I'm trying to make (moreover, English isn't my mother tongue). > To be specific, please list out, as you see them to be, what the most common > use cases are for interpreting the flag list are and why an alphabetic > ordering would serve those use cases better than an ordering that is first > sorted by status. > I already said everything I feel was needed... alphabetic (or numeric) order is needed, for most people, to quickly and easily apprehend a list... changing this, even if, after getting used to it, scanning the list for changes might be a bit quicker (which I doubt -because the separation between the two lists is not clear, because we need to scan two different lists to scan all the USE flags, and because strict alphabetic order is what we all know and use everyday since we learn our letters), is not worth the effort. Making it an option is the way to go... people who want to try an alternative order, will try the option (and try to get use to it), and the others will just use what they are used to (in daily life, and in Gentoo), a strict alphabetic order, which is good, because the users are used to it (and it feels pretty logic to me, even if I guess there are way better sorting we might want to try -for those interested). I won't insist, you are the developper here, do what you feel is right (well, it's already done, in this case). I'm just pretty sure it is wrong, and I'm sorry if I couldn't convince you (it seems to be pretty common, for usability people... however, I guess I'm still lacking experience). Cya.
(In reply to comment #9) > Also also, drop the USE="" bit This is a good change... easier for copy-pasting and easier to understand... it should be kept... why do you want it to be dropped? (well, maybe you should open another bug report, if you really have arguments)
The USE= is a waste of screen space. We know fine well it's USE.
For the sake of us who uses a white background on console... the yellow bit is almost unreadable... there's hope to get something more readable?
Mathieu, are you a usability expert? Has anyone done usability tests on this, actually watching how people react and figure things out the new way vs the old way?
(In reply to comment #14) > Mathieu, are you a usability expert? As said, I'm not, but I'm pretty interested in this kind of things, and hope to work in this field, in some years. > > Has anyone done usability tests on this, actually watching how people react > and figure things out the new way vs the old way? > I don't feel there is any need for serious usability testing... breaking the alphabetic order seems a basic usability error to me, in most cases... (and I really felt confused myself). We can break the alphabetic order, to classify the USE flags into definitive categories, like "video codecs", "audio codecs", "ouput codecs", etc. for the media-video/mplayer USE flags... the strict alphabetic order will be broken, but the USE flags won't change place everytime we change their activated/desactivated status, so we would have a sure point of reference, to apprehend the list, which we won't have otherwise... this change would make the scanning and apprehension quicker and easier, because of the added sure information... -activated/desactivated status is variable, of course- (However, this change would need much screen space, and we would have to avoid new lines in categories, or find a way to group them anyway, -and find a way to group some USE flags temporarily, in a "misc" category, if their category is too small or non-important in the package context- so it might not be a good sorting for today consoles... it's just an example of a sorting which break the strict alphabetic order -categories and category elements would be alphabetically sorted, of course-, with added value...)
I'll be very short: - please revert this ordering, it's confusing and takes a lot more time to read - USE= is reduntant; - and that yellow sucks, as Flameeyes said. Thanks.
I agree, revert the formatting - very leaste remove the USE=" bit
(In reply to comment #16) > I'll be very short: > > - please revert this ordering, it's confusing and takes a lot more time to read Not "a lot", just "more". > > - USE= is reduntant; > It isn't, it only takes 6 characters (mplayer has like 450 characters of USE flags), it is useful when copy-pasting the package name and its current USE flags, and even if beginners sure learn this kind of things quickly, it still is a usability advantage, to describe things on the screen. I don't know how much time it would take to make it an option, and I'm sure it's not worth it, but if you don't mind, just make the 'USE=""' display, a default option... (with an option like "--do-not-display-the-use-flag-variable-name", to not display it). > > - and that yellow sucks, as Flameeyes said. > Well, as dark blue is hard to read on a black background... Would there be a way for the user to change those colors? (or maybe for the program to detect the background color and apply a different color theme if the background color is dark, or if it is light?)
(In reply to comment #18) > > - USE= is reduntant; > > It isn't, it only takes 6 characters (mplayer has like 450 characters of USE > flags), it is useful when copy-pasting the package name Huh? Using USE="" as an environment variable is considered harmful. I demand my six characters back. Now, since the bike shed is getting a new coat of paint, why aren't SLOTs displayed?
(In reply to comment #19) > (In reply to comment #18) > > > - USE= is reduntant; > > > > It isn't, it only takes 6 characters (mplayer has like 450 characters of USE > > flags), it is useful when copy-pasting the package name > > Huh? Using USE="" as an environment variable is considered harmful. It is perfectly fine for limited temporary tests (no depclean, I guess?), and to indicate which USE flags are activated and which are not, with a tiny description of what is this keyword string after the package name... (you may not care, it does not mean it has to be removed, when it should be useful for most people... well, as said, it might be made as an option -with the variable name displayed by default-, but it should not be removed).
(In reply to comment #0) While I can live with the ugly %s appended to the USE flags (makes it look like it's not parsing the code correctly, though), "-auD" or "-puD" should not display the same (or nearly) the same output as the "-vpuD" option. This ("--verbose" should _not_ be on by default. There's a reason why we want functionality *switches*. If we want it, we'll ask for it. Granted, I always do -v first before finalizing the emerge, but it clutters up the initial output, especially in regards to unexpected line breaks and wrapping. Please remove this odd new default --verbose from emerge. Let it remain an option with "-v".
Just adding my voice to Mathieu's about alphabetic ordering and to Diego's about unreadable yellow flags.
Adding my "me too"to this bug. After installing and using 2.1_pre3, I have to agree that it would be more usable if the USE flags were strictly alphabetically sorted.
(In reply to comment #3) > > The color and symbol is the same for both so there is no easily distinguishable > feature between enabled and disabled. > Maybe a '+' sign should be added, before activated USE flags... I often thought it would be better this way, to set and print USE flags... Well, it might not be perfect for all uses, some would complain about screen space, and maybe more than I can think about, depend on this lack of '+' sign for activated USE flags (portage seems to ignore the '+' sign ("+foo" is egal to "foo", and "-+foo" and "+-foo" is egal to "-foo"), so it should be ok -after removing the warning about the '+' sign), so it should be an non-default option, at least for some time... (anyway, the lack of '+' sign should still mean the same, and not just for abvious compatibility reasons) Was there a particular reason why we don't use the '+' sign before activated USE flags?
*** Bug 118155 has been marked as a duplicate of this bug. ***
As I said in #118155, this change leads to confusion. It would be better to AT LEAST have the option of having use flags listed in alphabetic order, for those of us who are just users, not developers. The old style has been always enough for all my purposes, and I don't see any advantage in this new approach, I just find it confusing. On the other hand, I would also remove the "USE=" bit from the emerge output, but that's more of an aesthetical bother than a usability one, so it's not a big deal if it stays.
This seems to be the bug where the new USE= display is comming from. Jason, Can we limit the USE= and [oldversion] display to -pv vs -p alone to keep compat with existing scripts. I'd also think that the USE="" is a tad reduntant and could confuse people who might try to copy +paste the display into make.conf.
(In reply to comment #26) > As I said in #118155, this change leads to confusion. It would be better to AT > LEAST have the option of having use flags listed in alphabetic order, for those > of us who are just users, not developers. This is not something worth having a configuration option over. Just pick one way or the other and stick with it.
> This is not something worth having a configuration option over. Just pick one > way or the other and stick with it. Hm.. go back to the old way then :)
About the USE variable name display, when doing an `emerge -pv`, I just found this: https://bugs.gentoo.org/show_bug.cgi?id=23826#c16 Look at the example (comment 16, by Jason (did you forget? ;))): [ebuild R ] sys-apps/portage-2.0.51.22-r1 -build (-selinux) LINGUAS="+en +ja" 0 kB As other informations may, in the near future, be displayed after the USE flags, I guess no one will complain anymore about the USE variable name display, will you? (and there is a '+' sign before activated languages? was this just an example, or will it really be used?)
Personally I find the new way much easier to parse visually and less of a strain on my eyes.
I'm also not much for the new style. The color highlighting is IMO sufficient to identify the different kind of flags easily, sorting that doesn't really give any benefit. As has been pointed out the advantage with alpha sort is that it makes finding flags easier, for example when checking with use.desc (with the new way you'd have to scroll up and down all the time instead of just down once). While the USE="" part could be seen as redundant it makes the overall output more consistent. As for displaying flags without -v, I can see both the pros and cons for that one, so I'm undecided on it. And yes, the yellow is unreadable on white background. Well, guess it's time for adding output filter support ...
(In reply to comment #32) > I'm also not much for the new style. The color highlighting is IMO sufficient > to identify the different kind of flags easily, Except for the color blind, or when emerge is writing to a non-tty (thus disabling color), so some type of marking is required.
(In reply to comment #33) > Except for the color blind, or when emerge is writing to a non-tty (thus > disabling color), so some type of marking is required. > When there is no coloring, it's even harder to apprehend the USE flag list, when the USE flags are not strictly alphabetically sorted... (just try) Some way to enhance the display, which would benefit to everyone, but especially when not using coloring (or when the user sees only tones of gray): - The USE flags should be correctly capitalized ("Debug", "DirectFB", "GIF", "Joystick", "TrueType", etc.), as it grealty enhance readability... however, most people don't even think about it, and use strange capitalization patterns, including names only in lowercase (that's where case sensitive filenames might be a problem... -well, in today operating systems, at least), as official names... some even officially use different capitalization patterns, without thinking about it... (even some big companies do this, which is bad for the product name...) and then, some multiple words names are stuck with dashes, others with underscores and others without anything... (and yet others with spaces, of course, which should be the best, but developpers don't seem to like spaces...) all this leads to the fact that correct (i.e.: official) capitalization don't work as good as it should... - Separate USE flags using commas, instead of spaces... but it would cause major incompatibilities... - Group USE flags in a dark bordered rectangle, with a very light background (if text color is dark, and vice versa if the text color is light -well, black on light background should be the best for most people)... but today consoles might not be advanced enough for the result to be acceptable/portable... - As I said in other comments above, separating (and not just with spaces) USE flags into functionnalities ("audio output codecs", "image formats", "compression formats", etc.) do breaks the strict alphabetic order, but makes finding a USE flag easier and quicker... but as also said, it would be hard to display USE flags this way, using today consoles...
(In reply to comment #33) > (In reply to comment #32) > > I'm also not much for the new style. The color highlighting is IMO sufficient > > to identify the different kind of flags easily, > Except for the color blind, or when emerge is writing to a non-tty (thus > disabling color), so some type of marking is required. You still have the +,-,* and % pre-/suffixes for that
Okay, people love to get off track, don't they? This bug is only about alphabetic ordering or enabled/disabled followed by alphabetic ordering. None of the other issues discussed pertain to any sort of usability regression. So, there are many voices asking to go back to the old way but the only argument each side has put forward is that it's easier to read. For enabled/disabled ordering, I think I've clearly stated the benefits. For alphabetic ordering, I think it goes something like: * "People are creatures of habit" and "you can't teach an old dog new tricks". I can't really see beyond those two as the current ordering is not really hard to learn. * People are generally unsure of themselves. By that I'm referring to the argument of needing to check two lists to see if a flag is available. This argument I can accept and is the only real argument against enabled/disabled ordering that I can see. Did I miss anything there? We really need to be stating more than "alphabetic rules all" and the "the old way is better" to get anywhere here. What is needed is specific cases of "I wanted to do/check this and the enabled/disabled order makes it more difficult because..." As for all the other things discussed... Adding USE="" was done for consistency. Removing the plus signs before enabled flags was done for consistency. Both of these are there so that the output directly correlates to what a user would find (or should put into) make.conf. Yes the characters denoting changed and added flags work against this but it's much closer than before. Adding flag output to --pretend output when --verbose isn't specified is also for usability. The main purpose for using --verbose is to find out what flags are available for a new package and what flags have changed for an existing package. It is that information which is displayed and takes up very little screen space in the general case. Using the --quiet option will restore the previous behaviour of no flag output at all and is backward compatible with 2.0 portages allowing scripts to be easily migrated. Configurable colour output is a good thing and something I'm planning on doing later (if no-one else gets there first) but really deserves a bug of its own.
You're making it harder to check whether a particular flag is enabled. It's a usability regression. Also, why not change the bug to be about all the other usability regressions too rather than forcing someone to copy half of the comments in this bug into yet another bug?
(In reply to comment #37) > You're making it harder to check whether a particular flag is enabled. It's a > usability regression. It's no harder to check whether a particular flag is enabled. In fact it's easier. There's only the first "half" of the list to scan rather than a full list.
(In reply to comment #38) > It's no harder to check whether a particular flag is enabled. In fact it's > easier. There's only the first "half" of the list to scan rather than a full > list. And then the second "half" to make sure that the flag in question still exists.
*** Bug 119244 has been marked as a duplicate of this bug. ***
(In reply to comment #37) > You're making it harder to check whether a particular flag is > enabled. It's a usability regression. Which is what this bug covers... > Also, why not change the bug to be about all the other usability > regressions too rather than forcing someone to copy half of the > comments in this bug into yet another bug? 1) No other possible usability regressions have been mentioned. 2) "Super" bugs end up never being resolved because new issues are continually added. (In reply to comment #39) > (In reply to comment #38) > > It's no harder to check whether a particular flag is enabled. In > > fact it's easier. There's only the first "half" of the list to > > scan rather than a full list. > > And then the second "half" to make sure that the flag in question > still exists. (Excerpt from comment #36) > * People are generally unsure of themselves. By that I'm referring > to the argument of needing to check two lists to see if a flag is > available. This argument I can accept and is the only real > argument against enabled/disabled ordering that I can see.
(In reply to comment #36) > Okay, people love to get off track, don't they? > > This bug is only about alphabetic ordering or enabled/disabled followed by > alphabetic ordering. None of the other issues discussed pertain to any sort of > usability regression. Hmmm? Why do we need multiple overlapping bugs about the same issue (usability regression or emerge -pv output)? (In reply to comment #39) > (In reply to comment #38) > > It's no harder to check whether a particular flag is enabled. In fact it's > > easier. There's only the first "half" of the list to scan rather than a full > > list. > > And then the second "half" to make sure that the flag in question still exists. Yeah... two weeks later, I still hate the new output, takes a lot longer to check the use flags, especially with ebuilds that have a lot of flags (like php). (In reply to comment #34) > - The USE flags should be correctly capitalized ("Debug", "DirectFB", "GIF", > "Joystick", "TrueType", etc.), as it grealty enhance readability... however, > most people don't even think about it, and use strange capitalization patterns, > including names only in lowercase Jesus, noooooo - just not that. The capitalized ebuild names (think perl ebuilds or PEAR packages e.g.) suck big time, dunno why should I bother with capitals when trying to emerge something or specify use flags.
> (In reply to comment #34) > > - The USE flags should be correctly capitalized ("Debug", "DirectFB", "GIF", > > "Joystick", "TrueType", etc.), as it grealty enhance readability... however, > > most people don't even think about it, and use strange capitalization > > patterns, including names only in lowercase > > Jesus, noooooo - just not that. The capitalized ebuild names (think perl > ebuilds or PEAR packages e.g.) suck big time, dunno why should I bother with > capitals when trying to emerge something or specify use flags. > Yeah, that's why I said case-sensitive filenames (and names in general) is a problem :) (well, if software and functionalities were named in a more simple/neutral way, I'm pretty sure it wouldn't be that much of a problem -ok, you'll probably have to change the whole human society... but still, when we use the console all day, it's better if these name are not case-sensitive). Reading would be easier and quicker, but as for the other interactions with these names, and as far as today computer world and today human society pertists, it would be hell... (and indeed already is with PEAR, some executables which use mixed case, etc.) (In reply to comment #36) > * "People are creatures of habit" and "you can't teach > an old dog new tricks". I can't really see beyond those > two as the current ordering is not really hard > to learn. > It might not be really hard to learn for *you*. Usability is about what is easier for most. Excepting illiterates, alphabetical order is known, and more or less mastered, by all (well, people who use the latin alphabet or a similar alphabet, ok, but they won't be able to read, if they don't, anyway). I didn't say they couldn't learn other ways, I said it would be easier for most, to keep the well known strict alphabetical order. Being easier, it is the only way to go, if we care about usability in Gentoo Linux. The alphabetic order (with added symbols and possible coloring) is not bad (I don't say it is in any way perfect, as it is far from it). We don't need to find other ways. If some people want to try other ways, as an experiment, they create options. If the option becomes used by most, then we can think about making it the default behaviour, keeping the old way as an option, for people who don't care about other ways. When the option is used by nearly all users, we can think about removing the old way, if it really gets in the way. You should not assume your new way is better and must be the only way to go, when you only got reports from some devs and maybe some users, who didn't use the new way more than a few weeks at most. Moreover when there are people telling you the old way was better. I assume the old way was better because alphabetical order is a basis. Most users, if not all, just do master it. Creating two lists breaks this. Ok this is still readable, ok some people might find this easier, ok we might want to try to make it an experimental option and see how other people react to it. (In reply to comment #36) > * People are generally unsure of themselves. By that > I'm referring to the argument of needing to check two lists > to see if a flag is available. This argument I can accept and > is the only real argument against enabled/disabled > ordering that I can see. > > Did I miss anything there? We really need to be stating > more than "alphabetic rules all" and the "the old way is > better" to get anywhere here. What is needed is specific > cases of "I wanted to do/check this and the enabled/disabled > order makes it more difficult because..." > Well, I'm pretty sure I said more. For example, I said that we need a sure reference (of order, of place, etc.). Strict alphabetical order gives a sure reference, be it the order or the place. Changing the USE flags order and place when their activated/deactivated status changes is just plain wrong. I also said, and you agreed, if I correctly remember, that the border between the two lists might not be clear, when there are new/changed USE flags at/near this border... (when using coloring, we can't rely on the activated/deactivated colors, to separate the list) There is no such problem with alphabetical order. Separating activated from deactivated USE flags means we associate a color (red or blue) with the list, far more than when using a strict and fixed alphabetical order. Meaning that when the colors are changed (when there is a new or changed USE flag), confusion arise, moreover when at/near the border. But ok, new/changed USE flags status only is temporary (well, confusion should be avoided, even if it's only temporary, if we care about usability). If you can't see quickly if a USE flag is activated or not, using the "old way", on a black/dark background with coloring, just make the '-' sign, before deactivated USE flags, white (well, the standard foreground color -better for people using a white/light background); it would enhance readability... (just put the '%' and '*' symbols in parenthesis, or something like that -sorry for your screen space, Ciaran ;)) (In reply to comment #36) > Adding USE="" was done for consistency. Removing the plus > signs before enabled flags was done for consistency. Both of > these are there so that the output directly correlates to what > a user would find (or should put into) make.conf. > Well, of course, if we have a plus sign, it should be made possible to use a plus sign in our configuration files... (and as said, it seems to work, except there is a warning about it, when using emerge...). Again, is there a particular reason for the lack of plus sign, which presence would enhance redability, which is, as I understand, why you tried to separate the activated from the deactivated USE flags? Shall I open a new bug report for the '+' sign matter? (well, there already is a very old bug report, here: https://bugs.gentoo.org/show_bug.cgi?id=10013 but no discussions... I guess it's better to open a new one, if needed...) I guess that's what I'll do sometime today or tomorrow...
Stumbling about this bug, I have to concur with Mathieu and Ciaran regarding non-alphabetic use flag order and also with Jakub regarding mixed case use flags and ebuilds - both not helpful, but annoying.
(In reply to comment #43) > Shall I open a new bug report for the '+' sign matter? (well, there already is > a very old bug report, here: https://bugs.gentoo.org/show_bug.cgi?id=10013 but > no discussions... I guess it's better to open a new one, if needed...) I guess > that's what I'll do sometime today or tomorrow... > Here is the new bug report about adding a plus (+) symbol before activated USE flags: https://bugs.gentoo.org/show_bug.cgi?id=119484 For issues other than the new separation of activated from deactivated USE flags by `emerge`, we should indeed open new bug reports, so the discussions stay focused. A bug report already exists about `emerge` output coloring being partly unreadable depending on the background color, here: https://bugs.gentoo.org/show_bug.cgi?id=63517
Ok... Flags are now displayed whether --verbose is specified or not. The difference is that --verbose shows all flags whereas lack of --verbose only shows new or changed flags. I'd think it'd be fair to say that if --verbose is specified then the goal is to view all available flags, in which case purely alphabetical output would be better. When displaying new and changed flags the logical goal is to ascertain the status of those flags. Hence, how about leaving lack of --verbose as it is now and restoring alphabetical ordering when --verbose is specified?
(In reply to comment #46) > Flags are now displayed whether --verbose is specified or not. The difference > is that --verbose shows all flags whereas lack of --verbose only shows new or > changed flags. > ... which is pretty good (permitting not to use --verbose, but still not missing new/changed USE flags -well, I prefer always using --verbose, to always check if old USE flags might be changed, but the behaviour you describe really is practical). > > I'd think it'd be fair to say that if --verbose is specified > then the goal is to view all available flags, in which case purely > alphabetical output would be better. When displaying new and changed flags the > logical goal is to ascertain the status of those flags. > > Hence, how about leaving lack of --verbose as it is now and restoring > alphabetical ordering when --verbose is specified? > Well, as long as the new/changed USE flag list is short (no line -80/110 chars- break), there is not much problem with separating activated from deactivated USE flags, as alphabetical order isn't quite needed, since we can pretty much see and apprehend the whole list without having to move the eyes (no risk to lose yourself because of the lack of sure reference). However, I still think it is better to just stay with a single simple behaviour: the strict, fixed, alphabetical order. Other kinds of sortings should be made as non-default options, at least until most people use this option (and even then, the strict alphabetical order must be kept has an option). What is the problem with making the separation between activated and deactivated a non-default option? We would be able to talk about it in more details (as for other possible USE flags sortings), if we weren't pressured by the fact this new behaviour already has been implemented as the default behaviour :/ Anyway, I always use the "--verbose" option, so would you decide to do as you just told us, it would not inconvenience me much in daily life, as for probably most people... but I really think the way to go is to make the separation between activated and deactivated USE flags a non-default option... people who feel it's better and want to test will use it, and all the others will just use the classic behaviour. If you want to make people interested in this new sorting, you might put an einfo in the ebuild, telling about the option... (but as said, even if after some time, the new sorting is set to be used as default, the strict alphabetical order must be kept as an option).
I think reordering the flags based on enabled/disabled status just makes it harder to see what's going on, the USE="..." seems redundant and wastes screen real estate, but marking new use flags with yellow and % is awesome and I love it. I can't stand white backgrounds, they make my eyes hurt, but I do think it would be nice to be able to customise the colours used. also, can we make colours/no colours a command line option to emerge and its kin? i'd love to be able to convert term colours to html for my -pvtDNul cron jobs, but only if i specify that I want them. checking if stderr (rather than stdout) is a terminal would mean we could still have the colours if piping to less, but not when called from a cron job ps: the updating package metadata thing that appears if you sync on one machine then run emerge on another still has term colours when stdout isn't a terminal
Wouldn't it be possible to make the output format for emerge customizable? Something like LS_COLORS for 'ls --color', where both the syntax and the colors can be changed in some /etc/emerge.conf or EMERGE_COLORS variable.. It would solve all problems, and would allow both groups to live happy. In addition, a --no-format parameter for emerge could produce "non-colorized, standarized" output for showing in bugzilla, etc.
Well, I think that would make things too complex. I prefer keeping sane defaults. BTW, I don't see the "we want the enabled/disabled sort"-group anywhere so this bug is solely about bringing back the original behaviour...
(In reply to comment #50) > BTW, I don't see the "we want the enabled/disabled sort"-group anywhere so > this bug is solely about bringing back the original behaviour... When was the last time you searched for a bug on a change that you approved of simply to post a comment relating your approval?
http://forums.gentoo.org/viewtopic-t-426033.html So let's just keep quiet on this bug until some unbiased opinions come in.
I just tried to say that this "let's change it then let people vote" opinion is bad. The "normal" way of doing usability changes is letting them in but not enabling them by default. When there's a lot of people wanting it to become a new default, do it then. Never the other way. Sorry, for adding another post, I promise this is my last one before the poll ends (which is when?).
Released in 2.1_pre4
Another issue I have with the colors and such is that colors are constant regardless of the flag being added or removed. New flags (or whatever they are) are always yellow, and changed flags are always green. It makes it hard to identify how these flags were actually changed.
