Status of the libkdeedu API

[Aleix Pol]

On Sat, Jun 21, 2014 at 2:55 PM, Inge Wallin <inge at lysator.liu.se> wrote:

>  On Saturday, June 21, 2014 05:31:18 Andreas Xavier wrote:
>
> > I am wondering about the status of libkdeedu and its interface. May I add
>
> > some functions and enums to KEduVocDoument?
>
> >
>
> > In particular I started working on a patch for
>
> >
>
> > https://bugs.kde.org/show_bug.cgi?id=240552
>
> >
>
> > Bug 240552 - Second parley process cancels out changes in language file
> when
>
> > closing
>
> >
>
> > The patch
>
> >
>
> > https://git.reviewboard.kde.org/r/118686/
>
> >
>
> > uses KAutoSaveFile to lock the vocdoc and prevent overwriting the file.
>
> > However, the patch is incomplete because Parley has no useful way to
> repond
>
> > when the file cannot be opened. I would like to give the user the option
>
> > to steal the lock and forcefully open/save the file. So I need to create
> a
>
> > function to open/save/saveAs to a locked file.
>
> >
>
> >
>
> > I have read the binary compatibility article.
>
> >
>
> >
> http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
>
> >
>
> > I think that something like the following new member functions and enums
> are
>
> > acceptable.
>
> >
>
> > enum ErrorCode {
>
> > NoError = 0,
>
> > Unknown,
>
> > InvalidXml,
>
> > FileTypeUnknown,
>
> > FileCannotWrite,
>
> > FileWriterFailed,
>
> > FileCannotRead,
>
> > FileReaderFailed,
>
> > FileDoesNotExist,
>
> > FileIsLocked //<******* NEW
>
> > };
>
> >
>
> > //********** All New *************
>
> > enum LockingBehavior {
>
> > RespectLock =0,
>
> > ForceLock
>
> > };
>
> >
>
> > void close(); // <*************** NEW
>
> >
>
> >
>
> > int open(const QUrl & url, LockingBehavior lb); //** Merge this with open
>
> > on API change ^^^^^^^^^
>
> > // NEW param
>
> >
>
> > int saveAs( const KUrl & url, FileType ft, const QString & generator ,
>
> > LockingBehavior lb); //** Merge this with saveAs when the API changes //
>
> >
>
> > ^^^^^^^^^^^^^^^^ //
>
> > NEW param
>
>
>
> These two last ones would be problems and in violation of the binary
> compatibility policy... except that Jeremys patch from KUrl to QUrl was
> much more intrusive and did get ok'ed.
>
>
>
> So I think that we can safely say that binary compatibility is already out
> the door which makes your changes ok.
>
>
>
> BUT: Note that there are many more programs than Parley which use
> keduvocdocument. So you need to make sure that all of them still build.
>
>
>
> -Inge
>
>
>
> _______________________________________________
> kde-edu mailing list
> kde-edu at mail.kde.org
> https://mail.kde.org/mailman/listinfo/kde-edu
>
>
Jeremy's KUrl patch went to the frameworks branch.

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20140623/9d3b502a/attachment-0002.html>