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

List:       koffice-devel
Subject:    Re: Making koApplication inherits KUniqueApplication
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2005-10-26 10:40:12
Message-ID: 200510261240.16810.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 26 October 2005 12:04, Thomas Zander wrote:
> On Wednesday 26 October 2005 09:57, Boudewijn Rempt wrote:
> > > Hmm, can't you run the lengthy operation in another thread, as long
> > > as it doesn't touch the GUI?
> >
> > That's what I'm trying to do -- but I haven't solved it in a generic
> > way yet. Besides, the second view on the same document would still be
> > inaccessible when the thread is running.
>
> Are you sure?

I should have said "should". You shouldn't be able to paint on a document 
that's being restored with the cimg plugin.

> Only lengthy processes that run inside the event queue block all the
> windows events.
> So any threading solution will not have an effect there.

It's the other way around: if a lenghty process is working a document, I want 
to block all the views on that document, while still having the progressbar 
updating and the view repainted, of course. I'm not sure how to do that, 
actually, but I'll probably find out.

> Besides; the proper way is to show a progress bar in _all_ views 

Of that document -- not in the views of another document.

> and 
> change the mouse pointer to a stopwatch in _all_ views.  If you choose to
> do it in the background, then again the same UI locking should be done
> for all views of the same document.

Exactly, that was what I meant.
-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


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