Insert GGB File : Object Naming Convention

lewws shared this idea 2 months ago
Declined

Hi ,

I am using insert ggb file as a possible way to manage bigger projects and also allow collaboration among students in class.


But I notice when inserting, GGB is able to prevent duplicated names, eg

s1 => s1_1 (s1 in 2nd file to be inserted is given new subscript, even no conflict)

or B => B_1 ( ie. a subscript is assigned if object in 2nd file to be inserted has no subscript)

s_1 => s_2 ( if s_1 is in original then s_1 in 2nd file to be inserted is changed)


t_{a} or t_a or t_{p2} => t_1 or t_3 or t_2 (name of objects with alphabetical subscripts in 2nd file given new number subscripts even when there is no duplicates


All objects in original file will remain ..


From this it appears that GGB is using only numerical subscripts of name_subscriptnumber without braces to manage duplicate names.


Is it possible to be more detailed and allow for checking conflict at subscript _{ } level for both numerical and mixed numerical and alphabetical subscript with braces?


If not then, for example t_{A1} in file to be inserted, we will have to name it as tA1.

Otherwise it will become t_1 or t_2 (if conflict with t_1 in original file)>


Let us know if changes can be made?


In any case, insert GGB file is a good idea, as it can allow larger projects to be managed by being broken down to several files, with several users working separately if needed.

Comments (4)

photo
1

I don't know if this will be improved, since it's currently working only in version 5 (sigh), but I'm looping your request to the developers :)

photo
1

Thanks, Simona.

photo
photo
1

Sorry, we won't be making improvements to that

photo
1

Am ok with that..

Current system handling of automatic object during insertion seems good enough.


I brought this request up partly to document the system's handling of _{alphbetical subscripts} so that unsuspecting users with lots of objects named this way will not have wasted time attempting to avoid object naming conflicts this way.

photo
© 2019 International GeoGebra Institute