Volume OSD (1 Viewer)

joboehl

Retired Team Member
  • Premium Supporter
  • July 30, 2006
    431
    4
    Home Country
    Brazil Brazil
    Hi,

    I was thinking in making the volume OSD available troughout the whole MP experience, but after taking a look at the source code I got a doubt.

    I see that the VolumeHandler sends the message ACTION_SHOW_VOLUME and this message is then treated inside each module (Eg: WINDOSW_TVFULLSCREEN or WINDOWS_FULLSCREEN_VIDEO).

    I don't think it would be practical to code a volumebar renderer in each screen where it could be used, si I tough about moving the ACTION_SHOW_VOLUME to the main WindowsManager (GUIWindowsManager.cs). The point is, I don't know if this (making it specific for each component) was make on purpose or not. If it was, I can then start coding inside each module (musics, menus, etc) the volumear handler. If not, I tough about this approach initially.

    - Split the RenderVolume/Render loginc into a separate module/file.
    - Move the ACTION_SHOW_VOLUME message handling to the main GUIWindowManager.
    - Always direct, indepedent of the screen, to the volume handler functions and decided in there what's needed to do in terms of rendering.


    I was also thinking about some improvements so skins could work a little bit more in terms of the look and feel of the volumebar, but maybe in the future.

    Since I'am realy new to this project, I don't want to break any structure you guys are defining, so would like to understand where should I put this functions if I decided for the wrong places.

    Also, if anyone is already looking at this, I'll step back or help. Up to you guys. :)

    Comments anyone?

    Thanks,
    Julio
     

    Smirnuff

    Portal Pro
    December 7, 2004
    630
    3
    United Kingdom
    The point is, I don't know if this (making it specific for each component) was make on purpose or not. If it was, I can then start coding inside each module (musics, menus, etc) the volumear handler. If not, I tough about this approach initially

    The wait cursor is accessible on an application-wide basis and has worked well (even though it doesn't get a lot of use), you might want to follow the breadcrumb trail that it leaves if you want a bit of a headstart; do a Find in Files 'GUIWaitCursor.' and you'll be on your way.

    I would like to see the volume bar displayed globally :).
     

    mPod

    Portal Pro
    January 26, 2005
    2,084
    3
    Berlin
    Home Country
    Germany Germany
    The wait cursor is accessible on an application-wide basis and has worked well (even though it doesn't get a lot of use)
    It isn't used cause when called from the mainthread it doesn't work, when the mainthread is busy. Unfortunately most MP stuff still runs in the main thread. We'd love to use it in all possible places, but that current implementation of the WaitCursor doesn't make it possible. (Rendering of GUIWaitCursor takes place in the main thread.)

    But there's an easy fix for that: SMIFF, COME BACK AND FIX THAT! :D
     

    Smirnuff

    Portal Pro
    December 7, 2004
    630
    3
    United Kingdom
    when the mainthread is busy

    Tsk tsk thats just excusing the code that existed way before the wait cursor came along for not rewriting itself :p. Code that came after... thread pool, background workers and plain old dedicated threads would provide a suitable fix with the obvious added benefits.

    SMIFF, COME BACK AND FIX THAT!

    Wow I'm sure a pig just flew past my window.
     

    mPod

    Portal Pro
    January 26, 2005
    2,084
    3
    Berlin
    Home Country
    Germany Germany
    Ok, nice answer... :(

    I guess we (or me?) are just too stupid to use it then...

    Let the pigs fly wherever & enjoy watching them...
     

    Users who are viewing this thread

    Top Bottom