[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