[PATCH] ReadWritePart::queryClose()

[David Faure]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 11 December 2002 07:09, John Firebaugh wrote:
> On Sunday 01 December 2002 4:51, you wrote:
Ok now I completely lost track of the discussion :}

> > 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();

This code only says "if there's no url, we need to get one -> show the file dialog".
Nothing about empty vs non-empty documents. But anyway I'm not sure
what was the point behind this :)

> > > >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?

The app is supposed to wait. Note that completed() is only emitted after the
upload is finished. See the last method in part.cpp.

> > 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.

i.e. implementing more logic in the app, rather than in KParts. Generally the point
about KParts was to let it do as much as possible, to avoid code duplication
in the apps..... But I agree that having to cancel the closing on previous parts is a bit bad.

The flag in closeURL means that apps (that do things a bit wrong) could end
up allowing the user to close a modified part without asking for saving, that's
what I don't really like about that solution.

> 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.
Another bad hack :}

Ok, well, if you think it's the best solution in terms of application code, go for it.
It does read like a hack (at the KParts level), but I don't see a better solution right now.

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
Get the latest KOffice - http://download.kde.org/stable/koffice-1.2/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE992gT72KcVAmwbhARAiq3AJwPFtS/5xTnHc846EJCRXI/W5z0vACeLe84
DqK32i6CZTlEnuede5mZESw=
=kY80
-----END PGP SIGNATURE-----