Bug 3756 - Remove a recipient row when the delete button is clicked
Summary: Remove a recipient row when the delete button is clicked
Status: REOPENED
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: UI/Compose Window (show other bugs)
Version: other
Hardware: PC Linux
: P3 enhancement
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2017-01-10 18:27 UTC by larivact
Modified: 2017-01-11 06:36 UTC (History)
0 users

See Also:


Attachments

Description larivact 2017-01-10 18:27:52 UTC
While the compose window allows you to easily add recipients you can't remove them once added. Probably the "Delete entry contents" buttons should be replaced by "Remove recipient" buttons? I don't think that the "Delete entry buttons" should be there in the first place since selecting everything and hitting backspace is pretty straightforward.
Comment 1 Paul 2017-01-10 18:34:07 UTC
The user can remove added recipients using the delete entry button which you mention.
Comment 2 larivact 2017-01-10 18:44:02 UTC
Since when? I am using 3.14.1 and it doesn't work for me. Is it fixed in the repo?
Comment 3 Paul 2017-01-10 18:45:14 UTC
What exactly doesn't work for you?
Comment 4 larivact 2017-01-10 18:49:56 UTC
When I hit the "Delete entry contents" button it only clears the field but the recipient row is still there.
Comment 5 Paul 2017-01-10 18:57:22 UTC
Yes, that's how it works. Is an empty row a problem for you?
Comment 6 larivact 2017-01-10 19:05:48 UTC
From a user experience perspective you should be able to.
A row represents a recipient, to add a recipient you add a row,
now what do you do to remove a recipient?
The delete button only clears the field it isn't obvious that claws ignores
empty recipient fields. However if the button removed the row it would be obvious that the recipient is removed.
Comment 7 Paul 2017-01-10 19:15:12 UTC
re-opened because it's now an enhancement request, even though I am in total disagreement with comment #6. (For instance, there is always an empty row.)
Comment 8 larivact 2017-01-10 19:25:24 UTC
Thanks for reopening I appreciate it.

>For instance, there is always an empty row.

Which is why the first row shouldn't have a delete button.
Comment 9 larivact 2017-01-10 19:28:24 UTC
I apologize that would be bad design, instead the delete button should be disabled when it's the only row.
Comment 10 wwp 2017-01-11 00:42:53 UTC
Not exactly that simple: row 1 should get a greyed-out delete button IF it's the only recipient.
If you have
To: foo
Cc: bar
To: another
You must be able to remove the 1st To:.

Moreover, I wonder if a sweep is the best icon for 'delete' action, to me it's more clean than delete. But since it doesn't really delete the repicient but cleans the recipient field up, it's fine. Then don't call this a delete button.
<<mad>> :-D
Comment 11 Ricardo Mones 2017-01-11 00:46:30 UTC
(In reply to comment #6)
> From a user experience perspective you should be able to.
> A row represents a recipient, to add a recipient you add a row,
> now what do you do to remove a recipient?

A row is a space to enter recipients, can be zero, one or more than one.

That association of one-row is one-recipient is completely imagined by you :)

> The delete button only clears the field it isn't obvious that claws ignores
> empty recipient fields.

It isn't? Do you expect it to send a mail to a blank string "address"?

I've heard a lot of absurd things, but this one is a real finisher :)

> However if the button removed the row it would be
> obvious that the recipient is removed.

Could be *more* obvious, yes.

Would also made replacement of addresses harder, because you have to go the end of upper field, and press enter, and select again the address header if incorrect, and then start typing.

I guess the entry could be removed if the user clicks the delete button and the entry is already empty. That way current behaviour is preserved and doesn't disturb existing work-flows for address replacement, and you should be able to remove entries with a second click, as requested.
Comment 12 Ricardo Mones 2017-01-11 00:49:24 UTC
(In reply to comment #10)
[...]
> Moreover, I wonder if a sweep is the best icon for 'delete' action, to me
> it's more clean than delete. But since it doesn't really delete the
> repicient but cleans the recipient field up, it's fine. Then don't call this
> a delete button.
> <<mad>> :-D

It's default GTK stock icon, not ours.

And yeah, you're reaching some kind of icon-caused insanity ;-)
Comment 13 Ricardo Mones 2017-01-11 00:59:55 UTC
(In reply to comment #11)
[...]
> I guess the entry could be removed if the user clicks the delete button and
> the entry is already empty. That way current behaviour is preserved and
> doesn't disturb existing work-flows for address replacement, and you should
> be able to remove entries with a second click, as requested.

And while at it: after first click the brush icon on the button should be changed to a minus or delete red icon, to indicate that second click is going to remove the row completely.
Comment 14 larivact 2017-01-11 06:36:54 UTC
@wpp
>Not exactly that simple: row 1 should get a greyed-out delete button IF it's the only recipient.

That's exactly what I said in comment #9. 

>Then don't call this a delete button.

Currently it isn't a delete button, this enhancement request is about making them delete buttons.

@Ricardo

>A row is a space to enter recipients, can be zero, one or more than one.

Thanks, I didn't know that a row can contain multiple recipients.

>Would also made replacement of addresses harder, because you have to go the end of upper field, and press enter, and select again the address header if incorrect, and then start typing.

You can just: select the field, hit Ctrl+A followed by backspace.

>I guess the entry could be removed if the user clicks the delete button and the entry is already empty.

Buttons changing their functions is unintuitive.

I still think these buttons should be delete buttons, but you Paul had a good argument that I didn't get yesterday. When you type into the field of the last row it immediately adds a new row below it. I think that instead there should be an add recipient button, with a simple plus as the icon.

To make this system keyboard friendly backspace in an empty field could remove the row and enter in a field could create a new row below the current one.

Note You need to log in before you can comment on or make changes to this bug.