From koffice Fri May 26 00:31:40 2000 From: Don Sanders Date: Fri, 26 May 2000 00:31:40 +0000 To: koffice Subject: Re: kmail & koffice X-MARC-Message: https://marc.info/?l=koffice&m=95930147801062 > > > (You might think: let's not embed the full konqueror but just one of > > > its views, like the icon view, but that is not possible, since > > > koshell is a very stupid koffice mainwindow, does nothing but embed parts, > > > whereas the konqueror mainwindow does _a lot_). > > > > This is interesting, so for the kde-pim project when we come to merging the > > organizer/mail-client/adress-book we might be best of merging their mainwindow > > code rather than making each of these things an embeddable part then? > > I don't see why you're saying that - the point here is that konqueror in itself > is already a kparts mainwindow, so embedding it in a super-mainwindow doesn't > really make sense. But turning many apps into parts and embedding them > into a common framework (e.g. mainwindow) makes sense - it's exactly > what the current work in kdegraphics (kviewshell) is about. Ahh, so the correct analogy would be - if there existed a kde-pim application that embeds various pim parts then that kde-pim application would be equivalent (in some sense) to konqueror, and it would not make sense to embed it in koshell? (Because the kde-pim application would already be a kparts mainwindow so embedding it in a super-mainwindow wouldn't make sense). I guess another example would be it doesn't make sense to try to embed koshell within itself. > > I am wondering what the best way of merging these projects is. > > > > Actually I had been thinking that there could be multiple mail-client/address > > book parts and the user would choose the one they liked. > Yes - much like the texteditor interface currently being developed in kdelibs > (of which kwrite is an implementation). Or much like browserextension, etc. OK. I should keep on eye on how this texteditor interface evolves then, it would seem relevant. BFN, Don.