KParts::ReadWritePart::closeURL ()

David Faure david at mandrakesoft.com
Fri May 24 23:40:18 BST 2002


On Saturday 25 May 2002 00:27, Christoph Cullmann wrote:
> On Saturday 25 May 2002 00:19, David Faure wrote:
> > On Saturday 25 May 2002 00:10, Christoph Cullmann wrote:
> > > On Friday 24 May 2002 23:04, David Faure wrote:
> > > > On Friday 24 May 2002 22:37, Christoph Cullmann wrote:
> > > > > Would be nice to get this behaviour in the kpart lib, too ;)
> > > >
> > > > Yes. I approved and provided the code, can you integrate and test? ;)
> > >
> > > But should that code go into saveAs ? not in closeURL ?
> >
> > Err, of course it's for saveAs...
> > When closeURL saves to the same URL (I open /tmp/blah, and then
> > close, it asks for saving -> if yes, it will save to /tmp/blah of course),
> > then it's _normal_ that the dest file is already there. That's quite normal
> > when working on a file. Only saveAs must warn, when the user chooses
> > an existing file from KFileDialog.
> But than the part has no chance to re-ask for an other file, or I am wrong, as 
> saveURL should return simply false if the given url can't be used, or ?

Ah, now I see. It's not saveAs which has the KFileDialog, but closeURL.
Then indeed the while() loop like the one I posted must be in closeURL
 - or better, in a separate method called by closeURL so that the code
remains maintainable. I would make that 
bool ReadWritePart::saveAs()
so that this new method can be called by the application's "save as" action.
Then closeURL can call saveAs() instead of its current code (lines 462-468).

-- 
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/
KDE, Making The Future of Computing Available Today





More information about the kde-core-devel mailing list