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

List:       rocs-devel
Subject:    Re: Rework in core (rocs 2.0?)
From:       Andreas Cord-Landwehr <phoenixx () uni-paderborn ! de>
Date:       2012-03-05 16:30:21
Message-ID: 2053693.sORXbjgN6a () worblehat
[Download RAW message or body]

On Monday 05 March 2012 12:59:19 Wagner Reck wrote:
> Today i see many flaws in the implementation of some itens that need
> to be corrected.
> 
> For instance, i don't remember now, why i'm returning a QLayout* from
> DS plugin (even more, from a const method),
> 
> There is other things that must be changed (like my workaround with
> properties to fetch click position).
> 
> So, what do you think about break BC of rocs core an release a 2.0
> version and try to keep the API stable.

Hi, since librocs is (currently) only an internal library I do not see why BC 
is requested for it. Same holds for API compatibility. But, I am all in for 
aiming a stable 2.0 API for librocs with BC compatibility for point releases. 
Maybe due to the amount of cleanups this cannot be done for the next release 
alongside with KDE SC 4.9, though it is a goal to aim.

Actually, I have myself a quite long list of API changes that I would like to 
perform. This mainly holds for a general cleanup for the API, consistent use 
of method names, documentation for the important parts of the public API, 
maybe changes to the plugin system (Sune suggested to compile the mandatory 
plugins into Rocs like e.g. knotify does...), and maybe some more...
And the same holds for deprecating several of the script functions in favor of 
a new consistent function naming. (maybe deprecate in the next release and 
remove the release after that)

Some of the API cleanup (especially at the GraphDataStructure) I started last 
weekend alongside with updating unit tests. If you do not object, I would like 
to continue with the core DataStructure classes. However, before starting 
those changes I think at least the following must be completed:
* unit tests for loading/saving
* unit tests for the script functions
* unit tests for the remaining data structures (list and tree)
to not break huge parts of Rocs completely. For this could you also merge your 
RootedTree plugin into the main branch (if it is ready) or otherwise into a 
side-branch? This would allow making necessary changes to that plugin when 
changing API.

Greetings,
   Andreas

PS: a very decent text I red to this topic recently: 
http://chaos.troll.no/~shausman/api-design/api-design.pdf
_______________________________________________
Rocs-devel mailing list
Rocs-devel@kde.org
https://mail.kde.org/mailman/listinfo/rocs-devel
[prev in list] [next in list] [prev in thread] [next in thread]