Re: The Deity tree widget
Jason Gunthorpe wrote:
>
> On Mon, 17 Nov 1997, Behan Webster wrote:
>
> > 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 - ?
I'm afraid I don't understand the question. Sorry.
> > 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?
Yes. If we use the +/- then the dep/whatever icons will go to the right
of the +/- just like in the linux Explorer. As you say, what is
currently in my web pages is a bit confusing. It was more of an
experiment. A failed experiment IMHO.
> > 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.
I think I agree. I just hope there's room! 8)
> > > > - 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..
Since I've received that email now, I've responded to it separately.
Identifying new packages shouldn't be a problem. Should it? If you have
to add a file to your cache (because it wasn't there on the previous
running of deity) surely you can assume it's a new package. Or am I
missing something?
> > 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'.
True. However, if there is no version to upgrade to, why is there a
problem?
Like I said, there is no explicit hold. Only an implicit hold. The
next time there is a version to upgrade to the user can choose to
upgrade or not. If they choose not to upgrade, the package is
implicitly held at that version until the user selects "inst" again.
> 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)
But that doesn't matter. If it is "kept" or not, if there is no version
to upgrade to, the only option you have is to delete it. Again, you are
thinking of an explicit hold. A concept which doesn't exist in my
design.
> 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'
I don't see what the problem is. In the case of not having a version to
upgrade to, you just don't draw the "keep" and "inst" controls and only
draw the "del" checkbox. You can't throw away this info, you just don't
display it. Afterall, this data is useless in this particular case.
The next time a newer version is available, you show these buttons again
in the state the user last left them.
> That will cause some strange problems in the code...
Perhaps.
> > 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.
I see. That makes sense.
> > 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!
A good idea to be sure.
Later,
Behan
--
Behan Webster mailto:behanw@verisim.com
+1-613-224-7547 http://www.verisim.com/
Reply to: