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

List:       koffice-devel
Subject:    Re: KTempFile wierdness
From:       Werner Trobin <trobin () kde ! org>
Date:       2001-05-31 5:42:19
[Download RAW message or body]

David Faure wrote:
> 
> On Wednesday 30 May 2001 23:28, David Faure wrote:
> > I think the real fix is to create a map, KProcess <-> some struct,
> > so that KoFilterManager::receivedStdout knows which process this is about,
> > and uses the correct data (document, tempfname etc.)
> 
> ... Another solution would be to create a new kofiltermanager for each conversion
> to be done. This might even be much simpler.

Yes, seems to be a better solution.

> It's a singleton currently, but this makes only sense at the KoDocument level
> (only one can get converted at a time...). Hmm, even that isn't really true anymore,
> with out-of-process conversion (and a slow machine, and a quick user :)

Hmmm... it *should* still block. As you probably have seen I'm using
the enter_loop() hack to have a semi-active GUI while the filter is
running (e.g. to show progress). Simon already pointed out a few problems
with it, but the plan was to make it still "block" in that sense that you
can't start a new conversion while you have another one running.

> BTW I volunteer to implement whichever solution we choose for KoFilterManager,
> since Werner has no time. But I'll wait for him to speak up first, since this is
> his stuff :)

I'm really sorry that I don't have the time... I either need Torben's
clone machine or a couple of hours more per day :}
However, I didn't look very closely, but making it a "normal" class
(no singleton) should be a possible solution for Shaheed's problem.

Ciao,
Werner

-- 
Werner Trobin - trobin@kde.org
_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel

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