Hi there, thanks Milan for your reply.
On Tuesday 20 Juli 2010 Milan Crha wrote:
> On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote:
> > Is it possible to define certain IMAP folders as "hidden" from within
> > our plugin's EPlugin part? Or is it possible to hide certain IMAP
> > folders (and their subfolders) in any other sensible way?
>
> Hi,
> you said you want to use imapx internally, is it right? And even if
IMAPX-only, yes. That's the master plan. :-)
> "only" the imap provider itself, then I would suggest to subclass it
> (your base imap provider) in your evolution-kolab "package" and manage
> this within CamelStore::get_folder_info, by calling parent class'
> get_folder_info and then recreate folder information based on your needs
> (once with email folders only, once with calendar folders only, and so
> on).
Hm. Maybe I'm still missing some parts here on how Evolution internally works.
Subclassing the Camel Provider in our backends and overloading
get_folder_info() will work for the backend part, i.e. PIM data wich is
accessed and managed from inside E-D-S. So far, no problem.
But there is standard Email to handle as well, and if I understood
correctly, Email handling is (presently) done inside Evolution, not E-D-S.
Now, if I create a Kolab account, I will see not only the Email IMAP folders
in Evolution (frontend, Email view), but *also* the parts of the IMAP tree for
the Kolab server which hold PIM data. These are simply IMAP folders, just that
they bear folder annotations. Other than that, the folders which hold PIM data
(as single emails with XML attachments) are no different from true Email
folders. This means, when I configure Evolution (2.30 let's say, without any
Kolab plugin) as to access a Kolab server, nothing hinders Evolution to
display the whole IMAP tree and the folders which hold PIM data just become
visible as standard Email folders.
This I cannot intercept from my backend code (or can I?), since Evolution
just accesses the Kolab IMAP server without knowing that certain IMAP folders
do not hold standard Emails which must not be accessible to the user. What's
more, the IMAP folder layout in Kolab may change over time, as I create new
address books, nesting things etc, so the folder tree is not static.
Therefore, I cannot just pre-configure which folders to show and which ones to
hide, I'll have to do this dynamically, solely relying on the folder
annotations telling me which kind of IMAP folder I'm facing.
For this to work, I would have to subclass the Camel Provider within my
EPlugin - is that possible? So far, I have only seen EPlugins using existing
Evolution infrastructure, but not changing the Camel Provider inside Evo...
> Hope that helps,
Partly, yes. :-) Please feel free to correct me on any misconception I have
regarding the internals of Evo/E-D-S, I'll be grateful for that. Also, if I
need to be clearer on any Kolab issue, please let me know as well.
> Milan
Best regards,
Christian
--
kernel concepts GbR Tel: +49-271-771091-14
Sieghuetter Hauptweg 48 Fax: +49-271-771091-19
D-57072 Siegen
http://www.kernelconcepts.de/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
