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

List:       kmail-devel
Subject:    kmfolder smarts, kmfoldertree, actionCollection
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-09-10 17:40:50
[Download RAW message or body]

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

hi...

so now that we have "move to trash" and "delete" as actions, we have a "funny" 
situation:

right click on the trash can and discover you can only send messages to the 
trash. well... they already are =P

obviously, it should be "Empty trash" on trash items which results in a series 
of KMDeleteMsgCommands (or perhaps there should be a "KMDeleteAllMsgs" 
command to kill all the msgs in a folder? don?)

so while looking at a good fix for this (because it pissed me off ;), i 
discovered that i would once again have to resort to the dreaded "== imap" 
bullshit to get it right for all situations. this is obviously not an option. 
well, not unless i want to suffer the wrath of the zack-meister ;)

KMFolder ought to be able to be queried for wether or not it is a trash 
folder. i propose that isSystemFolder be changed to return an int, not a 
bool, that is an or'd set of flags called KMFolder::folderTypes or some such. 
zero would be "normal msg folder", and non-zero would be reserved for trash, 
in, out, sent, etc... this would allow for future possibilities where we 
would want to have one folder have multiple roles (e.g. sent and trash), 
while preserving the ability to do "if (folder->isSystemFolder())". it would 
also allow us to check for things like "is it a trash folder?" in a way that 
doesn't require knowledge of the protocol or specifics.

alternatively, kmkernel->trashFolder() could be changed to return a 
QPtrList<KMFolder*> and have every folder that is a trash folder register 
itself with the kernel when it is created. the same could be done for out, 
in, etc... this allows for checking if a folder is a trash (or other system) 
folder by getting the list and seeing if it is in that list and also allows 
for multiple trash/in/out/sent/etc folders...

perhaps both of the above should be done.

i also noticed that kmfoldertree creates the RMB menu for folder items. this 
means that kmfoldertree needs intimate knowledge of the folders it contains. 
perhaps folders should provide their OWN RMB menu and the folder tree can 
simply request the correct menu from the correct folder?

which brings me to my next point of contension: actions.

currently kmail populates the kmmainwin actionCollection() with actions. this 
may seem fine at first glance, but it presents several unsavoury situations:

 o multiple windows == redundant actions and action collections!
 o for items that aren't aware of the main window we end up duplicating 
strings/actions. this means changes in one set of actions needs to be made in 
multiple places.

i ran into the second situation with the trash problem. i'd recommend we put 
an actionCollection in KMKernel and host all the actions there so that 
various parts of KMail that need them can just plug them in as necessary. 
this will allow string, accel, icon, etc changes to be made in one place 
only.

thoughts, rants, raves, flames?

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

"Everything should be made as simple as possible, but not simpler"
    - Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9fi6i1rcusafx20MRAj5UAJ9CfU/i6hhLjeEGpCjmp6s44++S1ACgi0uQ
IoOBAM8ffP9BDs3iP8Uoftc=
=601J
-----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]