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

List:       kfm-devel
Subject:    Re: kio::netaccess and imagepreview
From:       Simon Hausmann <shaus () helios ! Med ! Uni-Magdeburg ! DE>
Date:       2000-06-13 13:02:00
[Download RAW message or body]



On Tue, 13 Jun 2000, David Faure wrote:

> On Tue, Jun 13, 2000 at 01:16:08PM +0200, Simon Hausmann wrote:
> > > Sure. That's why we need to implement Waldo's refcounting solution,
> > > so that the app doesn't exit as long as some download/stat is going on.
> > > Is it a problem if the window is closed, though ? Hmmm... For NetAccess
> > > it may be (since it's called from konqiconview). Maybe we also want a refcounting
> > > per window (or even part), then ?
> > 
> > I fear that's the only solution.. (quite complex :|
> > 
> 
> In fact what we want is to abort a NetAccess operation when we close
> the window / part. What about setting a parent object to the netaccess
> object, then ? Either the window or the part, or whatever else. And when
> the parent is destroyed, Qt destroys the child, and in the NetAccess
> destructor we abort the job if it's still running.
> Of course this is a major BI and SI change, since this means passing
> a parent object, in each of the static methods.
> But this ensures: aborts operation when parent is destroyed.
> (Note: this has nothing to do with real downloads (or file saving
> from an editor), which should be done with 0L as parent and a refcounting
> in kapp).
> 
> Hmmmmm, but it may still lead to crashes, if the control comes back from the
> NetAccess:: call, into somewhere in the object we are in the process
> of destroying... (child objects are destroyed in ~QObject so most of the 
> object is already freed).
> 
> For instance, the konqfileitem pixmap stuff is then used to set the icon
> ... in an item that would be already destroyed. We really need to limit
> what one can do while a netaccess operation is going on - just like with
> modal dialogs (only repaints but nothing else). See below.
> 
> > Ahh, wait, there was still Waldo's qt_enter_modal() patch. Hmmmmm, why
> > didn't it work? Ah, yes, because qt_try_modal in qapplication_x11 fails.
> > (due to the lack of a real modal widget) . I'm not sure if messing around
> > with the activeModalWidget stuff in qt (or any other hacks ;-) would
> > work...
> I'm not quite sure about this issue... but does the lack of a modal
> widget means that currently, when an app uses KIO::NetAccess::upload for saving
> a document right before exiting, the saving doesn't have time to finish ?
> That would be a huge problem indeed :-(

Looks like :}

> Oh - there's one thing we can do to get around the lack of a modal widget :
> creating one, hidden :-). That's what kfm did, AFAIR, or at least 
> the early implementation of NetAccess.

D'oh, yes, you're right!

  /* this is a bit tricky. We use a faked modal dialog to be able to
     process the download syncronious. For the user it will look
     (almost) as if the kfm-dialog is the modal dialog of your
     application. After show() we will also enter a local event loop
     within Qt. The modal_hack_widget will be hidden and destroyed in
     the finish slot. This will implictly exit the local event loop
     in addition (Matthias)
  */
  modal_hack_widget = new QWidget(0,0,WType_Modal);
  modal_hack_widget->setGeometry(-10,-10,2,2);
  copy(src, target);
  modal_hack_widget->show();
  qApp->enter_loop();

I wonder why it was removed from netaccess? :-)

Hmmm
revision 1.5
date: 1999/12/29 19:29:18;  author: granroth;  state: Exp;  lines: +11 -37
[...]
2) Removed modalDialogHack.  Since this existed before KIO, I assume
   it was somehow related to a Qt shortcoming?  In any event, I
   removed it and everything worked like a charm.

Aha! :-)

Bye,
 Simon

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