(Thanks)
Now, I guess that all this hermeneutics (absolutely useful in any case
for me) probably dependents on the structural ambiguous semantics of my
post...
So, I try to make an example.
I'm developing graphical musical notation.
I need a finite set of symbols, each one having its properties. eg. a
red circle in a white rect represents something, a red circle alone
represents something other, a blue cross a third thing, a little blue
cross a fourth one and so on.
Conceptually, I would feel comfortable in defining a class for each
symbol, dimensions, positions, smoothing, colors included.
class FirstSymbol:
def __init__(self, dimensions, positions, smoothing, color):
self.dimensions = dimensions
#etc
Then I'd like to paint the objects. As evident, being a symbol I will
have many occurences of it in my project.
(My favorite approach (totally independent from actual PyX design and
implementation) would be to tell the object to stroke itself on a
canvas, passed as an attribute of the object itself.)
This said:
- probably there's a already way to do it
- maybe I put the whole thing in a more obscure way...-)
Best
-a-
On 21 Sep 2006, at 18:21, Joerg Lehmann wrote:
> Hi,
>
> On 21.09.06, Andre Wobst wrote:
>> Strictly speaking the "object" Andrea is talking about is the
>> decorated path, creating a canvas item out of a path and some
>> attributes.
>
>> You could do that by hand, but I don't understand at all
>> why this would change anything. And we do *not* have something like
>> object.color. Nowhere. We just don't have such explicit attributes
>> anywere and we don't want them. This is something which I wanted to
>> say as well.
>>
>>> So I would say the following. Currently the canvas is the PyX way to
>>> "annotate" objects with attributes like
>>>
>>> ap = canvas.canvas(p, attributes)
>>
>> I don't understand this. We have
>>
>> dp = deco.decoratedpath(p, strokepath=..., fillpath=...,
>> styles=..., strokestyles=...,
>> fillstyles=...,
>> ornaments=...)
>>
>> but I think this is something we should not emphasize too much
>> (although it can be used from the outside). And it has nothing to do
>> with a canvas (except that it creates a canvas item out of a
>> mathematical path object). But all this is quite internal stuff. And
>> (at least at the moment) there is no dp.set() method.
>
> Yes, a decorated path is not the right thing to do this kind of things.
> As you said, it's much too low-level to be used by normal users.
> Wrapping things in a canvas seems reasonable though and I don't
> understand your problem with that ;-)
>
> Jörg
>
> -----------------------------------------------------------------------
> --
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> PyX-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/pyx-user
>
>
Andrea Valle
DAMS - Facoltà di Scienze della Formazione
Università degli Studi di Torino
http://www.semiotiche.it/andrea
[EMAIL PROTECTED]
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
PyX-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyx-user
