[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: Review Request: Moving paintBorder function in KWCanvas to
From: Mani N C <maninc () gmail ! com>
Date: 2009-11-18 6:51:30
Message-ID: 9445e5350911172239lf07af47jdb3208f20cba8ac2 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I have already started to implement it. So I guess, I can take the ownership
for creating the new class.
I have created a new class KoFrameBorder under libs/flake directory (I hope
this is the right place) .
Will come up with the implementation soon.
Br,
Mani
On Wed, Nov 18, 2009 at 9:33 AM, Thorsten Zachmann <t.zachmann@zagge.de>wrote:
> On Tue November 17 2009, Inge Wallin wrote:
> > On Tuesday 17 November 2009 14:08:57 Thomas Zander wrote:
> > > On Tuesday 17. November 2009 13.45.42 Inge Wallin wrote:
> > > > On Tuesday 17 November 2009 12:15:30 Thomas Zander wrote:
> > > > > On Tuesday 17. November 2009 11.47.51 Inge Wallin wrote:
> > > > > > > > Frame borders have a different approach; they can't reuse
> this
> > > > > > > > concept due to them being any shape, not just square.
> > > > > >
> > > > > > Looking a bit deeper, I see that you are wrong.
> > > > > >
> > > > > > Section 15.27.14: Border (within 15.27: Frame Formatting
> > > > > > Properties) also point to 15.5.25 just like page, header, footer.
> > > > >
> > > > > How does that make me wrong in pointing out that shapes are able to
> > > > > be non- square?
> > > >
> > > > Actually you was pointing out that frames can have any shape (see
> > > > above). Maybe you were talking about frames in general, but if you
> > > > limit yourself to frames as defined in ODF, then they can only be
> > > > rectangular.
> > >
> > > Aha, I see your point now.
> > >
> > > The ODF concept of "draw:frame" does indeed look a lot like the KWFrame
> > > and has the same name.
> > > They are two different things, though.
> > > Since KOffice2 a KWframe is a wrapper around a KoShape and can contain
> > > more than just a "draw:frame".
> > > I can see how this is confusing, yes :)
> > >
> > > The bottom line really is that in the implementation a header/footer
> uses
> > > the shape borders for its border painting and thats able to be
> > > non-square.
> > >
> > > Naturally you could argue that this is wrong and that we should make
> > > headers/footers be square by definition and thus follow ODF more
> > > properly. I think that argument is wrong, we should not just blindly
> > > follow ODF and instead support it the best we can with the great
> concepts
> > > and technologies we see in Flake.
> >
> > Agreed, but then we have a problem. KoLineBorder is totally inadequate
> > right now. I think that we should have one border concept in KOffice
> that
> > is advanced enough to cover all cases. This one is KoBorder right now
> if
> > we limit ourselves to the border attributes, and probably KoLineBorder
> if
> > we limit ourselves to shapes and curves.
> >
> > How can we combine them? I'll try to take a look at them soon and see if
> I
> > can see a way.
>
> As pointed out by Thomas a new class based on KoShapeBorderModel is the way
> to
> implement a borders that support different types for lines for top/... .
> And
> that is what I have discussed with Mike on IRC. I think he will create that
> shortly.
>
> Thorsten
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>
--
N C Manikanda Prasad
[Attachment #5 (text/html)]
I have already started to implement it. So I guess, I can take the ownership for creating the new class. \
<br>I have created a new class KoFrameBorder under libs/flake directory (I hope this is the right place) \
. <br>Will come up with the implementation soon.<br>
<br>Br,<br>Mani<br><br><div class="gmail_quote">On Wed, Nov 18, 2009 at 9:33 AM, Thorsten Zachmann <span \
dir="ltr"><<a href="mailto:t.zachmann@zagge.de">t.zachmann@zagge.de</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt \
0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Tue November 17 2009, Inge Wallin wrote:<br>
> On Tuesday 17 November 2009 14:08:57 Thomas Zander wrote:<br>
> > On Tuesday 17. November 2009 13.45.42 Inge Wallin wrote:<br>
> > > On Tuesday 17 November 2009 12:15:30 Thomas Zander wrote:<br>
> > > > On Tuesday 17. November 2009 11.47.51 Inge Wallin wrote:<br>
> > > > > > > Frame borders have a different approach; they can't reuse this<br>
> > > > > > > concept due to them being any shape, not just square.<br>
> > > > ><br>
> > > > > Looking a bit deeper, I see that you are wrong.<br>
> > > > ><br>
> > > > > Section 15.27.14: Border (within 15.27: Frame Formatting<br>
> > > > > Properties) also point to 15.5.25 just like page, header, footer.<br>
> > > ><br>
> > > > How does that make me wrong in pointing out that shapes are able to<br>
> > > > be non- square?<br>
> > ><br>
> > > Actually you was pointing out that frames can have any shape (see<br>
> > > above). Maybe you were talking about frames in general, but if you<br>
> > > limit yourself to frames as defined in ODF, then they can only be<br>
> > > rectangular.<br>
> ><br>
> > Aha, I see your point now.<br>
> ><br>
> > The ODF concept of "draw:frame" does indeed look a lot like the KWFrame<br>
> > and has the same name.<br>
> > They are two different things, though.<br>
> > Since KOffice2 a KWframe is a wrapper around a KoShape and can contain<br>
> > more than just a "draw:frame".<br>
> > I can see how this is confusing, yes :)<br>
> ><br>
> > The bottom line really is that in the implementation a header/footer uses<br>
> > the shape borders for its border painting and thats able to be<br>
> > non-square.<br>
> ><br>
> > Naturally you could argue that this is wrong and that we should make<br>
> > headers/footers be square by definition and thus follow ODF more<br>
> > properly. I think that argument is wrong, we should not just blindly<br>
> > follow ODF and instead support it the best we can with the great concepts<br>
> > and technologies we see in Flake.<br>
><br>
> Agreed, but then we have a problem. KoLineBorder is totally inadequate<br>
> right now. I think that we should have one border concept in KOffice that<br>
> is advanced enough to cover all cases. This one is KoBorder right now if<br>
> we limit ourselves to the border attributes, and probably KoLineBorder if<br>
> we limit ourselves to shapes and curves.<br>
><br>
> How can we combine them? I'll try to take a look at them soon and see if I<br>
> can see a way.<br>
<br>
</div></div>As pointed out by Thomas a new class based on KoShapeBorderModel is the way to<br>
implement a borders that support different types for lines for top/... . And<br>
that is what I have discussed with Mike on IRC. I think he will create that<br>
shortly.<br>
<font color="#888888"><br>
Thorsten<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
koffice-devel mailing list<br>
<a href="mailto:koffice-devel@kde.org">koffice-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/koffice-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/koffice-devel</a><br> \
</div></div></blockquote></div><br><br clear="all"><br>-- <br>N C Manikanda Prasad<br><br>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic