[PATCH] Replacing email selection dialog in kmail

[Aaron J. Seigo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 30 November 2003 05:42, Ingo Klöcker wrote:
> On Monday 01 December 2003 00:34, Aaron J. Seigo wrote:
> > On Sunday 30 November 2003 12:02, Ingo Klöcker wrote:

> 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.

IME, yes.. these are real uses; conversely, you have yet to show that these 
useful buttons hinder the use of the dialog. all i've seen in this thread are 
assertions to that effect, but not one bit of explanatory reasoning or 
evidence.

> > UC 1: user opens up address picker, adds a few addresses, which to
> > add another address.
>
> ??? This sentense doesn't make sense, does it? 

sorry.. typo.. s/which/wishes/

> 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?

you're right, in fact in a perfect world all the addresses they need would 
come pre-loaded in the address book. we don't live in that perfect world. in 
the real world people DO need to enter addresses by hand. i do it all the 
time when on the phone with people, for instance. and i've usually got an 
email composer window open already...

> > 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).

how? with a double click? no, that would add the address.
with a right click context menu? no, most wouldn't find that.
ditto for names, of course, or any other part of address info this gets used 
for eventually. 

> > 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.

at least we agree on this one? =)

> >  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.

yes, i'm fully aware that it starts the address book. i'm not an idiot. the 
original plan, as i was told many months ago anyways, was that the edit 
dialog was going to be pushed into the library so it was usable by multiple 
applications w/out relying on kaddressbook.

> >  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.

it often doesn't work ... or at least it doesn't work here. would be nice, 
though. more bugs i suppose.

> >  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.

at least it only opens the edit dialog, and not the whole app. and as i stated 
previously, the plan is/was to export that dialog into a library.

> It seems that you don't know the code. 

but at least i have you around to be condescending... ;-)

>     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? ]

it is. apparently you don't know the code either? ;-P i suppose this is there 
for a "worst case failure" situation that shouldn't ever be reached. 

hrm. just noticed anoter bug: the Edit button gets enabled when the Recent 
Addresses list item it selected (it shouldn't). it also doesn't get 
deselected after an entry is added to the recipients ...

>   KRun::runCommand( "kaddressbook --editor-only --new-contact" );
> [ see above ]

all that's needed now is a patch ;-) seriously, i don't think this was 
intended to remain here for this long; i believe Zack planned on having this 
dialog available directly via the library making this hack unecessary.

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

heh... again, IIRC this was waiting on functionality in the libs. Zack?

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

just to be clear: this isn't originally my code. but i'm willing to look into 
it later this week ...

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

because i thought i'd already covered that point thoroughly =P

> (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

yes, it needs that final polishing to clean it up. i'd rather do that than 
have you throw the baby out with the bathwater.

> 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.

ever considered a career as a motivational speaker?

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
"Never weary, never dispair, never give in" - Winston Churchill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/yqnv1rcusafx20MRAk3RAJ9BrR/qMf4gLUCEW4PvvrIuJ44GVQCfQEmW
8Zz3l6TXpbNlFekkEIHIG7w=
=pXzK
-----END PGP SIGNATURE-----