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

List:       kwrite-devel
Subject:    Re: RFE: signal prior to saving a file
From:       Paul Giannaros <ceruleanblaze () gmail ! com>
Date:       2007-04-09 23:20:30
Message-ID: 200704100020.30364.ceruleanblaze () gmail ! com
[Download RAW message or body]

On Tuesday 10 April 2007 00:08, Matthew Woehlke wrote:
> Anders Lund wrote:
> > On Monday 09 April 2007, Matthew Woehlke wrote:
> >> Here's a request from kdevelop-devel for KDE4: for VCS integration, we
> >> would like to intercept when a document in a KTextEditor (typically
> >> KATE) is being saved. For aegis in particular, this needs to do two
> >> things: first, issue a VCS command to make the file edit-able, and
> >> second, change the name of the file prior to the save (so the 'save'
> >> really becomes a 'save as'). Other VCS's (e.g. Perforce) just need to do
> >> the 'make edit-able' action. Is this do-able? Does it require changing
> >> something in kdelibs (in which case maybe I should take this to k-c-d)?
> >
> > I can't see why we shouldn't just use SIGNAL/SLOT for this? Simply a
> > signal emitted from the save procedure?
>
> Sounds fine (I didn't imply a signal/slot wasn't enough, did I? :-)), as
> long as it can transmute a 'save' into a 'save as'... aegis (abomination
> though I may personally think it is ;-)) seems to need that. I guess
> passing the url being saved byref (and not const) - probably make a copy
> of the real url so the signal raiser can compare after - would be
> sufficient?

I would advise against passing by reference. It is not the intended use of 
signals/slots -- the whole point is that they are meant to be decoupled. They 
also cannot be easily wrapped by bindings.

>
> >> Also, is there a hook to mark a file not-read-only (e.g. if it was
> >> opened read-only)?
> >
> > In katepart, there is. If it is not exported in KTE, we should do that.
>
> I admit I didn't check, it was just something I thought of while typing
> up the original request. Actually, I see a get for katepart in 3.5 but
> not a set; it's the set (or rather, clear, we would want to make
> something *not* read only) that would be desired. (I didn't check trunk
> though.)
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]