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

List:       kmail-devel
Subject:    Re: kmfolder smarts, kmfoldertree, actionCollection
From:       Don Sanders <sanders () kde ! org>
Date:       2002-09-10 18:59:05
[Download RAW message or body]

On Wednesday 11 September 2002 03:40, Aaron J. Seigo wrote:
> -----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?)

KMDeleteMsgCommand, takes a list of messages so it should cover the 
job.

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

Well unfortunately in KMDeleteMsgCommand I had to leave in an "==imap" 
because of this trash problem. I did feel pretty guilty about that 
though, and it does need to be fixed.

But I think KMDeleteMsgCommand given a list of all messages should do 
the trick.

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

Yep.

> 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'd prefer just doing the KMFolder::folderType first, and I would use 
KMFolder::folderType in the singular (I think that's Qt style which 
is probably also KDE style).

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

Is it so bad for kmfoldertree to have intimate knowledge of the 
folders it contains? I mean it needs if for determing which icon to 
display for instance.

Or is that another instance of the same problem should KMFolder have a 
pixmap method as well? I guess that would make sense.

It could it making sense to put these in KMFolder if there was a need 
to show the folder properties dialog outside of KMFolderTree. Is 
there such a need?

For instance if we want to show folder pixmaps in the move and copy 
nested menus then it would meake sense to put a pixmap method in 
kmfolder.

But then again not putting these in KMFolder is probably creating an 
aftifical barrier that will prevent the folder popup menu from being 
shown elsewhere.

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

Oh, I didn't realize that is the way actionCollectin works, well sure 
kernel is the place for that kind of thing.

Sounds fine to me.

Don.


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