Put here some ideas for rewriting/ extend the media plugin.
Service Item properties
The following properties should be saved in the related Service Item
Properties of Base Type
Properties of Base Type
Location (file path or device path2))
subtitle (yes/no, language)
Buttons (Left, Right, Up, Down, OK)
Dropdown Fields (Language, Subtitle, Chapter)
Location (path to stream via http,ftp,mms,screen,udp)
were should big files be saved?
define an own folder as media library in the program settings?
allow only relative pathes at the same device as the saved service?
May it is better to save the device path in the program settings
rather in the service item to provide platform cross compatibility
Example for Media Manager
Controls at Service Manager
Same controls as for Controllers, but maybe as Pop up Menu
Controls at Theme Manger
Video Widgets for different Backends
At startup the core should provide Services to add Items to the
Media Manager (currently done)
Displays (Preview Display of the controllers and Live Display)
The plugins should have Items for the following services
Menu Items for Media Manager
Control Toolbars for Controllers
Display Widgets for Displays
Menu Items for Service Manager
Menu Items for Theme Manager
After loading a media in the Media Manager, nothing happening so far.
After send media to preview or live controller, the related plugin can
show appropriate Control items
Now the user can do some settings stuff for the media item(s)
May the related controller preview list widget could show the media
title(s) instead of the clapperboard picture
After this the media could be started or moved to live (or maybe to
Service Manager or as background for current Theme)
In case of a service is opened, there have to be a check started:
is the related player available
is the related path available
1. For providing Meta Infos of media files it is mostly needed to load
a media file and start playing shortly. So there should be an own
(hidden) display widget for all backend apis for the Service Manager.
(This datas are needed for duration of media file.) May it is a good
idea in general, because of when editing the media item in the Service
Manager it would possible helpful to have a litte preview. 2. Where the
media files should be saved (in case of putting it in a service or
1. Future enhancements such as linking songs to audio (backing tracks)
and adding a video background to a theme, should be able to hook into
the media displays without too much effort. Backing tracks would
obviously need a way of pulling in the media controls cleanly. Some of
this may determine how much code is in core and how much is in the media
2. If the media plugin is disabled, OpenLP should still function
perfectly well, so what should happen about the items in #1
3. Plugins should not be accessing core classes/methods directly. I.e.
we don't want a method in a plugin to just call something like
mainwindow.livecontroller.doSomething(). We need a documented proper
api. Signals are usually the preferred method for sending
data/performing actions, but we also need to consider the occasions when
a plugin needs to retrieve data from core.
4. Whether plugins should be adding items to the controller toolbar, or
whether these should be provided by core, and the best way of doing
whichever option we choose.
5. May in general we could use QGraphicsView and QGraphicsScene with
proxyWidgets. So we could easy add more widgets to the display and
control the position via z-index. 5.1 With this it would maybe possible
to use phonon directly for background videos, because of a phonon widget
can give the control to a proxy widget. (unfortunately this doesnt work
for vlc) 5.2 with the scale option of a QGraphicsView we could remove
the usage of screenshots for the preview screen in the preview