[PATCH] ReadWritePart::queryClose()

[John Firebaugh]

On Sunday 01 December 2002 4:51, you wrote:
> (You removed the kde-core-devel cc - intentionnally?)

Oops, no, was using a bad web-mail interface.

> On Monday 02 December 2002 00:17, you wrote:
> > But saveAs will only be called from queryClose if the document is new, in
> > which case there won't be a temp file, right?
>
> Not necessarily. E.g. in KOffice when you import a file (from another
> format), you get a document with no URL, so that when you press Save, it
> will go to "Save As", to force you to save it as a native format document.
> Same thing if you get the "wanna save?" dialog -> you then have to specify
> a filename to save that stuff to.

But is there a temp file in that case?

> Ok, this doesn't mean that your change necessarily breaks KOffice, since
> it reimplements quite a lot of that stuff (for various other reasons), but
> anyway, I think it's wrong to assume that only "created from empty"
> documents have no URL.

Well, that's basically exactly what the code does:

if (m_url.isEmpty())
{
    KURL url = KFileDialog::getSaveURL();
    ...
    return saveAs( url );
}
return save();

> > >I would suggest moving m_bClosing=true before the saveAs() call, as it
> > > was before - after all queryClose() is about closing in all cases,
> > > right?
> >
> > When queryClose is called on it's own (not from closeURL), it isn't
> > guaranteed that the document is really closed afterward (something else
> > could cancel the close).
> >
> > Therefore the temp file must remain, which is why I only set m_bClosing
> > to true from closeURL.
>
> Hmm. Ok. In fact the temp file will get deleted anyway - by
> ReadOnlyPart::closeURL, which is called upon destruction.

Yes. BTW, how does that work when the file is being uploaded asynchronously? 
I.e. what happens if the part is deleted before the upload finishes, and thus 
the temp file is removed? Does kio make a temp copy of its own before this 
can happen? Or is the app supposed to wait for the upload to finish?

> Hmm, difficult indeed, at the Part level we have no concept of the
> "window-level closing operation". So it can be cancelled after
> queryClose(), even if queryClose() said ok (yes or no).... Maybe a solution
> is to introduce another method, say cancelClose(), which lets the app tell
> the part that "we're not closing anymore". So the part could set m_bClosing
> in queryClose(), but would reset it in cancelClose(). And closeURL()
> wouldn't do anything if m_bClosing - since that means queryClose was
> already called, so the user was already prompted.

Seems like a kludgy solution. I'd prefer an overloaded closeURL() with a flag 
that controls whether or not to prompt.

Actually, apps that use the queryClose() method could just make sure to call 
ReadOnlyPart::closeURL() instead of ReadWritePart::closeURL(), or leave it to 
the destructor to call, which is what I have kate doing.

How about this patch?

-John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: queryClose.diff
Type: text/x-diff
Size: 4322 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20021210/2d00d408/attachment.diff>