[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 14:05:09
Message-ID: 201009141605.10101.zander () kde ! org
[Download RAW message or body]

On Tuesday 14. September 2010 10.37.47 Boudewijn Rempt wrote:
> By the way, the KOffice community has decided that libraries do not have
> explicit maintainers,right? So talking about "The flake maintainers" is a
> bit weird -- and I am unsure here, but did you mean to imply that if such
> a group would exist, I wouldn't be part of it?

First a quick note; please try to avoid reading more into what I write.
Assume pure intentions, everything will go much easier that way.

On Tuesday 14. September 2010 10.37.47 Boudewijn Rempt wrote:
> > The docs give no indication why there is any need for a canvasController
> > that  is not based on a QWidget. And I can't come up with any.
> 
> Because there are Qt-based widget sets that do not use QWidget, but
> QGraphicsItem. And we want KOffice to go there as well, without using
> QGraphicsProxyWidget (which is notorious for bad performance). So we
> cannot base all our canvas handling on QWidgets. 
> 
> This way, there's the flexibility to use QWidget-based canvases,
> QGraphicsItem-based canvases -- or something else, even. We discussed this
> at the last sprint -- moving away from a hard dependency on QWidget
> everywhere -- and this is the just the first step.

Its fine if you discuss this at a sprint, but without an actual technical 
design (i.e. more than a high level goal) being discussed in a broader group 
of people thats not enough.
My conclusion on how this refactor went and got integrates is that we are 
creating bad surprises for people; even people that were at that meeting may 
not interpret the couple of bullet points in the minutes the same way you do.

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 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?

My point is that this is not maintainable and not sustainable. This segments 
the community (again) and makes the effort to integrate with graphicsview 
better something that community members can't really work on.

I suggest we think about an alternative way to get to this goal, what would 
work for you?
-- 
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]