It's passable, but I have a suggestion (piggybacking off Waldemar's)
that I think might be better for organization, but I'll leave the final
verdict to the rest of you. :-) I'll give my best attempt at ASCII art
and explain.
...
You could place the destination beside the type to provide a little
visual balance. Placing them closer together also helps associate them
logically. The size for each install type could be included in the
label so that the user could see ahead of time how big the particular
install type is before he selects an item. It also should be less work,
which is also nice. :) Anyway, something to think about. TTFN
This ASCII art is a bit crooked here, so it's hard for me to exactly see
the details of this layout :). Anyway, here's what I think:
I've placed the install destination separate from the install type since
in most cases it's not quite dependent on the chosen profile. And having
too much menu fields in one place can 'scare' away users by making the
application look more complex IMO.
Having the size of each install in the selection is a great idea. I
don't think there would be problems with this issue too. The BMenuField
adjusts its size to the width of the selected label by default, if not
stated otherwise. In this case, will we still need the "Size:" label
positioned somewhere else?
As for the scroller in the description field - wouldn't it be better to
include it only if needed? I mean, the field size would depend on the
description size (auto resize), but when it reaches some value, we make
it scrollable. I think this would look a bit better. Or maybe that's
what you had in mind yourself?
