[Aptitude-devel] Bug#233625: upgrade confirmartion screen display nits

[Manuel A. Fernandez Montecelo]

Control: tags -1 + wontfix
Control: close -1


2004-02-19 03:39 Daniel Burrows:
>On Wed, Feb 18, 2004 at 09:45:26PM -0500, Joey Hess <joeyh at debian.org> was heard to say:
>> This is a bit ugly:
>>
>> xlibs-static-pic will be automatically installed to satisfy the following
>> dependencies:
>> This will use 979kB of disk space.
>
>  The disk-space indicator was a last-minute brainwave and I tried to
>integrate it in a way that didn't result in death by angry mobs of
>translators ;-).  (the other options I was considering at the time
>needed lots of string changes)
>
>  It definitely needs to go somewhere better.  I'd like it to be
>somewhere reliable, where you never have to scroll to see it, and I'm
>actually thinking about the main list view right now.

This change has taken place (for a decade or so at least).


>> The use of color helps occasionally, such as here:
>>
>>   * xlibmesa3-gl conflicts with libgl1 (provided by xlibmesa-gl
>>     4.3.0-0pre1v1, xlibmesa-gl 4.3.0-0pre1v3, xlibmesa-gl 4.3.0-0pre1v4,
>>     xlibmesa-gl 4.3.0-0pre1v5, xlibmesa-gl 4.3.0-2)
>>
>> Since the last package in the list was highlighted in green, I was
>> able to guess that it was being upgraded and this is why xlibmesa3-gl
>> got marked for removal. But couldn't the same thing be done by
>> simplifying it?
>>
>>   * xlibmesa3-gl conflicts with libgl1 (provided by xlibmesa-gl 4.3.0-2)
>>
>> After all, I don't have the many other packages installed at all.
>
>  The intent is to show you alternatives you could install -- but
>obviously that's useless for a Conflicts!  In this case the display
>should definitely be trimmed to only packages that are causing a
>conflicting state.

I am not sure if it's useless, but at least the current code has the
virtue of having some systematic display of dependencies, which I think
that it's good instead of duplicating code and handling this case
specially.


>> Unfortunatly, the first thing I thought of when I began to scroll down
>> the list and many colorised package names began to flash up in the lower
>> panel was display corruption caused by writing garbage to video memory,
>> or a terminal and the resulting angry fruit salad effect. I can't get
>> that analogy out of my head and I think I'd like a way to turn off the
>> colorisation of that part of aptitude. :-/
>
>  Hm.  The main reason I colorized the names was to avoid the
>`dselect syndrome':
>
>  * my-mail-user-agent depends on mail-transport-agent, but:
>    + exim which provides mail-transport-agent is going to be removed
>    + sendmail which provides mail-transport-agent is not installed
>    + ... (10-15 more lines here)
>
>  One way to quickly convey information about the state of the relevant
>packages, without a long and overly-verbose list, is to use colors.  Of
>course, there are alternatives: eg, package names could also be annotated
>with symbols, and maybe they should be anyway in order to support non-color
>terminals.

I agree with the use of these colour codes.  In some cases it can cause
the "fruit salad" appearance, but these cases should be few and far between.

If it's displeasing, the information can be switched with the 'i' key to
show other non-colorised information, or similar information in
different non-colorised format, or one can disable the panel entirely
with 'D' until one wants to view information of a particular package
causing troubles.

So, for all the reasons above, marking as +wontfix and closing.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>