Re: The Deity tree widget
On Mon, 17 Nov 1997, Behan Webster wrote:
> Ok! I've now _finally_ seen the current tree widget!
Ah, we are making progress!
> I hate to say it, but unfortunately it bears very little resemblance to
> what I was hoping for. There are 4 areas in which I would like to see
> changes:
>
> 1) Collapsible listes lines
> 2) Collapsible list controls
> 3) action bitmaps
> 4) radio buttons and checkboxes
I'm just going to make a broad statement that 'there are no bitmaps yet'
so that should defer a number of your questions for a bit ;>
The text version looks pretty much the same as the X11 version, so if for
now you could explain what ASCII chars I should use in all these places
that would help too. I can't use any special ascii characters though
> 1) What I was hoping for was a collapsible tree widget (not unlike what
> linux eplorer uses, but using the little triangle controls from the
> MacOS). The little lines between the open/close bitmaps show the
> relationships bewteen different lines very clearly. For an example of
> these lines checkout:
>
> http://jungfrau.ptf.hro.nl/explorer/
Okay, what column do you want these in? How should the section items look?
My experiments suggest that without the horizontal line they tend to get
lost in the display.
Should section headings include the vertical bars? Should there even -be-
vertical bars? Linux Explored doesn't use vert bars in it's columns, but
it's columns are more regular. Here I have seen all fields clipped at once
so without a bar they tend to run together..
> 2) If you look in the currently available UI spec you will notice that
> the bitmap infront of each item in the tree is also potentially
> different. There is a different triangle to represent whether the list
> will expand a group heading into a list of packages, or whether you are
> expanding a list of dependencies. (one triangle is currently grey, and
> the other has a red dot in it. These precise bitmaps need not be used
> in the final product, but it is importants to make the distinction in
> what part of the list you are about to expand.
Hm, this is a bit unusual, but okay. Have you considered a 'normal' +/-
tree but using special icons for the various sections? That could work out
well, we could get a number of stock icons for all the sections..
> 3) There is a little bitmap infront of the "inst-version" number that at
> a glance tells the user whether it is an upgrade, downgrade, new
> package, obsolete, or no package is being offered for installation.
Again bitmaps are missing, I draw a ^/V to indicate the sense of the
field.
> - For a new package there should be a little new graphic
> - For an obsolete package there should be a little "x" (or something
> like that)
This is going to get it's own email :|
> - For a package which is already installed there should be nothing in
> this column (not even a version number)
Erm? Is that right? Right now an installed package will show nothing in
the inst-version field iff there is no new version. If there is a newer
version it will be shown and the checks will be set to 'I'.
> 4) The left three columns should consist of radio buttons and checkboxes
> (depending on what the row represents. It is important that these
> controls are very obviously either a radio button group or a single
> checkbox. This is because not all options are available in each
> situation. Having a single kind of check control is not satisfactory
> for this design.
Okay, how do you want this too look? Do you actually want 3 radiobox like
items?
> - For an upgrade there are 3 radio buttons (del, keep, inst)
> - For a downgrade there are 3 radio buttons (del, keep, inst)
> - For a new package there is one checkbox (inst)
> - For an obsolete package there is one checkbox (del)
Right now for a new/obsolete package I put a check
in 'Keep' to indicate that there will be no upgrade.
> - For a package which is already installed there is one checkbox (del)
How are you going to indicate the more permanent 'held' state?
> My preference is for radio buttons to be round and checkboxes to be
> square, as this is the way they look for most widget sets and people
> understand these shapes and what they do already.
Sure, but do you -really- want radio buttons for this case? It might make
things look too busy? I can try it, lose some of the lines and chuck in a
few circles.. Do you mind Diamond shaped radio buttons? They are slightly
simpler to draw at this stage.
> I hope I haven't been too harsh in either my tone or wording of the
> above...
Oh, I don't think so..
Ah, we need an artist too.
Jason
Reply to: