Here are some note about the design of the media player plugin. Objective: to play media tiddlers that are linked to remote media, that are sequenced via playlists. Non functional considerations: controls must react in real-time, ie they must feel responsive. Play must not be interrupted. Assumption: Tiddlywiki5 should be usable on as many computers as twc, ie not just for the latest (fastest) computers.
tw5 has three devices for widget interactions, the refresh mechanism(RM), widget-tree messages(WM) and invokeActions(IA). WMs operate from a node in the tree towards the root - for a tree with N nodes it takes a max of O(log(N)) operations to send a message from a node to one of its ancestors. At each widget the message is either forward or examined and then possibly forwarded. RM does a depth first transversal of the whole tree and is O(N). In addition each widget recalculates its parameters when visited. IA are applied to only immediate children and are O(1) So IA gives the fastest response, then WM. Up to now user interactions (via buttons etc) result in mainly RM as changes to the ui are mediated by modifying tiddlers, on an atom based notebook there is a perceivable delay between clicking a button and the resultant action. With a mediaplayer application, delays between user actions and results are very noticeable and give a poor user experience. The fastest design for a mediaplayer would be to have all the logic within a single widget. Players are embedded in the dom and respond with dom events. It would be possible to have the dom 'finished playing' events directly trigger logic that would select the next track to play. Such a system would not be very flexible/extendable. It is more flexible to split the media player into logical components and to represent these components are widgets, allow a variable number of players and allowing other elements to be associated with the players (eg text and photos with mp3 tracks), as the user desires. The media play can be split into a sequencer (of a playlist) and players. Players respond to events generated by the sequencer or by user interaction (eg play pause), and generate events, some of which (eg finished) need to be sent to the sequencer. As there is one sequencer and many players, it seems logical to have the players as children of the sequencer. The device that gives the quickest possible inter-widget communication from the sequencer to the players is the IA. (Also, when action widgets are used with the button widget they separate the source of the event from the actions - this is a similar pattern). Likewise the quickest inter-widget comms from the players to the sequencer is given by WM. Players also respond to user input - different players may different controls - (eg fastforwards for video) - having controls as children of the players allow for a natural encapsulation. all comments wellcome! cheers -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywikidev. For more options, visit https://groups.google.com/d/optout.
