Each ui.Element to have a settable index number relative to a view/subview - enhancement

[Phuket2]

Unless I am wrong, there is only one order you can get subviews from a view. In the order in which they where created. For v in v.superview.subviews: Blah, blah...

This is haphazard in the sense it's not implicit. Deletions etc...

But if each item had a writable index number and/or also auto assigned, ui module could support a method like get_left, get right. Meaning it would look at the index number to determine the left or right object.to return. It might be None, it is acceptable.

This could be enhanced further by being able to say for example ui.view get_left(ui.Button) or get_right(ui.View). Meaning Pythonista is keeping track of types also or working it out realtime.

HyperCard and SuperCard did this before. If you set an obj index value to an existing one, it just replaced it and did something with the replacement. I think it just delegated to being the last index. But a predictable result.

I know this can be done dynamic attrs. Not really the point. It's just another way to access of a view/subview in an implicit way and knowing the attr exists.

Very importantly this attr would also be added to the elements in the Designer.

I hope I have articulated this well enough. But I think this enhancement would go a long way to aid in writing code that can produce code driven view/interface views.

[Phuket2]

This should go one step further, as well as index there should be a integer Id number as well for every object. Well in my opinion. The id should be managed by Pythonista, read only.

[cclauss]

??? Every object in Python already has a read-only integer id number that can be accessed via id(<object>).

for x in 'abc':
    print(x, id(x))

[Phuket2]

@cclauss , yes you are right. But it's not a managed Id in the context of ui. Rightly or wrongly, if you create a control in a pyui file, it would receive an id. You would expect that id to be static, not dynamically/created or updated. I understand you make not agree. But really long live Bill Atkinson.

[zrzka]

If this will be supported, I'd recommend to leverage what UIKit already provides:

• UIView tag
• UIView viewWithTag:

[omz]

@zrzka The equivalent of the tag property in the ui module is name. The equivalent of viewWithTag: is some_view['subview_name'].

[zrzka]

@omz yep, that's why I wrote if this will be supported. It probably doesn't make sense to duplicate it with tag.

@Phuket2 happy to close this one as you did request it?

[zrzka]

Works even without designer. You can use subview.name = 'blabla' and later retrieve this view via view['blabla']. Closing.