I’m ok with before too.
On further thought before/after are misleading, because they are opposite to the painting order. I’d prefer above/below.
Hi,
I think it is not to much work to make 3 functions, like
lv_obj_move_index(obj, index)
lv_obj_move_before/below(obj, obj)
lv_obj_move_after/above(obj, obj)
the first one works for lv_obj_move_before/after() i think.
one thing with namings, we have these lv_obj_move_foreground() and lv_obj_move_background() functions that will move items in a list to the bottom or top.
it is a little strange for the user that lv_obj_move_down() will move in the direction of lv_obj_move_foreground() 
we must be a little careful with lv_obj_move_index()
for example
obj0 - 0
obj1 - 1
obj2 - 2
obj3 - 3
obj4 - 4
lv_obj_move_index(obj3, 1) is easy (moving to top), but with
lv_obj_move_index(obj3, 4) we must decide if we first remove the item from the list (scrolling next items up) if we accept 4 as the index in the current list.
ps I’m happy to create them when the names and functionalities are defined 
Hi, maybe i was a little overenthusiastic indeed, swapping objects between different parents will probably never happen. moving objects to an other index or before/after an other object will be enough (and maybe swapping two objects in a list)
I agree to add this limitation. If parent change is required the user can call lv_obj_set_parent() first.
Great, thank you! Let’s figure out the names and the API:
So we are talking about these functions:
- move to index
- move after
- move before: do we need both after and before?
- to foreground: do we really need it? E.g.
move before(parent, NULL)can do the same. - to background: do we really need it? E.g.
move after(parent, NULL)can do the same.
Slides on Google drive uses these names:
What do you think about it?
We can change any of the current functions because it’s easy to provide wrappers for backward compatibility.
Hi, I’m happy with the Google Drive names, “Bring to front” and lv_obj_move_foreground are the same, but we can offer two functions for backwards combability. In the documentation we must make it clear that when used in a list control, ‘background’ means ‘top of the list’ and ‘foreground’ means ‘bottom of the list’.
lv_obj_move_to_index(obj, index) should move an object to the index (before the move action)
lv_obj_move_before(obj, obj) optional (but not difficult)
lv_obj_move_after(obj, obj) optional (but not difficult)
lv_obj_move_to_front(obj) same as lv_obj_move_foreground
lv_obj_move_foreward(obj)
lv_obj_move_backward(obj)
lv_obj_move_to_back(obj) same as lv_obj_move_background
@kisvegabor I think it is for you (or your team) to decide if we offer aliasses for ‘to back’ and ‘background’ alike functions, i think that move_to_index would help a lot but also offering before/after variant is nice for the user.
Greetings, Karijn
It look good and consistent. The question is what can we remove to keep the API as lean and small as possible. It seems all these functions can be a wrapper for lv_obj_move_to_index.
E.g.
lv_obj_move_before(obj, obj) is
lv_obj_move_to_index(obj1, lv_obj_get_child_id(obj2) - 1)
It can be also a decision to keep all of them if we think the “magic” lv_obj_get_child_id/cnt() is not intuitive enough for the users.
@embeddedt, @cjheath what do you think?
I think if we list examples with intuitive names in the documentation (“Bring an object to the front”, “Move an object behind another”), we can just have lv_obj_move_to_index.
We could make inline wrappers with the other names, but remember that the MicroPython binding size is heavily correlated with the total number of function names.
All looks good, but I have two comments:
- “forward” doesn’t have an “e”
- I don’t like the use of “_id” meaning index, because most other places in the software industry use it to mean “identifier” which is unique over all objects - not just in this parent’s child list. If you want to use an abbreviation for “index” it should be"idx".
I’m thinking the same way. We can add some examples event in the comments above the function.
I’ve really used _id in some function names incorrectly. They meant to use index and idx would have been a better abbreviation.
The rule for myself is to abbreviate only if it makes the work at least half long but it’s not true for index and idx. So I propose to change _ids to _index in API functions and use index in the new ones.
ok,
so i just
- add a function lv_obj_move_to_index(obj, index)
- change the function lv_obj_get_child_id(obj) to lv_obj_get_child_index(obj)
forget about
lv_obj_move_before(obj, obj) optional (but not difficult)
lv_obj_move_after(obj, obj) optional (but not difficult)
lv_obj_move_to_front(obj) same as lv_obj_move_foreground
lv_obj_move_foreward(obj)
lv_obj_move_backward(obj)
lv_obj_move_to_back(obj) same as lv_obj_move_background
IMO, yes.
two more questions (sorry for this)
- do i remove the old ( lv_obj_get_child_id(obj)) function or make it [[depricated]]
- is lv_obj_get_index(obj) or lv_obj_get_index_in_parent(obj) a better name that lv_obj_get_child_index(obj), this because we want to get the index from obj
Please refactor it to and add a n inline function for backward compatibility in lv_api_map.h.
Good question. It’d be great to express that the index is related to the position in list of children. But lv_obj_get_child_index really sounds like “get my child’s index”. lv_obj_get_index_in_parent can be good but somehow still strange for me.
“abbreviate only if it makes the word at least half long” - Excellent. We have wide screens and auto-complete, and I’d argue with using full names even more often than that. There is really no good reason for most abbreviations these days.