[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Search Dialog
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2003-12-29 0:15:20
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 28 December 2003 22:38, Thomas Zander wrote:
> The search dialog is very unintuitive and the concept of search
> folders seems to be slammed in without any thought whatsoever.

I agree.

> First some global things; the buttons on the right
> (search/stop/close) are part of the dialog while each and every
> dialog in KDE makes those a different level.

Nobody will object if it's changed accordingly.

> Take a look at the find 
> dialog in konqueror to see that even there there is a visual line
> between those buttons and the rest.
> I fail to see why the comboboxes are editable,

Obviously because you never wanted to find all HTML only message in a 
folder. In this case you would have to search for "Content-type" 
contains "text/html". But "Content-type" is not in the combo box. Now, 
please don't suggest to add "Content-type" to the combo box. It's 
rarely used (and if it's used then it's only used by experts). So this 
would only unnecessarily clutter the combo box. Moreover there will 
always be a header missing in the combo box. And therefore it must be 
editable.

> plus it has an 
> strangly (unintuitive) ordered list of items.

Again we won't object if the items are reordered changed.

> So make it un-editable;

That's not an option.

> or remove 70% of the options.

The meta items have to remain under all circumstances. And then at least 
"Subject", "From" and "To" (although this one is already covered by 
<recipients>) should stay. I wouldn't object if the other ones would be 
removed. But then KMail should remember additional (manually entered) 
headers that a user has searched for.

> On top of that, put the  
> most used ones at the top.

Which are "Subject", "From" and "To"/<recipients> I assume?

> Making it uneditable additionally solves 
> the problem that I can currently search even while all comboboxes are
> empty.

We'll have to find another solution.

> The text fields are way too high (using keramic here and it seems the
> text fields take the same size of the comboboxes). Does not fit in
> the rest of KDE.

Layout problem. No objections against fixing this.

> The Fewer button stops working while I have 2 entries; I should be
> able to remove the 2nd entry!

No objection. I always wondered why we default to two entries anyway.

> The clean button should ask for confirmation.

No objection. But of course the confirmation should have a "Don't annoy 
me again" checkbox.

> Pressing 'fewer' should remove empty searches first so I can remove
> the 2nd while the 3th is filled.

No objection although a delete button next to each search rule would IMO 
be more intuitive.

> The statusbar at the bottom has the default text 'Ready.'  This is
> out of line with the rest of the application; ready is not needed,
> plus the dot at the end looks funny.

Agreed.

> The status bar fails to put some spacing left of the text making it
> harder to read. Additionally; I never actually see something like
> 'searching', its either Ready or Done.

Actually instead of Ready the current number of found matches is shown. 
But of course this number is only updated every once in a while, so if 
you just tested this with small folders then you might not have seen 
this.

> Stop fails to save my search (I did not say cancel did I?)

Save? Where? In the search folder? This would be a bug -> Don.

> I have to double click to open an email in the KMail front end, which
> is against KDE policy.

Do you know that you can perform actions on the selected messages? 
Opening a message as soon as it's selected would IMO be 
counterproductive. And I fail to see which KDE policy this violates.

> Sender/Receiver always shows sender, even if the item comes from a
> folder where the default is set to receiver.

Bug, I'd say.

> Ok, I'll stop now..
>
>
> I'm not going into the 'open'/'rename' buttons issue as that has been
> discussed recently; just that I fully agree that its needed for the
> 3.2 release.

What is needed? Changing it or leaving it as it currently is?

> In short; people that feel the search dialog is ready to ship are not
> doing the KMail project a service; I feel that it should get a good
> makeover or even that certain functionality (search folders) should
> be disbled for this release.

The search dialog hasn't change (except for the new Search folder 
functionality) since ages. So I fail to see why it should be ready to 
ship. IIRC Aaron wanted to redesign the search dialog (but I might be 
wrong, maybe he only wanted to redesign the folder properties dialog). 
It's a pity that he didn't have the time.

Also your complaints come a bit late in the release cycle. It wouldn't 
be wise to force any changes two weeks before KDE 3.2 is tagged for 
release. And since there will be an intermediate release between KDE 
3.2 and KDE 3.3 there's no need to rush any changes. It's not as if 
anyone would have complained about the search dialog in the last 5 
years.

> Last point; do you feel that I need to open 20 bugreports on this?

No. One patch will do. ;-)

> Or is someone willing to implement a UI file if I create one?

After KDE 3.2 is out I'll see what I can do.

Regards,
Ingo

[Attachment #5 (application/pgp-signature)]

_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel


[prev in list] [next in list] [prev in thread] [next in thread]