[kgraphviewer-devel] Re: Many wishes + will to implement them :-)

[Milian Wolff]

On Sunday 21 November 2010 21:46:09 Marco Poletti wrote:
> 2010/11/21 Milian Wolff <mail at milianw.de>:
> > On Sunday 21 November 2010 19:05:52 Gaël (aka Kleag) wrote:
> >> Le dimanche 21 novembre 2010 18:48:10, vous avez écrit :
> >> > 2010/11/21 Gaël (aka Kleag) <kleag at free.fr>:
> >> > 
> >> > 1)
> >> > Maintain all the methods both in the widget interface and in the
> >> > KPart. (Full source/binary compatibility)
> >> > 
> >> > 2)
> >> > Maintain all the methods in the KPart interface, but freedom to modify
> >> > the widget interface. (May break code using the widget interface)
> >> > 
> >> > 3)
> >> > Never lose any features in both interfaces, but to get the same
> >> > features, user code must be adapted.
> >> > 
> >> > If the answer is 1), the MVC improvement probably can't be implemented
> >> > on the existing classes. I will need to copy&paste the code into
> >> > classes with a different name and then modify it.
> >> > 
> >> > If the answer is 2), I will probably be able to do what I want in the
> >> > existing classes.
> >> > 
> >> > If the answer is 3), I will be sure to do all the changes I have in
> >> > mind.
> >> 
> >> I think it's 3. To my knowledge, only massif-vizualizer and the kdevelop
> >> flowchart plugin use the part and only to display graphs without editing
> >> features. And they know that the API is not stabilized. Milian can
> >>  confirm that I think.
> >> I have also another tool with graph editing features (to edit nlp
> >> syntactic analysis) but it is not public currently and is not actively
> >> developed. So, when I will work on it again I will be able to adapt it
> >> to a new API.
> > 
> > As long as you document the required upgrade path I'm ok with that, I'd
> > also port ControlFlowGraph plugin for KDevelop.
> > 
> > But since both currently use external .dot files, it should work as-is in
> > the future, just a recompile required to care for the BIC changes I'd
> > say.
> 
> Sorry, I don't understand.
> The first paragraph seems to suggest 3), with some documentation of
> the upgrade path.
> 
> The second paragraph seems to suggest 1), and that's radically different.
> You say "just a recompile required".
> Do you mean "follow the upgrade path and then recompile"?

What I meant is that I don't see how the API we currently use is going to be 
affected by what you are trying to do, hence a simple recompile should be 
sufficient on our side to take the ABI changes into account:

- it will still be a KPart afterwards, hence part->openUrl will work as-is
- I don't see how the api for setZoomFactor, setPannerPosition, 
setPannerEnabled,  centerOnNode is going to change

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kgraphviewer-devel/attachments/20101122/dca090a2/attachment.sig