Why would you make it compulsory ? Let it optional. A ListGroup does NOT
need a movementTable everytime.
>I guess the fundamental question is does a ListGroup without
>a TokenMovementTable make any sense? You wouldn't be able to
>use move(), which makes some sorts of navigation difficult, but
>most of the main ListGroup functionality is not affected.
cell, and then use setFirstItem or scrollItems to make the items presented
in the cell.
This is very useful in many many many applications and as the ListGroup has
only one cell in this case, I don't see any interest in defining the
MovementTable for it...
>The second point is about FirstItem. The corrigenda proposes
>that with the WrapAround attribute set to true, FirstItem
>should be restricted to the range [1..Length of list], but
>allows any value for non-wrapping lists. Several people
>have commented that allowing out-of-list values under any
>circumstances complicates things, and could causes
>inconsistencies.
>
>Can anyone think of a good reason why FirstItem should be
>allowed out-of-list for non-wrapping lists? The only one I
>can imagine is to allow a list to be constructed off-screen,
>which isn't particularly compelling as we have LockScreen
>already.
I don't think there is any good reason to allow FirstItem to take values
outside the range of items in the ListGroup but this is a Technical change
which may modify the behavior of existing applications so people must be
aware of this change if it occurs. The definition of setFirstItem and
scrollItems also have to be modified because the current definition would
very likely cause confusion.
To me, for instance, the current MHEG-5 standard never said that firstItem
attribute is in the range of [1..listSize], even for WrapAround True, so
this is yet another technical change which will impact application and MHEG
tools. I know some current engines already consider this but I don't agree
with this point of view (even if logical). In this area for instance,
MhegDitor considers that FirstItem could take any integer values and that
the modulo is applied at render time.
This impact the way application are displaying items in cells in case you
add or delete items and the firstItem attribute was outside the items range.
>Lastly, would anyone really object if GetCellItem was changed
>to return an index into the list instead of an ObjectReference,
>to make it consistent with the other ListGroup elementary
>actions? An alternative would be to keep GetCellItem as it
>is, and add a new 'GetCellIndex' action.
In fact, both could be interesting so that's why I have already made both
accessible for authors in MhegDitor authoring tool. Remember that delItem
for instance requires an objectRef, not an index so that getCellItem could
be useful before using delItem. If we had GetCellIndex, OK, great ! I would
be happy because MHEG App description could be more compact in some cases
but everytime I suggested such changes here or there, I was answered that
MHEG-5 has to remain low-level and that it was not needed to add actions
that can yet be done another way in MHEG-5.
In the case of GetCellIndex, you can get it by 3 MHEG elementary actions.
GetFirstItem(ListGroup, CellIndex)
Add(CellIndex, cellNumber)
Substract(CellIndex, 1)
Then of course, you could have to check than the cell is filled with an
item and therefore use a link and additional variables for this...
If MHEG contributors are now ready to add some elementary actions to
MHEG-5, then the really really top most interesting function regarding
ListGroups would rather be to have a PseudoModulo actions that would take
any integer and return its modulo in range [1..modulo].
As a reminder, the current modulo returns something in range
[(-modulo+1)..(modulo-1)] depending on the sign of the integer. This is
absolutely not convenient from an author point of view.
Best regards to all,
__________________________________________________________________
Emmanuel BEUQUE mailto:ebeuque@pratique.fr
MediaServ tel: +33 (0) 2 99 64 35 64
Multimedia consultant & developer fax: +33 (0) 2 99 64 36 65