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

List:       kmail-devel
Subject:    Re: [patch] Re: GUI consistency
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2002-08-31 21:08:39
[Download RAW message or body]

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

On Saturday 31 August 2002 20:54, Marc Mutz wrote:
> On Saturday 31 August 2002 18:57, Ingo Klöcker wrote:
> > - I didn't change the order of "Move" and "Copy", e.g. in the DnD
> > confirmation menu, because moving messages is in KMail much more
> > common than copying messages.
>
> That was actually the starting point of Martin, IIRC. I can imagine
> that it very much hinders productivity if this standard popup is
> permutated in each app.

I still didn't deactive the DnD popup in KMail (because it doesn't 
hinder my productivity). This means I have to select "Move" each time I 
want to move a message. Currently all I have to do is move the mouse a 
teeny-tiny little bit to the lower right and press the left mouse 
button. If we changed the order of Move and Copy in this popup menu I 
would be forced to disable the popup because it would hinder my 
productivity infinitely. The same is true for every other user.

Why did we introduce this popup? We introduced it to give the 
inexperienced user (who doesn't know that one can cancel a drag simply 
by pressing Esc and who doesn't know that one can copy instead of move 
by pressing Ctrl) a chance to cancel the DnD operation resp. to copy 
instead of move. You'll have to admit that copying a message is the 
exception while moving a message is a common task. Therefore moving a 
message should be more easy than copying a message. And this is why 
Move has to be the first item in the DnD popup.

I will reorder Move and Copy in all other menus to follow the standards.

> > - I removed "Unread Column" and "Read Column" from the View menu as
> > they are easily configurable via the RMB menu. We need to write a
> > Tip of the Day for this or else the users might not find it.
>
> Exactly because of this it should stay. An action SHOULD NOT (in the
> rfc sense) appear only in context menus.
>
> One might argue that the whole config option in and by itself is
> superfluous, though. *ducks* ;-)

Then why is "Display message size" not listed in the View menu? It's 
configurable via the configuration menu. This is o.k. because most 
users won't change this option very often if ever. (One could even 
argue that this option is also superfluous.) The same is true for the 
unread/total message count columns. Most users will only change this 
setting once. And options which are only set once shouldn't clutter the 
menus. (I think that all other items in the View menu are not only set 
once and therefore they should stay.)

BTW, are these columns enabled by default? If not, then we should 
probably change the default.

> > - I added KMMainWin::slotSetMsgStatusForwarded() and
> > KMMainWin::slotSetThreadStatusForwarded() in order to be able to
> > set the status of a message or a thread to "forwarded". I already
> > missed this a few times in the past.
>
> Oops, you're right. It ought to be there. Funny nobody saw this
> earlier.

I noticed it several times but I never bothered to change it.

> > - I moved "Search Messages..." to the Tools menu.
>
> Maybe rename it to "Find Messages..."? Just a thought.

o.k.

> > Furthermore the '&a' appears twice,
> > once for "Reply to _A_ll" and once for "Save _A_s". I'd prefer to
> > change "Save _A_s" to "_S_ave As". But this would cause a clash in
> > the File menu. Any suggestions?
>
> Do we already have the accel conflict resolver in place?

I don't know.

> Patch:
>
> -  message = i18n( "Cannot move a parent folder into a child folder."
> ); +  message = i18n( "Cannot move a folder into a subfolder below
> it." ); ? message = i18n("Cannot move \"%1\" to a subfolder of
> itself, \"%2\") ?    .arg( <parent> ).arg( <child> )

Malcolm suggested this change. Therefore I suggest changing it to
"Cannot move folder %1 into a subfolder below itself.".

Much better would be that only valid parent folders appeared in the 
folder list in the folder configuration dialog. Then this message would 
be obsolete.

> The icon for search message should be "mail_find". There's also
> mail_new etc. in HEAD's pics/

hicolor doesn't have those two icons. And in HEAD (some days old) there 
are only 22x22 and 32x32 versions of those icons. But for the menus we 
need 16x16 versions.

> And what about the QPixmap pointers that never get deleted??? :-o

I'll take care of this.

Regards,
Ingo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9cTBXGnR+RTDgudgRAqMbAJ0bO50wp42AqRT5DzeKQKGPC+tMfQCfXrdR
flLj83brD7uBxaK/DlmZ76Y=
=2edm
-----END PGP SIGNATURE-----

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]