Re: Context menus
Jason Gunthorpe wrote:
>
> I see no reason why the slang versions can't have a context menu as well.
> It's actually more work to remove it :P
Really? Well then, I've underestimated the potential of the slang
version of deity! I will adjust my expectations accordingly!
> > btw, just to remind you, in this new interface, there is no distinction
> > between remove and purge (I've always found that distinction
> > confusing). They are both the same in deity. All that happens is that
> > on a remove/purge, the confiles are stored in /var/backup/dpkg/<package>
> > and if the package is ever reinstalled, the old conf files can be
> > recovered from there.
>
> Okay, I didn't know that ;>
I have only mentioned it here on this list. I really should put it my
document.
> > Again, the concept of "hold" is unessesary. By not upgrading to the
> > next version of a package there is an implicit hold placed on the
> > package by the user.
>
> Hm, I was thinking 'hold' has a single use -- to prevent a pacakge from
> being automatically installed.
That is what "keep" means. The state in which the user leaves the UI is
the state it should come up again in the next invocation of deity. This
includes if a particular package was not upgraded (or in other words the
old version was kept). If you liken this to dselect, if the last thing
a user did was not upgrade a package, then there is an implicit hold.
The new version will be offered to the user on successive invocations of
deity, but the left hand buttons will remain on "keep" until the user
clicks "inst" again. At this point deity will automatically assume that
the user will want to upgrade to progessive versions again. Does that
make sense?
> > There should be a "choose version" entry in the menus somewhere, but not
> > a bo/hamm entry. We can put this kind of thing in a context sensitive
> > pop-up menu, but not in the main menu!
>
> Well my thought would be that ppl would not really care what the specific
> version is. Perhaps that's wrong, perhaps both are needed.
I certainly care what version! I care less what distribution it comes
from as long as I can install it. Perhaps the "Choose version" should
prominently state where each version comes from.
> The trouble is
> if the user specifies a specific version it vastly complicates things
> because forevermore that package is attached to that version - period.
Explain please?
> Now that might be changable, but it would require some detailed thought.
> What we need is a spec of exactly how deity decides what package to offer
> for installation (= the package it's going to install)
It should stay within the same distribution if possible. I agree this
isn't defined well currently. I'll think about it more. Any ideas from
the rest of you?
> > It does, actually. They have merely been condensed and called "delete",
> > "keep" and "install". (Check the left hand column of the select screen.
>
> The UI prototype has had my interpritation of your web page for a while
> now, so we should check that it is okay..
I haven't managed to check it out yet, because I haven't been able to
compile it yet!
> > Drat! We've been having computer problems here recently (all 9 of our
> > new computers are spontaneously rebooting, and all my work is suffering
>
> Ewwwwwwww, I hate those sorts of problems :< Too many likely causes,
> overheating or bad power supplies have both caused them for me..
In our case we're pretty sure it's the PCI chipset. It's crashing both
Linux and NT machines (both no mean feats), and it is only really
affected by activity of PCI devices (SCSI and video cards). We're
trying to get the manufacturer to replace the motherboards, but we're
having problems. 8(
> Your guess is prolly fairly good. TargetVersion and Target dist directly
> control the package that will be offered for installation. If
> TargetVersion is 1.0 then only version 1.0 will be offered for
> installation no matter what other versions are avaible if TargetDist is
> 'unstable' then the newest version from 'unstable' will be offerened for
> installation irregardless of what bo/etc is set to. I think this might
> even include a downgrade..
Oh I see! Ok, I'll have to go over the design and see how this fits.
I'll get back to you on that.
> The implementation of the above is supposted to support your UI ideas, I
> hope it does!
Me too! 8)
> I've somehow managed to con Scott Ellis into building daily .debs of Deity
> for at least the next short while. I don't always get changes in ever day
> however. He says the next snapshot should be done compiling in about
> 10mins (as I write this)
Yes! Ok, that makes it easier for me! I'll check it out for sure!
Looking forward to it.
Thanks!
Behan
--
Behan Webster mailto:behanw@verisim.com
+1-613-224-7547 http://www.verisim.com/
Reply to: