Re: The Deity tree widget
On Mon, 17 Nov 1997, Behan Webster wrote:
You know, the lists are down :<
> > 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
>
> Well, I don't know exactly how, but something along the lines of what's
> below (I knon I've seen this done well before, but I can't remember
> where 8( ). Unfortunatly in the text version there won't be much space,
> so it can be simplified tremendously.
>
> + foobar
> + blah
> - baz
Oh good, that is what it looks like :> How about the 3 columns to the
left? Right now I used simply
--* + foobar 1.3 ^ 1.4 cpp,binutils
How do you wish to handle the various cases in text? Omit the - ?
> > > 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.
>
> I kinda show how this is setup in my web page. It should be in the
> column in which the package names are.
Yeah, that is how they are aligned right no, just no lines yet.
> If I understand you correctly, you are talking about horizontal lines
> that separate rows? I don't think they are needed. I have yet to see a
If you look I drew the sections without any horizontal lines and a single
vertical underline which had the effect of visually setting them apart.
Since we are losing the vertical lines the horizontal will go too.
Will there be an icon (ala explorer) beside section and package lines to
indicate things? (Section type, package, depends type, etc)
Actually, could we move the 'Dep' indication into an icon to the right of
the +/-. Here is a case that confuses me, you have 'Dep' drawn to the left
of the +/-, but that is where the vertical tree lines must go, unless you
only want some, not all of the lines?
> Personally, I'd prefer no extraneous lines. The vertical ones
> especially detract from the fact that the data on each row is associated
> with each other. There should be a flow from left to right in the data
> and a vertical line detracts from this flow.
> I think once the icons are in, they will separate some columns better
> than a vertical line.
Ah yes, I didn't leave space for the icons, that will certainly fix it!
> Not so unusal. The mac has used the triangles for years. I find the
> +/- icons, although more common, much more confusing. It is always
> instantly obvious whether a list is open or closed from just the
> triangle icon. I find that this instant recognition is not there with
> the +/- icons.
>
> The only advantage of +/- icons is that they can also be easily used in
> the slang version of the list. We could do it the way Linux Explorer
> does it with +/- and then a little icon though. Perhaps that would be
> best. People are already used to +/- I suppose from windows.
Well, we can try both ways, I think a nicely drawn, sculpted triangle
could be highly attractive, but I can't draw anything like that! I
personally would like to see a nice icon (ala Explorer) beside each item,
for some reason that makes things seem more professional, donno why.
> > > - 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 :|
> Pardon?
The lists are down so you never saw it :< How to handle getting
new/obsolete is a bit complex I think..
> > > - 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'.
>
> You didn't quote the line above, but the example you're thinking of is
> an upgrade. That case was handled by a previous item. (Item 1 of the
> five I listed I believe). What I was trying to get across is that if a
> package is installed, and there is no version to upgrade or downgrade,
> and if it is not new or obsolete, then the Inst-version field is just
> empty.
Oh, yeah, I already knew (and followed) that from someplace :>
> > > 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?
>
> Yes. I want it very obvious which columns will actually do something.
> All three controls are not necessarily available on each line (please
> see my design again).
Yes, I see the way you want it to work, can do.
> > > - 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.
>
> You will find that this is contrary to the design I specified in my
> design page.
Hm, so it is.
> We're working with a user's mental model here. You have to think as
> they would think.
>
> How can you delete or keep a package that isn't installed? Hence there
> is a check box for inst only.
>
> You can keep a obsolete package, however, keep is more akin to the
> deselect hold, therefore I've changed it so that you can only delete an
> obsolete package.
Okay, I think I see. There is going to be more questions on this though..
> > > - For a package which is already installed there is one checkbox (del)
> >
> > How are you going to indicate the more permanent 'held' state?
>
> There is no "held" state. There is an implied held. By pressing "keep"
> you are asking deity to not auto-upgrade until you press inst again
> (presumably sometime in the future). Effectively, as a user, if one
> time I decided not to upgrade samba (for whatever reason) I would not
> like it to default to inst the next time it runs either. I would like
> it to stay in the keep state until I say othrwise. It all has to do
> with deity keeping the controls in the same state as the user left them
> the last time.
Hm, but how can the user do this if there is no version to upgrade? I
think you said that in the case of an installed package, with no
upgradeable version there would be a checkbox on remove, which means there
is no option to 'keep'.
This causes me some problems because the package can be in a state that
cannot be represented (it once was kept, but something changed and now it
is still kept, but there is no upgrade version so it cannot be shown that
it is kept.. which poses the question of wheather it is actually kept any
more or not kept, either way makes things complicated)
Think about this,
'Deity will keep the controls in the same state as the user left them'
but
'The controls change depending on the state of the package'
hence
'The controls cannot always be in the same state as the user left them if
that state is no longer possible'
That will cause some strange problems in the code...
> I'd prefer circles (I personally don't like the diamonds; they're not so
> obviously radio buttons), but diamonds will do for now.
Cicles will need bitmaps to do properly so they will have to be a later
addition is all.
> > Ah, we need an artist too.
>
> Yes. I think this shouldn't be too hard to find if we ask in
> debian-devel.
I asked Brian and Ben (Che) to poke around, hopefully we will find a
really awesome artist!
Jason
Reply to: