[PATCH] Replacing email selection dialog in kmail

[Ingo Klöcker]

On Monday 01 December 2003 00:34, Aaron J. Seigo wrote:
> On Sunday 30 November 2003 12:02, Ingo Klöcker wrote:
> > Or why it's not possible to add a distribution list to the
> > list of addressees (and by this I mean the name of the distribution
> > list and not all it's members).
>
> this is indeed a bug, but has nothing to do with the layout of the
> dialog.
>
> > Why can one Add, Edit or Remove
> > contacts from the addressbook in an address _selection_ dialog? Why
> > can one save distribution lists from there?
>
> two words: use case.

I can come up with use cases for everything. The question is whether 
those use cases occur often enough to rectify adding a button for this.

> UC 1: user opens up address picker, adds a few addresses, which to
> add another address.

??? This sentense doesn't make sense, does it? Anyway, I guess I know 
what you want to say. But normally the user will hopefully right click 
on all new addresses (in the message viewer) and add them this way. Why 
should a user enter an address by hand? This will just lead to UC 2. ;-)

> UC 2: user opens up address picker, notices than an email addy is
> wrong and should be changed.

Then why is the email address not editable directly in the listview? This 
makes much more sense than opening the addressbook dialog (see below).

> UC 3: user opens up address picker, sees an old entry in there that
> should be removed.

If it just would work (cf. below).

> UC4: user picks a bunch of addresses to send an email to and decides
> that since they'll be doing this often, should save that selection as
> a grouping.
>
> the best answer to each of those UCs is to allow them to immediately
> add, edit or remove the entry. if we force them to open up the whole
> address book we:
>
>  o cause them to wait longer while the address book starts

HAHAHA. Obviously you didn't have a look at the code. It does start the 
address book, so there's no gain.

>  o cause them to find the addy in the address book application AGAIN
> after they had ALREADY found it once in the address picker
>  o cause them to hide the address picker dialog in kmail and open it
> again so it can refresh the changes

Huh? The dialog already watches the address book and the distribution 
lists for changes (which results in strange crashes which Tobias wasn't 
able to track down). So this is also no valid argument.

>  o cause the user to switch between using kmail and using another
> application which is distinctly different. think of it as a human
> "context switch" with all the same sorts of overhead a context switch
> incurs in an OS kernel.

But that's exactly what's happening with the current code. KAddressBook 
is started.

It seems that you don't know the code. So let's have a look at the behind 
the three buttons (my comments are in brackets):
=====
void
AddressesDialog::editEntry()
{
  AddresseeViewItem *item = static_cast<AddresseeViewItem*>( d->ui->mAvailableView->currentItem() );

#if defined( Q_CC_GNU )
#warning "This is rather crappy"
#endif
[ ^ this comment speaks for itself, editable listviewitems should be used instead ]
  if ( item ) {
    if ( ! KStandardDirs::findExe( "kaddressbook" ).isEmpty()  ) {
      KRun::runCommand( "kaddressbook -a " + KProcess::quote( item->addressee().fullEmail() ) );
[ startServiceByDesktopName has to be used here ]
    } else {
      KMessageBox::information( 0,
                                i18n("No external address book application found. You might want to "
                                     "install KAddressBook from the kdepim module.") );
[ 
    }
  } else {
    KMessageBox::information( 0,
                              i18n("Please select the entry which you want to edit.") );
[ Huh? Why is the Edit button not disabled if no item is selected? Is
  this usability? ]
  }
}

void
AddressesDialog::newEntry()
{
#if defined( Q_CC_GNU )
#warning "FIXME: do not call kaddressbook"
#endif
  KRun::runCommand( "kaddressbook --editor-only --new-contact" );
[ see above ]
}

void
AddressesDialog::deleteEntry()
 {
 }
[ Whoa? I'm impressed. This method is indeed absolutely bug free. ;-p ]
=====

I wonder when someone intended to implement the missing functionality 
and fix the FIXMEs.

> for the distribution list UC (#4) we can add the fact that allowing
> them to compile a list while addressing an email allows them two
> accomplish two tasks at once, and from the best perspective, that of
> actually peforming the task (rather than pretending to while in the
> address book, as in, "If I were to actually send an email that needs
> to go to all <insert grouping>, who would that include?")
>
> as for the buttons themselves, they are the bottom of the list. this
> keeps them well out of the way of the work flow. it isn't like they
> are on the top of the list, at the bottom of the whole dialog, or
> garishly in the middle.
>
> > gives milk and wool and which lays eggs"). It doesn't really solve
> > the task that it is supposed to solve, namely to make it easy for
> > the user to select the To, the Cc and the Bcc recipients. (Mostly
> > because of many bugs.)
>
> this dialog is better because:
>
>  o it scales to many addresses
>  o allows picking To, Cc and Bcc simultaneously
>  o supports the quick creation of To lists with double click
>  o supports distribution lists and email groupings

It's interesting that you didn't mention:
 o allows adding, changing and deleting address book entries
;-)

It seems the real problem I have with the new dialog is not the layout (apart 
from the stupid QSplitters) but that it's simply full of bugs (just have 
a look at the KMail bugs), FIXMEs and even missing implementations. In 
the current state it's far from being ready for prime time and we are 
already deep in deep freeze. Originally Coolo even wanted to release 
KDE 3.2 around this date. So when would this code have been fixed/finished?
Who will fix it? Those stupid PIM guys that anyway don't have anything 
better to do than to make this halfbaked dialog work? Sorry, but it 
really makes me angry if I see something like this. It shows that some 
people lack the responsibility to finish what they have begun. That's 
really sad. You should thank Tobias that he's now begun to work on this. 
But you can't expect him to fix all those FIXMEs that someone else left 
behind.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20031201/6fdcffd9/attachment.sig>