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

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

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

On Tuesday 10 September 2002 11:59, Carsten Burghardt wrote:
> Good point. Something similar (although on a gui-level) is done in the
> kfoldertree with the type-enum.

right...

> > 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...
>
> From an OO perspective the above solution is cleaner.

agreed, but i like to offer options in proposals =) 

this still leaves us with the fugly kmkernel trash, in, out, sent box methods. 
these should either be extended to reflect the true state of things 
(multiples of each), modified to indicate that they are the local defaults 
only, or be removed and the functionality put into the folders themselves.  
personally, i'm all for removal =)

a folder (and by extension a message) should be able to tell you what its 
associated trash/in/out/sent folders are. the kernel is innapropriate for 
this functionality in a multi-protocol, multi-home messenger app.

> > 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?
>
> The foldertree _needs_ to have a reference to the folder (select it, get
> the type, for the unread-count, ....), so where is the problem? The folder
> shouldn't really mess with the gui part, which a popup is definitely.

wrong. this is a context scoping issue.

the foldertree needs to know what type of folder it is to provide the correct 
options. take a look at the code in kmfoldertree.cpp starting around line 862 
to see just how much folder-specific knowledge is required. i count no less 
than 13 folder attribute queries in the creation of that menu, including 
querying whether it is an IMAP folder or not!

accessing this information in the foldertree makes things very non-extensible: 
when a new folder type is added that provides new options (think: plugins), 
the foldertree needs to be ammended. very non-OO and just asking for ever 
growing complexity in that bit of code. 

the RMB provides for context sensitive actions. the context is the folder. 
even the name of the popupmenu variable in KMFolderTree is "folderMenu". ergo 
the folder should provide the actions! the foldertree can take the liberty of 
_adding_ to these actions if necessary, but i truly doubt that would be 
necessary.

this also allows for other parts that aren't the foldertree (e.g. the search 
window) asking the folder for its RMB actions in a generic way. 

it's all about the benja.. uh... the context.

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

iD8DBQE9fjmr1rcusafx20MRAlqNAJ9QmYHdElRPr45sblNdRMLPw8nB/ACdGLpL
w0w1IlB46Jd1j2TJcGuDtQQ=
=4W4c
-----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]