bugpyFormex - Bugs: bug #41404, Should .attrib be inherited just...


bug #41404: Should .attrib be inherited just like .prop?

Submitter:  Benedict Verhegghe <bverheg>
Submitted:  Thu 30 Jan 2014 02:04:10 PM UTC
Category:  Rendering Severity:  1 - Wish
Item Group:  Feature request Status:  Ready For Test
Privacy:  Public Assigned to:  bverheg
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup

Thu 16 Jun 2016 08:34:54 PM UTC, comment #4: 

Implemented in 266bd41

All transforms using _set_coords() method will now inherit the attributes.

We could think about adding it to other methods (e.g. select) also.

It could be written a bit nicer if the if we had a setAttrib returning self (like the setProp).

Benedict Verhegghe <bverheg>
Group administrator
Thu 16 Jun 2016 03:09:30 PM UTC, comment #3: 

I tend to agree with this: if the user binds a new name to the transformed object, then he would expect that the new object can be changed independenly. The design of the pyFormex language was purposely done in that way for the geometry of the objects. So we should do the same for the attributes.

This will however mean a lot of copying of attributes. Think about a long chain of transformations with a copy on each step:

G = G.trf1().trf2().trf3().trf4().trf5()...

But the the same holds for the coords, and the attribs will usually be limited.
And, the user can set the attributes after most of the transformations.

So I will go ahead and let the attributes be copied.
I think for now we will only implement it in simple transforms that just do some coordinate transformations.

Benedict Verhegghe <bverheg>
Group administrator
Thu 16 Jun 2016 02:30:50 PM UTC, comment #2: 

I think this is urgent.
I would use make a copy of the attributes:

1) G = G.scale() will overwrite both geometry and attributes
2) GNEW = G.scale(0.5) is creating a new object

In case 2) the following could be a problem:

G.attrib['color'] = 'red'
GNEW = G.scale(0.5)
G.attrib['color'] = 'green'

what is the color of GNEW? The user expects 'red', but I think if we do not make a copy the color will be 'green'

gianluca de santis <gianlucadesi>
Group Member
Wed 15 Jun 2016 06:04:45 PM UTC, comment #1: 

With the .attrib likely to become more popular in pyFormex, and the draw() arguments only being a temporary override of the attributes set on some Geometry, this question becomes urging again.
Suppose a color is set on a Geometry:
G = Geometry().attrib(color=red)
and the Geometry is the drawn in a scaled version:
The color will not be red, but the default (black).
This is likely not what the user expects.

This also means e.g. that the customization of the Triade can not be colored (except by the way of prop color), because the Triade geometry is always scaled in the rendering.

So I think inheritance of .attrib should be implemented.

But should we make a copy, or just use the original set of attributes?

Benedict Verhegghe <bverheg>
Group administrator
Thu 30 Jan 2014 02:04:10 PM UTC, original submission:  

The script in https://savannah.nongnu.org/bugs/?40632#comment4 raises a question: Should the .attrib attribute of Geometry be inherited by the transformed Geometry, just like it is now the case with the .prop attribute?

Currently, as the script illustrates, even a simple transformation like a translation makes the .attrib be lost.
It would be nice to have this inherited, and it does not seem to be difficult to do, if the attribs are just constant rendering values for the object.

But what if the .attrib.color is an array of per-element colors or per-vertex colors and the transformation changes the number of elements? That would need some extra processing. A select operation could just select the appriopriate colors.

If adding the inheritence to Geometry seems simple enough, there will still be a lot of Formex/Mesh methods where .attrib will be lost. A good principle could be to inherit .attrib at all the same places where .prop is inherited.

So what do you think? Good idea?

Benedict Verhegghe <bverheg>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by gianlucadesi (Posted a comment)
  • -email is unavailable- added by bverheg (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-06-16 bverheg StatusNeed Info Ready For Test
        Assigned toNone bverheg

    Back to the top

    Powered by Savane 3.13-04b1.
    Corresponding source code