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

List:       koffice-devel
Subject:    Re: Fwd: Fwd: Rendering of stroke with stroke-width zero
From:       Pierre Stirnweiss <pstirnweiss () googlemail ! com>
Date:       2009-03-25 8:00:35
Message-ID: af76e3dc0903250100n72a5ad40t3ba06f36a86882e4 () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


>
> Should we make such code in a special way so we see that it tries to work
> around a bug in a different odf implementation and the sniplets get easy to
> find? Or should we put that code all into a special class that gets a
> method
> for such fixes. We might end up with a lot of functions but at least all
> the
> code that handels defect odf implementations will be in one place.
>
> What do you think?


If it is possible I think a special class would be much better. If we spread
"work around" code all over the place, it will never really go away because
there is a high chance it will get mixed with non-work-around code or simply
lay there forgotten. Plus, should OOo fix the faulty behaviour, pruning out
the work-around code would be much easier if it is in one known place. But
this mean that if work-around code already exist, it should be moved into
this class straight away (like with shopping list, something not on the list
will be forgotten once in the shop).

Pierre

>
>
> Thorsten
>
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>

[Attachment #5 (text/html)]

<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px \
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Should we \
make such code in a special way so we see that it tries to work<br> around a bug in a \
different odf implementation and the sniplets get easy to<br> find? Or should we put \
that code all into a special class that gets a method<br> for such fixes. We might \
end up with a lot of functions but at least all the<br> code that handels defect odf \
implementations will be in one place.<br> <br>
What do you think?</blockquote><div><br>If it is possible I think a special class \
would be much better. If we spread &quot;work around&quot; code all over the place, \
it will never really go away because there is a high chance it will get mixed with \
non-work-around code or simply lay there forgotten. Plus, should OOo fix the faulty \
behaviour, pruning out the work-around code would be much easier if it is in one \
known place. But this mean that if work-around code already exist, it should be moved \
into this class straight away (like with shopping list, something not on the list \
will be forgotten once in the shop).<br> <br>Pierre<br></div><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"><br> <br>
Thorsten<br>
<br>
_______________________________________________<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> \
</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]