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

List:       koffice-devel
Subject:    Re: Page variable support for kopageapp
From:       Thorsten Zachmann <t.zachmann () zagge ! de>
Date:       2009-09-18 3:14:39
Message-ID: 200909180514.39439.t.zachmann () zagge ! de
[Download RAW message or body]

On Thu September 17 2009, Thomas Zander wrote:
> On Thursday 17. September 2009 21.44.41 Thorsten Zachmann wrote:
> > > Its a universal design concept. Model view shows this too.
> > > If I put a string in a model the exact same string will be shown in a
> > > tree or in a list view. Maybe the way its shown is slightly different
> > > (different font, only the first 20 characters) but the actual content
> > > is always the same.
> > > So if you have a different point of view, then I'm afraid you have the
> > >  burden of proof here as you disagree with the core concept of MVC. And
> > > one thing you will have to prove is that its not expensive to do what
> > > you want. You say "no extra code at all". Which is not true. Its only
> > > no extra code for KPresenter. But instead you add extra code for each
> > > and every shape that you want to have showing different. And the amount
> > > of plugins is infinite.
> >
> > Even the proxy shape you introduced for kword uses the same model and
> > sets a different page for a short period so that is not different to what
> > is done by this patch.
> 
> There is an essential difference thats quite important here. It is
> essentially a different shape with its own properties and position. It just
> steals the content from another shape.

There are no own properties for the shapes of the master page on every page 
they are used.

> If I want to show a vector shape but in a different location, or with an
> effect or with a rotation then you can not have the same shape twice. A
>  shape can not have two positions or two rotations. Just like the same
>  shape can't have two contents.
> When the application wants to show a similar-but-different shape it can do
>  so by creating a proxy shape. This will work for all shapes without any
>  code in the shape.

Nothing of that is wanted. I just want to paint the shape.

> Very consistent, with no extra code in a shape plugin.
> 
> Again, reasoning from the perspective that we have only a small amount of
> applications and a lot shapes and hopefully many 3rd party ones too.
> Moving the complexity to the application, out of the shapes, is the only
> sane thing to do.

It is completely wrong in opinion to have spacial code for a shape in the 
application. That just makes the application very hard to maintain. 

Thorsten 
_______________________________________________
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]