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

List:       kmail-devel
Subject:    Re: [Kde-pim] Re: ClientInterface (was Re: Fwd: [PATCH] kernel / UI
From:       Don Sanders <sanders () kde ! org>
Date:       2003-07-17 5:45:48
[Download RAW message or body]

On Wednesday 16 July 2003 06:50, Carsten Burghardt wrote:
> On Tuesday 15 July 2003 22:02, Andreas Gungl wrote:
> > I recommend to think over the targets to be worked for before any
> > further
> >
> > technical discussion continues. Is it to have different UIs? Is
> > it to allow
> >
> > many other applications (perhaps still unknown today) to interact
> > with
> >
> > KMail's core? Is it "only" a cleanup to separate core and UI code
> > in the
> >
> > current codebase?
>
> Probably all 3 of them should be considered. Personally speaking I
> think we should start cleaning up the codebase by cleaning up UI
> and processing code.

I think this is possibly a way forward.

Regardless of whether DCOP is used or not there seems to be a common 
desire to partition KMail into processing and UI code spaces.

Assuming the processing code is basically the same as the 
kernel/server code space idea and the UI code is basically the same 
as the client code space idea, and that cleaning up includes 
separating the processing/UI code then I think this is sensible 
longer term goal.

Futhermore I think there is work towards this longer term goal that 
can be started now. Especially if Andreas has time available to 
contribute now then I think it makes sense to use this resource 
rather than telling him to delay for yet another month. (Last patch 
was sent on 20-June)

More specifically I'm thinking that Andreas' KMailClient class makes 
sense whether or not DCOP is used. Perhaps Andreas could consider 
creating a non DCOP version of his patch, and adding a global 
KMailClient *kmclient variable to KMail.

This kmclient variable would act as the dual of kmkernel. kmclient 
would be used within kernel space (e.g. KMFolder*) whenever gui stuff 
needs to be done. There's the kmbroadcaststatus issue for instance 
that I mentioned, maybe this could just be solved by replacing direct 
calls to kmbroadcaststatus in the kernel with calls to 
kmclient->broadCastStatus()->method(args). So in general proxy UI 
class in kernel space through kmclient. (This would include stuff 
like creating a composer in kmkernel). Also later on further work 
could be done in investigating what else needs to be done in order to 
get kmkernel and kmclient running in separate processes.

Andreas' what do you think of this idea? Does it make any sense?

Ingo, Carsten, Zack, (I've given up on Marc) do you think a workable 
solution (submittable patch) could be found that initially doesn't 
use DCOP? Eventually to get the client and server classes running in 
different spaces we would have to use something like DCOP, and 
eventually KMClient could be put in a library. Once in a library 
KMClient functionality like creating a composer etc would be exposed 
to other Kontact/kdepim apps like KAddressBook and then when stable 
would be available for all KDE apps.

The reason why I would like to work on this now rather than waiting 
for Nove Hrady is that it's easy to sit around and discuss design in 
a committee. The hard part is actually trying to get the ideas 
implemented and working in code, that's the frustrating part when our 
mental model or the code collides with reality and the real problems 
become apparent. If Andreas is able to put time into doing this hard 
work now, then I think it makes sense to capitalize on this 
opportunity rather than squander it, and risk discouraging him.

> This can be started in 3.2. 
> If you look at kontact the most important thing about this
> separation is probably that it makes an integration in other apps
> is easier. We regularly get bug reports (wishes) to support other
> guis for kmail but I consider this only a sideeffect.
> I strongly vote for not mixing up things too badly for 3.2 as the
> risk for bugs is too high.

Yeah, personally I want to spend some time on setting up my home 
network, and a new website, reducing the load from my girl friend 
process, bug fixing, starting with reproducing some hard to reproduce 
problems, and then moving onto bug:4202 and bug:50997.

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]