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

List:       koffice
Subject:    RE: KOffice loading and saving progress info
From:       David Faure <David.Faure () cramersystems ! com>
Date:       2000-03-08 16:27:59
[Download RAW message or body]

> > Asking the kview part to respect the doc/view model is definitely
> > adding complexity for nothing.
> > 
> > Perhaps the best solution (i.e. not to do now) would be to
> > create an intermediate layer, just like KOParts could have been:
> > something on top of KParts, with the document/view model, 
> > but not KOffice specific. A very good candidate for this would be
> > KWrite, of course, if it wants to go for the document/view model.
> > And KOffice would then use this "document/view-enabled" KParts.
> > That's the way I thought you would do KOParts at the time,
> > but without really knowing anything about it - and it would have had
> > to be named otherwise anyway. :)
> 
> Sure we can test this KO(ther)Parts with KWrite. I'm currently really
> dissatisfied with the currewnt KWrite when loading really great files
> ( > 50k ). Perhaps this can make it better.

Those are two different issues.
This (vapourware) KO(ther)Parts (hehe) would mean converting
KWrite to use the doc/view model, which I don't know if it does
(I believe the old one did, actually....)
But the framework needs to be written first :)

What is the problem with loading long files with KWrite ?
Since KWrite is a KRWP, it should show a widget before the document
is actually loaded. Or I mean it could, if it doesn't.
It doesn't have the KOffice problem of "I need the (full) document
before I can show anything".

Progress info is another matter, though. You could reuse whatever I do
for KOffice, or you could try KProgressDialog and I could steal
your solution ;-)

David.

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