Re: on value edit fields (i.e. the too small buttons inside)

Hi Steven!

Steven D'Aprano schrieb:
> 
> On Tue,  3 Sep 2002 07:12, Friedrich W. H. Kossebau wrote:

[snip]

> But I agree with you that the size of the buttons are horribly small.
> There seems to be a distressing habit among developers to make
> everything microscopically small; I guess its because all you young
> whipper-snappers still have perfect eyesight and expensive optical mice
> that never get dirty :-)

Or are trained by playing games using the mouse? Or having a more
reactive ui (thanks to cpu power or the latest kernel patches? ;)
 
> > Am I the only one to think this to be foolish? I see three problems:
> >
> > 1. tiny up/down buttons, hard to hit with the cursor
> 
> Agreed, with spades. Its not so much its hard to hit them, but its hard
> to hit the right one.

Nit picker you are ;)
 
> > 2. up/down looks like selection of predefined values
> 
> No, I don't see this at all.

Well, but it does look quite similar, doesn't it? At least I think there
could be a slightly more differing to a editable combobox. And there
might be culturs or even usages where it is not clear what the up and
down buttons result in. Plus and minus are more precise, aren't they
(compared to up and down)?
 
> > 3. no idea which values are achieved by which slider position, not
> > even min/max
> 
> Sliders should *always* display values, at least start and end values.
> That's just common sense, and I'm amazed that anyone would forget that.

Maybe it is the lack of bad marks on former dialogs ;) So they never
learned.
 
> > Problem 1 should be solved by enlarging the icons. As they then won't
> > fit anymore one above the other they have to be put somewhere else.
> > Attached you can see two possibilities of which I like the first one
> > better as one cannot accidentally click the wrong button.
> 
> Ah, but there is one other way of enlarging the icons. See my sample
> attached.

Imagine this with a dialog where there are many value edits... and even
in your proposal the edit field looks quite strange... the value appears
to be lost alone ;) I think one has to accept the height of the usual
edit field as the maximum heighth.
 
> > Problem 2 should be solved by using -/+ symbols for de-/incremental
> > steps.
> 
> I don't think Problem 2 is a problem, but if it was, I suppose this is
> a good solution.
> 
> > Problem 3 should be solved by printing the min/max values to the
> > corresponding ends.
> 
> I agree.

What about an additional tool tip or the like that shows the
corresponding value when hovering over the slider bar with the mouse? So
those who like to choose a slider position by middle mouse button (yes,
includes me) could think about until the final click whether they want
to change the value at all.

But well, the poor reaction on my initial email shows me there might be
only a few who are not satisfied with the actual situation. I guess I
should spend my energy to achieve a position for being able to spend
actual code...

So long... 

Friedrich