[kgraphviewer-devel] KF5 version of kgraphviewer

[Arnold Dumas]

Le 04/08/2014 22:42, Reimar Döffinger a écrit :
> On 04.08.2014, at 22:34, Arnold Dumas <contact at arnolddumas.fr> wrote:
>> Le 04/08/2014 22:17, Reimar Döffinger a écrit :
>>> Hello!
>>> On Mon, Aug 04, 2014 at 10:06:54PM +0200, Arnold Dumas wrote:
>>>> Massif-visualizer is being ported to KF5. As you might know,
>>>> massif-visualizer uses kgraphviewer to show nices graphs.
>>>> At the moment, there is no KF5-based version of kgraphviewer. I'm 
>>>> then
>>>> asking you: is there anybody working on such a port. If no, I'll be 
>>>> glad to
>>>> work on it.
>>> I don't think anyone is, I think we're kind of challenged time-wise
>>> just doing the basic maintenance :( .
>>> And I don't even have any idea what kind of changes that means.
>>> If it means any changes that aren't backwards-compatible I expect
>>> we will want to wait with committing anything to trunk until we made
>>> a proper release - though with git using a branch admittedly 
>>> shouldn't
>>> be an issue really.
>> 
>> Basically a KF5-based version means, based on Qt5 and it's not 
>> backward-compatible.
> 
> That is unfortunate, the few articles I skimmed about it sounded like
> at least the first pass should be perfectly possible in a way that
> works both with Qt4 and Qt5.
> 

You can use if/else cmake macros to have a build system that can either 
be Qt4 or Qt5 based.
IMHO, I don't think it's desired. The frameworks should be only 
Qt5-based.

>> The common practice is to create a "frameworks" branch and then to do 
>> the stuff there. The idea isn't to break master nor to mess up 
>> existing working versions, it's to make this application moving 
>> forward to the KDE future, aka Frameworks 5.
> 
> It just means that until we are ready to drop Qt4 support someone has
> to maintain that branch.
> If you think you have the time for that, great.
> Otherwise having as much as reasonably possible on trunk/master
> reduces the risk of losing work ("losing" as in "merging the branch to
> trunk would be more effort than just re-implementing the changes").

I have enough spare time to maintain the branch.
But I've you've planned to do huge refactorings, it may not be the 
moment to create the branch.

If no big refactoring (or huge feature development) is planned, it will 
just be about merging master in frameworks from time to time.

Any objection or thought?

Thanks

-- 
Arnold Dumas
http://arnolddumas.fr