# [Scilab-users] question on graphic children order

14 messages
Open this post in threaded view
|

## [Scilab-users] question on graphic children order

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:

scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data

// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])

// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
0.   0.
1.   1.

After the second plot we get

b  =
0.   0.5
1.   1.5

c  =

0.   0.
1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.

Regards,

Federico Miyara

 Libre de virus. www.avast.com

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## Re: question on graphic children order

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:

scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data

// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])

// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
0.   0.
1.   1.

After the second plot we get

b  =
0.   0.5
1.   1.5

c  =

0.   0.
1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.

Regards,

Federico Miyara

 Libre de virus. www.avast.com

```_______________________________________________
users mailing list
[hidden email]
```

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## Re: question on graphic children order

Stéphane,

Sometimes one just needs to extract some parameter from an entity and indexing is a valid way to access it.

Federico

On 08/04/2019 12:18, Stéphane Mottelet wrote:

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:

scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data

// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])

// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
0.   0.
1.   1.

After the second plot we get

b  =
0.   0.5
1.   1.5

c  =

0.   0.
1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.

Regards,

Federico Miyara

 Libre de virus. www.avast.com

```_______________________________________________
users mailing list
[hidden email]
```

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## Re: question on graphic children order

Le 08/04/2019 à 22:56, Federico Miyara a écrit :

Stéphane,

Sometimes one just needs to extract some parameter from an entity and indexing is a valid way to access it.

So what is your problem since you know that the order of entities is, though not natural, reproductible ? If you really need to recover a deeply hidden entity, use tags and the findobj() function.

S.

Federico

On 08/04/2019 12:18, Stéphane Mottelet wrote:

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:

scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data

// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])

// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
0.   0.
1.   1.

After the second plot we get

b  =
0.   0.5
1.   1.5

c  =

0.   0.
1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.

Regards,

Federico Miyara

 Libre de virus. www.avast.com

```_______________________________________________
users mailing list
[hidden email]
```

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

```_______________________________________________
users mailing list
[hidden email]
```

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## Re: question on graphic children order

I was wondering about it myself for quite some time.
Once recognizing the fact, I just accepted that new entities are placed at the first position.
However, it might be interesting to get some insight of why it is like this....for now I guessed it has to do with how to handle memory.

Philipp

Am Mo., 8. Apr. 2019 um 23:01 Uhr schrieb Stéphane Mottelet <[hidden email]>:

Le 08/04/2019 à 22:56, Federico Miyara a écrit :

Stéphane,

Sometimes one just needs to extract some parameter from an entity and indexing is a valid way to access it.

So what is your problem since you know that the order of entities is, though not natural, reproductible ? If you really need to recover a deeply hidden entity, use tags and the findobj() function.

S.

Federico

On 08/04/2019 12:18, Stéphane Mottelet wrote:

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:

scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data

// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])

// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
0.   0.
1.   1.

After the second plot we get

b  =
0.   0.5
1.   1.5

c  =

0.   0.
1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.

Regards,

Federico Miyara

 Libre de virus. www.avast.com

```_______________________________________________
users mailing list
[hidden email]
```

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

```_______________________________________________
users mailing list
[hidden email]
```
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## Re: question on graphic children order

Hello,

As Stéphane said, using a tag and findobj is a possibility that I use for complex layouts.
Here is another one: build your own vector of handles that you order the way you want:

as=[];
subplot(221)
plot(1,2)
as=[as,gca()]
subplot(222)
plot(1:2,2:3)
as=[as,gca()]
subplot(223)
plot(2*[1:2],2:3)
as=[as,gca()]
subplot(224)
plot(2*[1:2],-[2:3])
as=[as,gca()]
as.foreground=color('gray');
as.background=color('lightgray');
as.thickness=2;
as.font_size=4;

Cheers,

Antoine

Le 09/04/2019 à 08:30, P M a écrit :
I was wondering about it myself for quite some time.
Once recognizing the fact, I just accepted that new entities are placed at the first position.
However, it might be interesting to get some insight of why it is like this....for now I guessed it has to do with how to handle memory.

Philipp

Am Mo., 8. Apr. 2019 um 23:01 Uhr schrieb Stéphane Mottelet <[hidden email]>:

Le 08/04/2019 à 22:56, Federico Miyara a écrit :

Stéphane,

Sometimes one just needs to extract some parameter from an entity and indexing is a valid way to access it.

So what is your problem since you know that the order of entities is, though not natural, reproductible ? If you really need to recover a deeply hidden entity, use tags and the findobj() function.

S.

Federico

On 08/04/2019 12:18, Stéphane Mottelet wrote:

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:

scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data

// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])

// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
0.   0.
1.   1.

After the second plot we get

b  =
0.   0.5
1.   1.5

c  =

0.   0.
1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.

Regards,

Federico Miyara

 Libre de virus. www.avast.com

```_______________________________________________
users mailing list
[hidden email]
```

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

```_______________________________________________
users mailing list
[hidden email]
```
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

```--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

Antoine Monmayrant LAAS - CNRS
7 avenue du Colonel Roche
BP 54200
31031 TOULOUSE Cedex 4
FRANCE

Tel:+33 5 61 33 64 59

email : [hidden email]
permanent email : [hidden email]

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

```

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## Re: question on graphic children order

Antoine,

Thank you for your suggestion. It's a good one, but I still don't know the reason why the index of the current entity is 1 (my question was not really about workarounds but reasons). Stéphane said it was a stack, but as far as I could find, there is no stack structure in Scilab 6. But in any case, if the inclusion of new graphic entities is organized as a stack, the question is why, since actually operations on a stack generally refer to the topmost entity and in this case all entities are accessible via indices.

Regards,

Federico

On 09/04/2019 04:22, Antoine Monmayrant wrote:
Hello,

As Stéphane said, using a tag and findobj is a possibility that I use for complex layouts.
Here is another one: build your own vector of handles that you order the way you want:

as=[];
subplot(221)
plot(1,2)
as=[as,gca()]
subplot(222)
plot(1:2,2:3)
as=[as,gca()]
subplot(223)
plot(2*[1:2],2:3)
as=[as,gca()]
subplot(224)
plot(2*[1:2],-[2:3])
as=[as,gca()]
as.foreground=color('gray');
as.background=color('lightgray');
as.thickness=2;
as.font_size=4;

Cheers,

Antoine

Le 09/04/2019 à 08:30, P M a écrit :
I was wondering about it myself for quite some time.
Once recognizing the fact, I just accepted that new entities are placed at the first position.
However, it might be interesting to get some insight of why it is like this....for now I guessed it has to do with how to handle memory.

Philipp

Am Mo., 8. Apr. 2019 um 23:01 Uhr schrieb Stéphane Mottelet <[hidden email]>:

Le 08/04/2019 à 22:56, Federico Miyara a écrit :

Stéphane,

Sometimes one just needs to extract some parameter from an entity and indexing is a valid way to access it.

So what is your problem since you know that the order of entities is, though not natural, reproductible ? If you really need to recover a deeply hidden entity, use tags and the findobj() function.

S.

Federico

On 08/04/2019 12:18, Stéphane Mottelet wrote:

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:

scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data

// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])

// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
0.   0.
1.   1.

After the second plot we get

b  =
0.   0.5
1.   1.5

c  =

0.   0.
1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.

Regards,

Federico Miyara

 Libre de virus. www.avast.com

```_______________________________________________
users mailing list
[hidden email]
```

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

```_______________________________________________
users mailing list
[hidden email]
```
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

```--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

Antoine Monmayrant LAAS - CNRS
7 avenue du Colonel Roche
BP 54200
31031 TOULOUSE Cedex 4
FRANCE

Tel:+33 5 61 33 64 59

email : [hidden email]
permanent email : [hidden email]

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

```

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## Re: question on graphic children order

Le 10/04/2019 à 01:24, Federico Miyara a écrit :

Antoine,

Thank you for your suggestion. It's a good one, but I still don't know the reason why the index of the current entity is 1 (my question was not really about workarounds but reasons). Stéphane said it was a stack, but as far as I could find, there is no stack structure in Scilab 6.

It was an image. The graphics objects tree is not built at the interpreter level but internally with, at the end, Java objects. In

modules/graphic_objects/src/java/org/scilab/modules/graphic_objects/graphicObject/GraphicObject.java

you can see that the set of children of a graphic object is a (Java) list

/** Child objects list. Known by their UID */
private List <Integer> children;

When a children is added to a graphic object, the the method "addChild" is invoked. In the source you can see

}

Which is coherent with the actual behavior i.e. news children are pushed on the top.

What you would like is simply (without the 0)

}

If I have time I can see if it breaks other things, but I am almost sure that it will...

S.

On 09/04/2019 04:22, Antoine Monmayrant wrote:
Hello,

As Stéphane said, using a tag and findobj is a possibility that I use for complex layouts.
Here is another one: build your own vector of handles that you order the way you want:

as=[];
subplot(221)
plot(1,2)
as=[as,gca()]
subplot(222)
plot(1:2,2:3)
as=[as,gca()]
subplot(223)
plot(2*[1:2],2:3)
as=[as,gca()]
subplot(224)
plot(2*[1:2],-[2:3])
as=[as,gca()]
as.foreground=color('gray');
as.background=color('lightgray');
as.thickness=2;
as.font_size=4;

Cheers,

Antoine

Le 09/04/2019 à 08:30, P M a écrit :
I was wondering about it myself for quite some time.
Once recognizing the fact, I just accepted that new entities are placed at the first position.
However, it might be interesting to get some insight of why it is like this....for now I guessed it has to do with how to handle memory.

Philipp

Am Mo., 8. Apr. 2019 um 23:01 Uhr schrieb Stéphane Mottelet <[hidden email]>:

Le 08/04/2019 à 22:56, Federico Miyara a écrit :

Stéphane,

Sometimes one just needs to extract some parameter from an entity and indexing is a valid way to access it.

So what is your problem since you know that the order of entities is, though not natural, reproductible ? If you really need to recover a deeply hidden entity, use tags and the findobj() function.

S.

Federico

On 08/04/2019 12:18, Stéphane Mottelet wrote:

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:

scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data

// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])

// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
0.   0.
1.   1.

After the second plot we get

b  =
0.   0.5
1.   1.5

c  =

0.   0.
1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.

Regards,

Federico Miyara

 Libre de virus. www.avast.com

```_______________________________________________
users mailing list
[hidden email]
```

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

```_______________________________________________
users mailing list
[hidden email]
```
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

```--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

Antoine Monmayrant LAAS - CNRS
7 avenue du Colonel Roche
BP 54200
31031 TOULOUSE Cedex 4
FRANCE

<a class="moz-txt-link-freetext" href="Tel:+33">Tel:+33 5 61 33 64 59

email : [hidden email]
permanent email : [hidden email]

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

```

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

```_______________________________________________
users mailing list
[hidden email]
```

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## Re: question on graphic children order

It works (after the modification in GraphicObject.java)

t=linspace(0,2*%pi,4);
plot(t,sin(t))
plot(t,cos(t),'r')
legend('sin','cos')

--> gca().children(1).children.data
ans  =

0.          0.
2.0943951   0.8660254
4.1887902  -0.8660254
6.2831853  -2.449D-16

--> gca().children(2).children.data
ans  =

0.          1.
2.0943951  -0.5
4.1887902  -0.5
6.2831853   1.

i.e. the first compound is the sine. But it breaks legend() (see attached screenshot).

S.

Le 10/04/2019 à 08:47, Stéphane Mottelet a écrit :

Le 10/04/2019 à 01:24, Federico Miyara a écrit :

Antoine,

Thank you for your suggestion. It's a good one, but I still don't know the reason why the index of the current entity is 1 (my question was not really about workarounds but reasons). Stéphane said it was a stack, but as far as I could find, there is no stack structure in Scilab 6.

It was an image. The graphics objects tree is not built at the interpreter level but internally with, at the end, Java objects. In

modules/graphic_objects/src/java/org/scilab/modules/graphic_objects/graphicObject/GraphicObject.java

you can see that the set of children of a graphic object is a (Java) list

/** Child objects list. Known by their UID */
private List <Integer> children;

When a children is added to a graphic object, the the method "addChild" is invoked. In the source you can see

}

Which is coherent with the actual behavior i.e. news children are pushed on the top.

What you would like is simply (without the 0)

}

If I have time I can see if it breaks other things, but I am almost sure that it will...

S.

On 09/04/2019 04:22, Antoine Monmayrant wrote:
Hello,

As Stéphane said, using a tag and findobj is a possibility that I use for complex layouts.
Here is another one: build your own vector of handles that you order the way you want:

as=[];
subplot(221)
plot(1,2)
as=[as,gca()]
subplot(222)
plot(1:2,2:3)
as=[as,gca()]
subplot(223)
plot(2*[1:2],2:3)
as=[as,gca()]
subplot(224)
plot(2*[1:2],-[2:3])
as=[as,gca()]
as.foreground=color('gray');
as.background=color('lightgray');
as.thickness=2;
as.font_size=4;

Cheers,

Antoine

Le 09/04/2019 à 08:30, P M a écrit :
I was wondering about it myself for quite some time.
Once recognizing the fact, I just accepted that new entities are placed at the first position.
However, it might be interesting to get some insight of why it is like this....for now I guessed it has to do with how to handle memory.

Philipp

Am Mo., 8. Apr. 2019 um 23:01 Uhr schrieb Stéphane Mottelet <[hidden email]>:

Le 08/04/2019 à 22:56, Federico Miyara a écrit :

Stéphane,

Sometimes one just needs to extract some parameter from an entity and indexing is a valid way to access it.

So what is your problem since you know that the order of entities is, though not natural, reproductible ? If you really need to recover a deeply hidden entity, use tags and the findobj() function.

S.

Federico

On 08/04/2019 12:18, Stéphane Mottelet wrote:

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:

scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data

// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])

// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
0.   0.
1.   1.

After the second plot we get

b  =
0.   0.5
1.   1.5

c  =

0.   0.
1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.

Regards,

Federico Miyara

 Libre de virus. www.avast.com

```_______________________________________________
users mailing list
[hidden email]
```

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

```_______________________________________________
users mailing list
[hidden email]
```
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

```--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

Antoine Monmayrant LAAS - CNRS
7 avenue du Colonel Roche
BP 54200
31031 TOULOUSE Cedex 4
FRANCE

<a class="moz-txt-link-freetext" href="Tel:+33" moz-do-not-send="true">Tel:+33 5 61 33 64 59

email : [hidden email]
permanent email : [hidden email]

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

```

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

```_______________________________________________
users mailing list
[hidden email]
```

```_______________________________________________
users mailing list
[hidden email]
```

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users

Open this post in threaded view
|

## Re: question on graphic children order

In reply to this post by mottelet

Stéphane,

I think I've found a possible explanation fromthe user's point of view: If several entities are successively added and some of their properties need to be modified on the fly, it is easier to use a single instruction that affects the newly added entity instead of having to keep track of the index or the handle of each specific entity. I suppose it is more frequent to modify the most recently added object than a deeply buried one.

Regards,

Federico Miyara

On 10/04/2019 03:47, Stéphane Mottelet wrote:

Le 10/04/2019 à 01:24, Federico Miyara a écrit :

Antoine,

Thank you for your suggestion. It's a good one, but I still don't know the reason why the index of the current entity is 1 (my question was not really about workarounds but reasons). Stéphane said it was a stack, but as far as I could find, there is no stack structure in Scilab 6.

It was an image. The graphics objects tree is not built at the interpreter level but internally with, at the end, Java objects. In

modules/graphic_objects/src/java/org/scilab/modules/graphic_objects/graphicObject/GraphicObject.java

you can see that the set of children of a graphic object is a (Java) list

/** Child objects list. Known by their UID */
private List <Integer> children;

When a children is added to a graphic object, the the method "addChild" is invoked. In the source you can see

}

Which is coherent with the actual behavior i.e. news children are pushed on the top.

What you would like is simply (without the 0)

}

If I have time I can see if it breaks other things, but I am almost sure that it will...

S.

On 09/04/2019 04:22, Antoine Monmayrant wrote:
Hello,

As Stéphane said, using a tag and findobj is a possibility that I use for complex layouts.
Here is another one: build your own vector of handles that you order the way you want:

as=[];
subplot(221)
plot(1,2)
as=[as,gca()]
subplot(222)
plot(1:2,2:3)
as=[as,gca()]
subplot(223)
plot(2*[1:2],2:3)
as=[as,gca()]
subplot(224)
plot(2*[1:2],-[2:3])
as=[as,gca()]
as.foreground=color('gray');
as.background=color('lightgray');
as.thickness=2;
as.font_size=4;

Cheers,

Antoine

Le 09/04/2019 à 08:30, P M a écrit :
I was wondering about it myself for quite some time.
Once recognizing the fact, I just accepted that new entities are placed at the first position.
However, it might be interesting to get some insight of why it is like this....for now I guessed it has to do with how to handle memory.

Philipp

Am Mo., 8. Apr. 2019 um 23:01 Uhr schrieb Stéphane Mottelet <[hidden email]>:

Le 08/04/2019 à 22:56, Federico Miyara a écrit :

Stéphane,

Sometimes one just needs to extract some parameter from an entity and indexing is a valid way to access it.

So what is your problem since you know that the order of entities is, though not natural, reproductible ? If you really need to recover a deeply hidden entity, use tags and the findobj() function.

S.

Federico

On 08/04/2019 12:18, Stéphane Mottelet wrote:

Hello,

Le 07/04/2019 à 10:13, Federico Miyara a écrit :

Dear all,

I would like to know if there is a reason for the fact that whenever new graphic objects are added to an axes, the last one that has been created is always the one with index 1 instead of n+1 (where n is the number of objects prior to new one).

Example:

scf(1)
clf(1)

// Plot a simple two-point graph
plot2d([0, 1], [0, 1])
ax = gca()

// Colect plotted data
a = ax.children(1).children.data

// Plot a simple two-point graph
plot2d([0, 1],[0.5, 1.5])

// Colect plotted data corresponding to index 1
b
= ax.children(1).children.data

// Colect plotted data corresponding to index 2
c
= ax.children(2).children.data

After the first plot we get

a  =
0.   0.
1.   1.

After the second plot we get

b  =
0.   0.5
1.   1.5

c  =

0.   0.
1.   1.

I would expect that b = a, i.e, once a children object has been created on the axes, it would be reasonable that its index were kept constant. The current behavior is as if each new object were inserted in the structure before the previous one instead of after it.

I would say that the set of children is a stack, i.e. each new child is "pushed" on top. Anyway, relying on child order seems, to me, a bad idea. For example, legend takes as (optional) first argument an array of handles, and not an array of child numbers.

S.

Regards,

Federico Miyara

 Libre de virus. www.avast.com

```_______________________________________________
users mailing list
[hidden email]
```

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

```_______________________________________________
users mailing list
[hidden email]
```
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

```--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

Antoine Monmayrant LAAS - CNRS
7 avenue du Colonel Roche
BP 54200
31031 TOULOUSE Cedex 4
FRANCE

<a moz-do-not-send="true" class="moz-txt-link-freetext" href="Tel:+33">Tel:+33 5 61 33 64 59

email : [hidden email]
permanent email : [hidden email]

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

```

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

```_______________________________________________
users mailing list
[hidden email]
```

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## Re: question on graphic children order

 Le 10/04/2019 à 18:05, Federico Miyara a écrit : Stéphane, Thank you for your insight. I think I've found a possible explanation fromthe user's point of view: If several entities are successively added and some of their properties need to be modified on the fly, it is easier to use a single instruction that affects the newly added entity instead of having to keep track of the index or the handle of each specific entity. I suppose it is more frequent to modify the most recently added object than a deeply buried one. I don't think it is the reason (if there is any true reason). It is equally easy to get the handle with A...children(\$) A...children(1) gce() Thanks for your persistent will to know why, for things that are actually not the most handy, even if after years we are compelled to do with them. To have fresh observers and comenters is often interesting. To have new contributors as well. After the first interesting Stéphane's attempt, i am also afraid that changing the order now would break a lot of code. However, IMO it would be worthwhile to try, and see how many tests this change breaks. Many graphical tests are interactive, that requires more manpower (because these tests have no "automatic" validation/invalidation. A human must see how graphics are rendered and say "the test passes, or fails") But this is easy to do, and subscribers to this list could contribute. Samuel _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## Re: question on graphic children order

Samuel,

I would like to contribute somehow, but for the moment I don't know anything about Java and very little about C or C++. I could test code if it is in a version ready to install (I don't know how to compile) and if there is some protocol or guidelines to how to perform tests.

I find more likely for me to contribute Scilab functions written using the available functions and operators, or try to improve help pages.

Regards,

Federico

On 10/04/2019 13:28, Samuel Gougeon wrote:
Le 10/04/2019 à 18:05, Federico Miyara a écrit :

Stéphane,

I think I've found a possible explanation fromthe user's point of view: If several entities are successively added and some of their properties need to be modified on the fly, it is easier to use a single instruction that affects the newly added entity instead of having to keep track of the index or the handle of each specific entity. I suppose it is more frequent to modify the most recently added object than a deeply buried one.

I don't think it is the reason (if there is any true reason). It is equally easy to get the handle with
A...children(\$)
A...children(1)
gce()

Thanks for your persistent will to know why, for things that are actually not the most handy, even if after years we are compelled to do with them.
To have fresh observers and comenters is often interesting. To have new contributors as well.

After the first interesting Stéphane's attempt, i am also afraid that changing the order now would break a lot of code.
However, IMO it would be worthwhile to try, and see how many tests this change breaks.
Many graphical tests are interactive, that requires more manpower (because these tests have no "automatic" validation/invalidation. A human must see how graphics are rendered and say "the test passes, or fails")
But this is easy to do, and subscribers to this list could contribute.

Samuel

```_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
```

 Libre de virus. www.avast.com

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users