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

List:       kmail-devel
Subject:    Re: kmfolder smarts, kmfoldertree, actionCollection
From:       Carsten Burghardt <cb () magic-shop ! de>
Date:       2002-09-10 18:41:27
[Download RAW message or body]

On Tuesday 10 September 2002 20:27, Aaron J. Seigo wrote:
> 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 =)

Me too, but what is the best fix for 3.1? You can't delete this thingy.

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

Yup.

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

OK, is there a possibilty to split the actions (which the folder knows) and 
the display?

-- 
Regards,

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