Dnia 2009-07-26, nie o godzinie 04:50 -0700, Lee Jackson pisze: Hi, I'm not a developer either, a contributor rather, but I always like some discussion :)
> Overnight I actually solved most of the problems I was having and had > a first pass at the video controls. Firstly my build issue was due to > 1) my having failed to delete the plug-in cache and cached plugins and > 2) the moovida elisa packages being present on the standard python > path. Removing these from dist-packages got me up and running from a > remote terminal. While 2) was reasonably obvious it would have been > useful to detail to delete the plugin cache within the instructions > somewhere (or maybe it is detailed...). Well, 2) is a known bug and not a trivial one. I don't think 1) did actually matter as when you had the development branch in, the .eggs should not be loaded and thus not matter. > I'd still be interested in whether or not patches sent to this list > would be acceptable...although I can probably go the bzr route now. I'd be best to go the bzr route as it ensures proper quality review. BTW have you read this http://www.moovida.com/ca.pdf ? Without signing that and getting it to Fluendo your work won't be able to make it into Moovida core. > So I was able to have a look at the video controls. In the end, adding > the videobalance filter to the pipeline turned out to be reasonably > trivial. If I understand correctly, the videobalance plugin is using > the gstcolorbalance interface internally...whether this is the most > efficient way of adding this functionality though, I don't know. In > order to get things working I have hooked up the controls much as I > would expect to find them in mplayer i.e. keys 1 and 2 = -+ > brightness; 3,4 = -+ contrast etc. This all works much as I had > expected although I'm not sure about the granularity at this point (I > need to watch more material hehehe). As all Moovida drawables are rendered using OpenGL, I think managing colors there should be more efficient, I'm not sure if it's possible with current pigment, maybe 0.5. This also applies to changing video aspect / zooming which should be possible by modifying the drawable's height and width, making it bigger than the viewport. In pigment 0.5 it will probably be possible to do it in a less hackish way, but that's not going to happen real soon. > Anyways, my point here, assuming adding the videobalance filter into > the pipeline is acceptable, is regarding the interface for this. If I > understand you correctly David you're looking to minimise the number > of controls so that there is as little as possible for the user to > frack up (a good strategy - I use wifey as my usability test subject > and hence the KISS rule is essential *grin*); hence I was thinking of > setting these controls to being dependent upon the "power_user" > configuration setting being enabled. I was also thinking of tying the > following keys into the enhanced player functionality I'm looking to > add: > > 1 = decrease brightness > 2 = increase brightness > 3 = decrease contrast > 4 = increase contrast > 5 = decrease hue > 6 = increase hue > 7 = decrease saturation > 8 = increase saturation > > z = increase zoom > Z = decrease zoom > (alternatively z = toggle zoom) > > a = cycle through aspect ratios > > i = technical video information (aspect ratio, video stream type, > audio stream type, etc) > > Would this be acceptable from a usability standpoint and not interfere > with any roadmaps if I were to submit my changes? The options would be unavailable from a simple remote, I think adding a 'Display controls' glyph as a 'shelf' containing the above options (I'm not sure about i, though) would be acceptable in power user mode. David, have you considered a menu like that? I think it could work similar to the context menu button - when you hover on it for half a second or so the options would appear as a vertical list of rectangular glyphs which would only require pressing right / left to increase / decrease or select available options. If you want I can mock something up and describe what I have in mind. > My last point is also an interface related one - feedback to the user > on current settings. I obviously don't want the video dimmed when the > user adjusts these settings but it would be nice to add a status bar > to give feedback to the user as they adjust the video balance. I've > not looked in detail at how the status bars work - I assume they > aren't tied to dimming (or are they?), would it be acceptable to add a > status bar in the centre of the screen giving feedback on current > levels as they are adjusted? Lastly, would you have any glyphs for > these sort of functions just lying around? David will have to comment on this but I think the volume bar (press up/down when in player) would be a place to start in the case when you do have these additional buttons and not use a menu as I described above (although it could probably work either way if thought out properly - e.g. un-dim the video {or rather hide the player controls} if any of the color-related options are used). Cheers! -- Michał Sawicz <[email protected]>
