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

List:       koffice-devel
Subject:    Re: flake/canvasController
From:       zander () kde ! org
Date:       2010-09-14 15:04:23
Message-ID: 201009141704.23753.zander () kde ! org
[Download RAW message or body]

On Tuesday 14. September 2010 16.25.26 Cyrille Berger wrote:
> > In KDE we don't work that way; things happen in the open and get
> > developed in the open with much more input from people that have
> > previously been hacking on the same code than was shown here.
> 
> We are a big group of people hacking on the same code, it is difficult to
> get  everyone on board to discuss every issues.

Lets not get into the habit of pulling things into extremes; better to come to 
a middle ground by everyone giving in a little ;)

The extreme happened already; there was no design proposal or code available 
until it was ready for integration. Which was a pretty big amount of code all 
coming in at once.
Now read again that line above about how KDE works and see what it *is* that 
i'm pointing out.
Its not too much to ask to be more open, is it?

> > We now are at a position where we can't change things in Flake because
> > some code that I can't even see, let alone commit to, has the only
> > existing graphicsview based subclass. I mean, seriously?
> 
> Well of course it would be better to have the source code available. But
> that  does not prevent discussion. All I see as objection from you is that
> you don't want to see a QGraphicsView based canvas controller.

I'm sorry, I didn't mean to give the impression I'm against having a 
graphicsview based canvas controller.
I'm not. I'm saying its unhelpful to have it outside of KOffice svn in an 
application that we can't see and have technical decisions based on usecases I 
can't see.  It cuts everyone not 'in the loop' out of the design process.

> Maybe it is
> not what you want to say, in which case, you can give a detail explanation
> of your concern and why the changes are bad, and then Boudewijn will be
> able to address some of your concern and/or explain why they are invalid,
> or why we have to live with some of them because it is the best solutions

The objections I tried to put in my previous mails;
there has been no openness in the design and decision making and there is no 
way to improve the code now by community members because doing so would make 
Boud correctly point out that it broke some other app community members are 
not able to see the sourcecode of.
Thats not open development.

> > My point is that this is not maintainable and not sustainable.
> 
> Prove it. You do realize that this is something that can be said for every 
> commit, that does not make it true. Right now it is your words against 
> Boudewijn and the reviewers's words.

I thought I did; as I wrote that there is no application in KOffice that uses 
graphics view stuff and the only reason we now have 3 classes instead of one 
KoCanvasController is because of classes I can't see nor modify.

Or to prove it more practically;  I think the 'emitFoo' methods are suboptimal 
and want to turn them into a more proper solution. How do you propose I do 
that if half the code I am supposed to touch is not something I can see nor 
modify?
As a hint; telling me that Boud can fix that for me is just proving that its 
not a community maintainable solution anymore.
-- 
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]