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

List:       kmail-devel
Subject:    Re: Last attempt at reconciliation
From:       Bo Thorsen <bo () sonofthor ! dk>
Date:       2002-09-18 8:21:19
[Download RAW message or body]

On Tuesday 17 September 2002 21:35, Zack Rusin wrote:
> - we have two approaches to integrate KMail with kdepim packages.
> kgroupware has one and make_it_cool has one. The big problem I have
> with the kgroupware approach is that it majorly bloats KMail code,
> making it even harder to understand - for people who want to help us -
> and for ourselves. And to be completely honest, even on screenshots it
> looks not too promising. I find Don's and Daniel's approach with Kaplan
> _way_ superior. I think Kaplan and KMail as KPart is the way to go.
> Comments?

I see in your other mail that you already found out that the bloating problem 
is now moot :-)

As for the integration decision, I don't really think there is a problem. 
After Karl Heinz reorganized the kroupware specific code, there shouldn't be 
major problems re-uniting the KMail as KPart approach in make_it_cool. This 
way users will have the decision.

What is important for us is to minimize the hassle of coming back to HEAD. 
When the kroupware deadline is over and KDE 3.1 is out, I personally want to 
put the branch to rest. This means that if you see us doing something which 
makes this more difficult, please say so. You did with the kmmainwin changes 
so these are now resolved.

> - now people have problems with changes in make_it_cool. I want to know
> exactly what changes from make_it_cool bother you so much, so in no
> particular order:
> o my folder rework, asynchronous access to all folders, common
> interface, all folder use kmfolderjob, no distinction between local and
> imap folders. Problems? What? Why?

Please, oh please, keep this going! While working on the disconnected IMAP 
stuff, I have ran into so many problems because your work wasn't done yet. I 
can't wait for you to go on :-)

Example code problem:

void KMMainWin::slotMsgSelected(KMMessage *msg)
{
  if (msg && msg->parent() && (msg->parent()->protocol() == "imap") &&
      !msg->isComplete())
  {
    mMsgView->clear();
    KMImapJob *job = new KMImapJob(msg);
    connect(job, SIGNAL(messageRetrieved(KMMessage*)),
            SLOT(slotUpdateImapMessage(KMMessage*)));
  } else {
    mMsgView->setMsg(msg);
  }
  // reset HTML override to the folder setting
  mMsgView->setHtmlOverride(mFolderHtmlPref);
}

This basically boils down to

if (imap)
  approach1()
else
  approach2()

Yuck!

Your work with the command restructuring will solve this (at least I hope so 
:-) by putting the code into the responsible classes.

> o Daniel wants to refactor a lot of stuff - getting rid of the KM
> prefix, putting classes in the KMail namespace and putting files into a
> more approachable dir structure. Any problems with that?

At least the namespace part makes sense to me. Putting files in separate 
directories is a trade-off. I don't have the KMail code experience to comment 
on it.

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klarälvdalens Datakonsult  |   Denmark

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