Re: Context menus
Manoj Srivastava wrote:
>
> Hi,
> >>"Behan" == Behan Webster <behanw@verisim.com> writes:
>
> Behan> btw, just to remind you, in this new interface, there is no
> Behan> distinction between remove and purge (I've always found that
> Behan> distinction confusing). They are both the same in deity. All
> Behan> that happens is that on a remove/purge, the confiles are stored
> Behan> in /var/backup/dpkg/<package> and if the package is ever
> Behan> reinstalled, the old conf files can be recovered from there.
>
> I think that this may be going beyond Deities domain a
> bit. Deosn't dpkg diffretiate between the two? Since there is a
> difference in the underlying mechanism, I think it is wrong for a
> user interface to remove it in the name of simplicity (I hate
> microsoft).
This has nothing to do with Microsoft. It has to do with UI design.
Designing a UI for an existing process means you will have a terrible
UI. dselect
The idea is to design functionality and then implement the bits
underneath. Although dpkg is what will be the underlying mechanism for
the first version of deity, we should not be limited to just that. This
is an interim release, and no more. Designing a good GUI for a
command-line program is impossible. You will only have a mediocre GUI
at best. Command-line actions and GUI actions do not match up well
becuase they are based on two different user mental models. Again,
dselect should be more than enough proof of this assertion.
I am removing nothing from dpkg for the sake of simplicity. What I am
doing is a technical design of a GUI. Dpkg has added functionality in
it for the dselect GUI. I am suggesting nothing less, than added
functionality to support the deity GUI. In this case, the interface
does not need to differentiate between two alternatives which dselect
had to do before. The only difference is whether conf files are kept
around. I am suggesting they always should be. The only difference
being that they are kept in an out of the way place (/var/backups). In
this way you actually simplify how much the user needs to figure out.
Is that not what a GUI is for?
I'm afraid I resent the reference to what I'm doing is the same as
Microsoft. I hope I am misreading the intent of your comment.
> If you think that this is wrong, then this should be brought
> to the light of day, possibly on debian-devel, or in a mail message
> to the dpkg-maintainers, bruce, and a few others (I prefer
> debian-devel).
I have brought this to light of day. Just not on as open a forum as
debian-devel. I'm afraid I don't find debian-devel condusive to the
design process. There is too much noise, and not enough substance. It
is fine once you have a design to review, but design by commitee does
not yield a very good design. Brain storming on debian-devel the other
hand (which is how we started this design) is/was very useful.
Just explaining the first version of my design was very hard (and
extremely frustrating). I don't know how many times people asked if
deity included some feature, or that it should do something some way,
and all I did was point them to the URL where that was covered. Of
course there were several individuals who rightly pointed out faults and
corrections. (I was glad a few people actually read my design!).
*sigh* Ok, now that I've vented my frustration... 8)
If you think this is necessary, so be it. I thought those involved were
reading this anyways, and now that the list is digested, it's all public
record anyways.
Not to mention, because of the way the first version is being written (a
wrapper to dpkg) we have to talk to the dpkg people anyways. After all
they will be the ones implementing it.
> Behan> Now since we seem to first be building a wrapper around the
> Behan> current dpkg, I suggest these changes be requested of dpkg, but
> Behan> I still think that deity should work towards a common backend
> Behan> library that handles all things and deity and dpkg be simply
> Behan> possible front ends to this library.
>
> Hmmm. In that case, again, I thnk the design should be opened
> a bit more, at least the current dpkg designers should be included in
> this group.
Has nobody mentioned this ultimate merger to the dpkg people yet? I
expect that they won't really want to merge until they see more of the
benefits of Deity, but we can at least start to try and sell the idea to
them.
> Behan> I like dpkg as a command line tool, but as the backend to a
> Behan> more complicated GUI (in design, not useability), dpkg stinks!
> Behan> Building special GUI support funcions into a command-line tool
> Behan> is rediculous. Although for the first version it seems that is
> Behan> what we are faced with.
>
> Yesss, I think so. Actually, I think if we are going to go
> beyond a interface, into redesign of things, people should be
> forewarned (or else there is likely to be a firestorm when we unveil
> this. )
I have never said anything other than deity and dpkg should ultimately
be merged. I have said so on debian-devel and in private mail to many
people (not that I'm implying that you should have read this private
mail, but simply that I have said this same thing to many people).
I agree that people will be uncomfortable with this idea (as we've seen
in the past). I think it will become more palitable once they see the
advantages such a merger will entail.
> We tried initially to make Deity into a full fledged package
> management system, and were told to limit ourselves to a user
> interface module (if I recall the evnets clearly). I think we should
> not go beyond without notifying other people.
The entire deity design requires many changes to dpkg. All of them are
additions though. My point is that the appropriate people indeed need
to be talked too. Afterall, I'm sure they will be the ones that will be
doing the changes.
I think it was suggested that we concentrate on the UI for now, but no
one has ever said "dpkg is sacred and shalt not be changed by the deity
project". The goal of the first version of deity and the ultimate goal
of deity are two seperate things.
Of course, this is my understanding of how things stand in the deity
project.
> On the gripping hand, though, I am the newest member of the
> team, and may be getting to big for my britches. If ia have
> misunderstood the tenor of your message, please feel free to put me
> in my place ;-).
Well I for one plan not to put anyone in their places. We're all on the
same side here, we just have different opinions. There are no junior
members of this team as far as I am concerned.
Later,
Behan
--
Behan Webster mailto:behanw@verisim.com
+1-613-224-7547 http://www.verisim.com/
Reply to: