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.montez...@gmail.com>