Hey...
On Sun, 2016-07-24 at 15:41 +0100, Manuel A. Fernandez Montecelo wrote: > Given that it's an improvement over the previous functionality (all > or > nothing), in any case, it's more flexible than before... but I > disagree > that it's more unflexible than your proposal (read on). Hmm I tried it now for a few days, and while in principle it allows for more things to do, my original view hasn't changed and I'd still consider unfortunate for practical use. :-( The major use case I'd have seen in the selective forgetting is that one can keep those packages one wants to have a look at later on. This use case typically means that only a small subset of the new packages is wanted to be kept (otherwise one could just keep all). This in turn however makes the matching based solution rather impractical for day to day use: - new packages turn up in many sections, and often not all of those in one section are interesting enough to be kept thus filtering out based on the section doesn't really seem to work in many cases, and even if it would one would still have to type in all those sections one wants to discard (which can be quite some) - filtering out single packages is unhandy either As I've said before, it's typically the minority one wants to select but the filtering works vice-versa (i.e. selecting all those one wants to discard). Even without fast growing sections like dbg[sym] this end up being unusable. Inverting the filter wouldn't help IMO either, one would still need to write up all those packages that are to be kept, and since one needs to navigate through the package view and often all interesting packages wouldn't fit on one screen, I'd alrady need another editor or so, where I write up the interesting things. > Had the "F" shortcut not been taken for a completely different > purpose, Doesn't F anyway make just sense on already installed packages? While there can be packages in the New section which are installed (but just not forgotten yet),... I'm sure no one would bother if F would get another meaning when one is in the New tree. > I would have let "f" behave as before or perhaps implement your > suggestions (context-based, forgetting depending on where you > are). But > I didn't want to add a completely different shortcut, or have the new > feature only accessible through a menu, that perhaps people would not > discover for a long while. hmm.. > One of the problems that I found with your suggestions is that if > people > don't know about the feature and press "f" expecting that everything > is > forgotten as before, and only one package or a small section is > forgotten, they might think that forgetting-new is not working at > all, > or not working properly, or at least it will be puzzling for a while > until they learn that it's a "new feature" and how to use it. Well but that's a general problem with evolution of software... you add new features, and when people don't read the changelogs, they won't know about it. With that argument one could more or less never change anything. I'd have expected that some NEWS.Debian entry about any new behaviour would fix any such conernts.. > In the new implementation, the pop-up might be surprising the first > time, but it's pretty obvious what it needs to happen: just press > "enter" for the old behaviour, or use package names for patterns, as > suggested in the dialog. I think that it introduces nicely the new > feature to the users, while only being minimally disruptive for the > ones > used to the old behaviour. But it still "breaks" user "experience". I for example end up basically every 2nd time, pressing f then g (because usually I do the upgrades afterwards), but now the "g" goes into the popup. > Added bonus is that at least it needs an extra key stroke to have the > old behaviour clear all new ("f + Enter"), so it's likely to trigger > by > mistake than before (which happens from time to time, and a case for > which your suggestions in that bug report don't improve when people > press the key by mistake). Maybe one could have also "completely" changed f's behaviour, i.e. not immediately forget the package (and refresh the view), but just mark it dark grey or so (i.e. scheduled to be forgotton)... and when people exit aptitude, and/or perhaps on "g", and/or on some "save forgotten status function"... it would have been actually saved. This would make the "need" for an extra key stroke go away and allow people to undo their "f" without Ctrl-C aptitude. btw: I don't think that f+Enter really solves the issue you try to address above. As soon as people will get used to the popup, the f+Enter will go into flesh and blood for most, and the extra key stroke won't work as a guard anymore. > Also, it's easier to clear away all packages in ways that do not > conform > to the current visible hiearchy, e.g.: > > - forgetting-new all packages from a source package > > - or a pattern based on source package names (e.g. ~n*texlive*) Both nice to have,.. but again, I don't think of much use in practise: For the source packages: There are often cases where I'd find one binary package of a source package interesting... but not all the -dbg, -common, lib*, -doc etc. simply because when I look at the main package, this would anyway recommend/depend/suggest everything else. And the regexp thingy... well this always means that one has to come up with such regexp first. On Sun, 2016-07-24 at 15:54 +0100, Manuel A. Fernandez Montecelo wrote: > I forgot a couple of points... > > Or alternatively, if the screen is updated in every time that a > package > is forgotten, then the view would be reloaded and the whole tree > would > be collapsed (as it happens in other situations where the package > states > change). That could perhaps be solved with the "just mark it grey" idea I had above? Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature