[Aptitude-devel] Bug#458420: aptitude: show description when Depends->pkg is still folded in pkg info view

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hello Jerry,

2007-12-31 06:34 Jerry Quinn:
>Package: aptitude
>Version: 0.4.6.1-1.1
>Severity: wishlist
>
>The subject is perhaps not quite as descriptive as I'd like, but...
>
>If you look at the info for a package, the first tree section is
>Depends.  By default it shows all packages the current one depends
>on.  I often find myself wanting to know what one of the other
>packages actually is.  If I just scroll down, I don't see anything in
>the status bar.  I have to open and then highlight one of the actual
>versions underneath.  For example, sketching out the info view:
>
>i A  --\ libxul0d     	  	   1.8.1.11-1 1.8.1.11-1
> Description: Gecko engine library
>   <details and fields>
>   --\ Depends
>     --- libatk1.0-0 (>= 1.20.0)
>
>If I want to see the short description for libatk in the status line,
>I need to:
>
>1) move the cursor to libatk
>2) hit return to open
>3) move cursor to one of the specific versions underneath
>
>My first observation is that if there's only one version, why not show
>the description without opening?  It saves 2 steps.  If there are
>multiple versions, things are more complicated, but if they all have
>the same short description, again aptitude could show this.
>
>Please? :-)


I was looking into this, but I don't like very much the idea at the
moment.  I can be persuaded, thus marking this as 'moreinfo' in the case
that you or somebody else wants to chime in.


You can somehow shortcut your chase in the example above by opening the
whole tree at the same time with '['.  It won't save you anything if you
just want to view one dependency, but if what annoys you is the number
of steps, it will save you all the #1 and #2 if you want to view more
than one dependency, you just need to move the cursor then.


One of the problems to implement what you say is that versions can be
optional, so they are marked "--- pkg_a | pkg_b", in which case there is
already more than one version (so it doesn't work in your case).

Another special case is that the version can be a virtual package, in
which case there is no clear candidate.  (Although one can maybe use the
candidate version in this case).

In general it would be workable, but what I don't like is that to make
this kind of changes requires to change the logic and to create the view
to add lots of special cases, which is not very nice and complicates
refactorings and things in the long term; most probably interferes with
and complicates features like e.g. the "l/limit" on package views; and
perhaps prevents to share this code with other parts of the program.

Also, why set the limit on the case of only one and not two or three, or
N configurable by the user?  Or why not "expand as long as it fits in my
screen"?  Etc.


So in short, I don't think that this added feature would be worthy to
complicate the current design, there are enough difficult problems in
aptitude as it is :-/


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