You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The problem here is really the confusing names we gave the storage.slides.id, here is the deal:
We currently have 2 names which were supposed to describe the same thing, the page number of the presentation: id, currentPageId:
The currentPageId only appears in the context of tldrawAPI, which is the internal API of TLDraw, so we don't really need to worry about it, to my understanding. Moreover, its value is constantly equals to "page" (as far as I could get) which doesn't bring a lot of information for us. One more interesting thing is that we pass it over to parentId (see code previously linked in this paragraph);
The id can be interpreted as the page number of the presentation if it is inside the storage.slides.id as we can see from this snippet
All it does is take the previous id directive from the shapes.svg xml (which would be slide1, for instance) and transform it into 1;
Almost the same happens to the tldraw.json file, which simply is a place to store the annotations, and there we have the number of the page as the key, which is parsed to an id key later on (see code here) and the data which contains all information on the shape drawn (for example id again which in this case would mean id of the annotation).
Describe the solution you'd like
My thoughts on this is that it should be less confusing, as though we wouldn't feel obliged to look into how those things are built in order to get an insight of their meaning.
So we should rename those ids that mean exactly the same thing (the page number) to a more meaningful name, like pageNumber or slideNumber.
For now, I guess a changing in the building process of those data, should be enough (meaning change only bbb-playback). But later we should discuss if the names are meaningful for the record-and-playback in the archiving phase as well.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The problem here is really the confusing names we gave the
storage.slides.id
, here is the deal:We currently have 2 names which were supposed to describe the same thing, the page number of the presentation:
id
,currentPageId
:parentId
(see code previously linked in this paragraph);bbb-playback/src/utils/builder.js
Line 187 in 71cbfdd
Almost the same happens to the
tldraw.json
file, which simply is a place to store the annotations, and there we have the number of the page as the key, which is parsed to anid
key later on (see code here) and the data which contains all information on the shape drawn (for exampleid
again which in this case would mean id of the annotation).Describe the solution you'd like
My thoughts on this is that it should be less confusing, as though we wouldn't feel obliged to look into how those things are built in order to get an insight of their meaning.
So we should rename those ids that mean exactly the same thing (the page number) to a more meaningful name, like
pageNumber
orslideNumber
.For now, I guess a changing in the building process of those data, should be enough (meaning change only
bbb-playback
). But later we should discuss if the names are meaningful for therecord-and-playback
in the archiving phase as well.The text was updated successfully, but these errors were encountered: