[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: End lines patch
From: Jérémy_Lugagne <lugagne.jeremy () gmail ! com>
Date: 2009-11-22 15:26:46
Message-ID: a4dc807e0911220726t24a3eaf5sa3a27b8ba65ab495 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I don't understand how to describe the endings with that enum ? the enum
contains only the type of the ending and the full description are in svg
file ? or ?!
J=E9r=E9my.
2009/11/22 Thomas Zander <zander@kde.org>
> On Sunday 22. November 2009 13.55.49 J=E9r=E9my Lugagne wrote:
> > Hi,
> >
> > Yesterday night, i talked with TZander and CyrilleB about this docker
> (and
> > classes) and for them, the best approach for the endings is : make one
> svg
> > by ending and generate only one QSVGRenderer by SVG file and work on it
> in
> > painting method of the KoLineEnd (or KoMarker now).
>
> Let me write down what I remember fromt he discussion;
>
> the current approach of generating a bytearray with an svg seems a bit od=
d.
>
> The suggestion we came up with is to have an enum on KoPathShape with all
> the
> known (ODF) line endings.
> Then have a setter on KoPathShape for both the begin and end of the line
> using
> that enum.
> Then paint the line ending using QPainter calls in the KoPathShape code.
>
> One of the enum values should represent an external SVG. So the user can
> set
> an svg that will be used as a line-ending.
>
> This means that we get 2 ways of painting line endings; one based on
> QPainter
> and one based on svg.
> And the QPainter one will have to implement all line ending types that OD=
F
> has.
>
> > So, what do you think
> > about this approach ?
> --
> Thomas Zander
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>
[Attachment #5 (text/html)]
I don't understand how to describe the endings with that enum ? the \
enum contains only the type of the ending and the full description are in \
svg file ? or ?!<br><br>Jérémy.<br><br><div class="gmail_quote">2009/11/22 \
Thomas Zander <span dir="ltr"><<a \
href="mailto:zander@kde.org">zander@kde.org</a>></span><br> <blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); \
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Sunday \
22. November 2009 13.55.49 Jérémy Lugagne wrote:<br> > Hi,<br>
><br>
> Yesterday night, i talked with TZander and CyrilleB about this docker \
(and<br> > classes) and for them, the best approach for the endings is : \
make one svg<br> > by ending and generate only one QSVGRenderer by SVG \
file and work on it in<br> > painting method of the KoLineEnd (or \
KoMarker now).<br> <br>
</div>Let me write down what I remember fromt he discussion;<br>
<br>
the current approach of generating a bytearray with an svg seems a bit \
odd.<br> <br>
The suggestion we came up with is to have an enum on KoPathShape with all \
the<br> known (ODF) line endings.<br>
Then have a setter on KoPathShape for both the begin and end of the line \
using<br> that enum.<br>
Then paint the line ending using QPainter calls in the KoPathShape \
code.<br> <br>
One of the enum values should represent an external SVG. So the user can \
set<br> an svg that will be used as a line-ending.<br>
<br>
This means that we get 2 ways of painting line endings; one based on \
QPainter<br> and one based on svg.<br>
And the QPainter one will have to implement all line ending types that \
ODF<br> has.<br>
<div class="im"><br>
> So, what do you think<br>
> about this approach ?<br>
</div>--<br>
<font color="#888888">Thomas Zander<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>
_______________________________________________
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