Hi Krzysztof, That's a quite thorough analysis of the situation! As you may have noticed, the slideshow player has been recently re-modelled. It is now much better (and, I think, a piece of Elisa we can now be proud of). Its API is quite consistent because carefully designed, so I think most of the changes you are proposing ought to be done in the video/audio player to reflect changes in the slideshow player.
Now, until which point it is relevant to try and unify the two players' APIs is another open question. Some methods of the slideshow are for example quite specific to a slideshow and don't really fit in a video/audio player. Any concrete proposal of what should be done, or even a design or proof-of-concept branch are more than welcome! Cheers, Olivier Krzysztof Adamski a écrit : > I've investigated current slideshow player and video player classes > trying to find similarities and differences between their public API. > I've found quite a lot of methods that could be unified between them and > maybe even moved to some base class and shared between all the players > (even future ones). There is a lot of code duplicated between players > and i think it's bad. Anyway, here is the list of methods that are not > slideshow/wideo specific and in my opinion could be shared between > players: > > SLIDESHOW: > set_playlist(self, playlist, picture_index=0): ** 1 > get_current_picture(self): ** 2 > next(self): ** 3 > previous(self): ** 4 > start_slideshow(self, index=None): ** just start? 5 > stop_slideshow(self): ** just stop? 6 > clear_playlist(self): ** - > get_playlist_size(self): ** - > > VIDEO: > set_playlist(self, playable_list_model): ** 1 > get_current_model(self): ** 2 > play_next(self): ** 3 > play_previous(self): ** 4 > play_at_index(self, index): ** 5 > play(self): ** 5 > stop(self): ** 6 > pause(self): ** - > enqueue_to_playlist(self, media_model): ** - > play_model(self, media_model): ** - > > The numbers on the right are mappings between players. Methods with the > same number do almost or exactly the same thing but differs in name. > > So my question is... how about unifying this API?
