On 19 Aug 2002, Guillaume Cottenceau wrote:
> > [4] if the checkbox could be at the left of the name instead of the > > right, you'd see it even if the widest package name was wider than > > the sub-window listing packages. > > There are hardcoded sizes so that the box must never disappear. For heaven's sake, I hope they are not coded in pixel units, but in a character height/width unit. There are some nice pieces of software that really look pityful (windows too small and non-resizable, clobbered text in boxes and buttons, etc) just because they are coded in pixel unit and you happen to have a hi-res screen (say, 1400x1050 on 15", like Dell laptops) so choose bigger fonts in Gnome (KDE does it automatically depending on the dpi returned by X). Please do think about it. > > If you don't do this, *please* make it clearer which box goes with > > which item - they are too far apart for me to be certain I'm > > clicking on the right thing without selecting one. Also note that if > > I make a selection, the blue is dark enough that I can't see the > > checkbox any more, and yet I also can't easily read the white text. > > A pastel blue or yellow would probably be better. > > Hum, are you colourblind or something? Even if he isn't, some others might be. I prefer the checkbox on the left, you're sure it's close to the item even if it's short. > > The URL should be copy/pastable text! > > This seems minor to me :-). IMHO, all text in all windows of a windowing system should be copy/pastable. This would mean, incidentally, that it's not up to the applications to take care of it. Ever been frustrated, not to be able to copy/paste an error message in a dialog box to mail it to a maintainer ? > > It looks like it installed the packages and then just went away?!?!?!?!? > > did it install all of them? how do I tell? What if it uninstalled some > > packages in order to satisfy dependencies? What if it installed extra > > packages? > > Like previous "grpmi" version, when there is no problem there is > nothing reported. I think that a report should always be generated. Something like: "The packages xxx, xxx, xxx were installed. For their proper operation, is was needed to install: yyy yyy and to upgrade or remove: zzz zzz [Ok]" Even if most of the time it shrinks down to: "The package foo was installed. No additional package was needed for proper operation. No previously installed package conflicted. [Ok]" I liked the summary in the previous versions of rpmdrake, though having to click on "cancel" to confirm was a bad UI choice. The report "educates" the newbie by telling him that this program actually does a goob job behind the scene. When you ask for a beer at a bar, you do expect the barman to give you and say "here you are, sir" or something, not disappearing while you find the beer in front of you. I know that precisely, traditional Unix programs follow the "no problem, no report", which is very good because those can be scripted, etc... but since rpmdrake is a end-newbie-user-interface, it's good to produce a report. It's clearer for the user, which becomes more confident in the tool. > With current rpmdrake version, after installation you're back to > the main rpmdrake window so it might be less awkwark. "Will you take anything, beside your beer ?" We do agree ;-) -- St�phane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr/ - philo du dimanche http://amphi-gouri.org/
