Status of the libkdeedu API

[Inge Wallin]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20140621/b2b220d1/attachment-0003.html>