Chris: is this still 1.0?

This is a new feature, but we're past feature freeze, so it's getting
marked Future.

Would it be hard to replace the ETables on the right with multi-line
EEntries?  Does EEntry do word-wrap?

This sounds like the main constraint to me.  On Outlook, they just
have an entry widget on the right like the one you have in the
composer window; but instead of scrolling horizontally, it wraps and
scrolls vertically.  If EEntry can be made to work that way, then the
change is probably trivial and I would go for it.  Otherwise, we have
to stick with the ETable for now.

EEntry does have word wrap and multi-line abilities but I don't
believe it's mature enough to be added here at such a late date.

How major/trivial is this? If it's reasonably small, it should be a
1.2 UI enhancement, otherwise, it's 1.4 material.

I believe this is 1.4 material, but then I haven't seen a good
proposal for what the GUI should look like, so it's hard to plan how
much time it will take.

anna, do we have a mockup for this?

well, what miguel is proposing doesn't need a mockup (if i am
understanding this properly). he is just requesting that a
(more-or-less identical to the user) different widget be used in the
existing dialog. 
I'll make a mockup if Chris feels it is necessary, but this seems
a bit ridiculous to me. In point of fact, I can't even use e-tables
or e-entries in glade.

This should be trivial.  We just stick an EEntry which is the same as
the one used in the To: Cc: Bcc: boxes and we are done with it.

Assigning to Trow.

Uh, if you are suggesting that we replace the ETable with an EEntry,
it isn't trivial.  It certainly is doable, but it isn't trivial.

Just dropping in EEntry would result in very different (and very
wrong) semantics than the ETable.  It will have to be hacked to map
commas to newlines, select on left-clicks, etc.

trow: so if that is the scenario, this is well more than the current
'severity'? 

Luis: Yes, you are right.  I'm boosting the severity, but this is
really just a stab in the dark.  The problem is that most of the work
required would be ugly hacks to EText, and EText is already pretty big
and complex.  It is hard to say just how easy or hard it would be
until I popped the hood up and got my hands dirty.

Maybe I'm just being pessimistic, but I think that this should be a
"1.2 if we have time, later otherwise" kind of feature.  It just
doesn't seem that important to me... or at least, the importance seems
disproportionate to the PITA-factor in implementing it.  But that is
just me.

Don't get me wrong: it is doable.  Maybe things would fall into place
and it would just be a two-day hack.  The big question is how
important it is for us to have the UI work the same as Outlook's.

Marking this down to Minor.

Trow: is the main problem the fact that EText doesn't do word wrapping?

Ettore: EText does do word-wrapping.  The hardest part would probably
be to get the button-click semantics working properly.  It _might_ be
doable in a not-too-awful way, but I suspect it would come down to
peppering e-text.c (which is already big and complicated) with a bunch
of

if (etext->emulate_etable_mode) {
  /* big annoying hack */
} else {
  /* the usual behavior */
}

type code, which doesn't exactly thrill me.

And then there are other issues.  Do we want to let people edit
addresses, or just enter new ones?  If we let people edit the
addresses (which would be hard to prevent if we used EEntry -- we'd
need to add more ugly hacks to prevent it), then we'd need to add
logic to the select-names dialog so that the editted name would move
back to the left column again.

Doing a rough working implementation isn't really the problem: it is
getting all of the details right.

I think we want to allow normal editing on the right, like the entry
boxes in the composer window.

I am not sure what you mean with changing the button semantics -- I
think it should just work normally, like a standard EEntry.  Removing
of addresses would be done by either editing with the keyboard
normally, or right-clicking and doing "remove".  (This is a feature
that would be useful in the main composer window too, so we would not
even have to special-case this).

Plus, I think we can remove the feature that hides the addresses as
you select them in the left box (if that's what you are talking
about).  I don't even think Outlook does that.

Would this make the whole thing more doable?

OK, this is largely fixed in CVS.  It will probably need some more
tweaking to get all of the semantics right.

What we have now will probably need some EText-ish polishing.  Clahey,
perhaps?

Trow has fixed this.