From kmail-devel Tue Jun 03 06:54:00 2003 From: Andreas Gungl Date: Tue, 03 Jun 2003 06:54:00 +0000 To: kmail-devel Subject: Re: [PATCH] UI abstraction proposal (partially only) X-MARC-Message: https://marc.info/?l=kmail-devel&m=105462344624908 Am Dienstag, 3. Juni 2003 00:36 schrieb Zack Rusin: > Hi, well this is probably the most desired of our goals for the > not-so-near future, but definitely not the way you're doing it. The way > you're doing it, has pretty much no appeal as the gui is still a > compile time dependency therefore nothing changes except the fact that > there's another level of method calls. > The patch you presented gain us nothing. The idea is that we need to > seperate core from gui but not as a compile option, but a run-time one. > Meaning one core is running and you can have twenty gui's for it > running. One in a terminal, one in a remote X session, one in a local X > session etc. Hi Zack, as I wrote I've no problem to discard this little piece of work. However your criticism is not very informative in the sence of how to do it, except that you mention compile time independency. What kind of communication do you want to use between kernel and UI? (You need one to prevent compile time dependencies, or would you like to load libs dynamicly?) What are in your opinion the necessary steps to reach the final goal? Do you plan a big step made by some developers working through some nights to split logic and UI? I would prefer little steps (like building a mosaic picture) which are possible along the normal release cycles. For example, my patch is no big deal (as you've stated correctly), but it separates UI code and logic in different classes. This makes further refactoring easier, because then you can focus mostly on the UI related classes. And you have some kind of callbacks ready no matter what kind of calls/communication you'll use later. Can you try to draw a "big picture" how to continue best. I'm interested in your and other's opinions about the way to go, and I think, the discussion could bring some light on this issue. Regards, Andreas _______________________________________________ KMail Developers mailing list kmail@mail.kde.org http://mail.kde.org/mailman/listinfo/kmail