[psypher]

I'm interested in doing some coding for XBMC. While my motives are somewhat selfish (I want some features added ) , who knows where it will take me. As far as my experience/skills set, well all my experience is with Windows development. I've been coding for a very long time in C++ and C#. If anyone wants more details just PM me.

Anyways, I followed the Wiki and got the source through SVN. I know the Wiki can become outdated, so let me know if I'm missing anything. I'm using Visual Studio 2008 Pro. I also have DirectX SDK (Summer 2004) installed. Everything compiles, runs and debugs fine. The only issue I saw was just a lot of warnings. Let me know if that's normal for you guys or if there is something else I need to do.

I guess now I just need to be pointed in the right direction. I'm looking at tackling the video progress bar to allow the mouse to jump to specific points in the video file. Based on some of the code that I saw and what would be required, the progress bar would obviously have to be displayed. I see that sometimes its not. So I guess I need to know if that is controlled by xbmc or the skin. I would also need to be able to know the location/boundary box of the progress bar. Is that even available? If not, how bad are the changes for that?

I kept digging around and found GUIWindowOSD which handles the OSD and saw how it handles the mouse click which triggers the pause action. I modified it to pass a new action I created and in the application OnAction I added the code to handle this new action. To quickly test it I simply checked the CanSeek method in the player interface and then called SeekPercentage with an amount. Amazingly enough it worked the first time So now I guess it's a question of doing it correctly. I implemented the OnMouse method in the SeekBar dialog and disabled the pause in the OSD. How do I get the mouse events enabled in the SeekBar? Also, how do I get the location/area of the progress bar to check the clicked area and calculate the percentage of where to seek to.

[spiff]

hey, self interest is what motivates us all so no reason being ashamed there

that would be a matter of implementing the mouse stuff for the GUIlProgressControl.cpp.
the seek bar is either in GUIDialogSeekbar or in GUIDialogFullscreenInfo. what controls it, uhrr, if the user skips the GUIDialogSeekbar is shown. the GUIDialogFullscreenInfo is a activatewindow from keymap.

[psypher]

Ok, I see the GUIProgressControl. I tried implementing OnMouseClick, but when I try to click on the progress bar of the seek dialog, it doesn't get called. How do I get the OnMouseClick to be called for the progress bar?

And once I get this event to be called, would I create a CGUIMessage and call SendWindowMessage in order to notify the parent, which in this case should be the Seek dialog so I could trigger the seek action?

[spiff]

yes. that is what you need to do. that would only update the drawing though, you need to send a message to the player to make it seek. see how the analog seek works in GUIDialogSeekbar

you need someone else for details (i never dabbled in the guilib domain).

[psypher]

Ok thanks, I still haven't been able to get the mouse click events to work on the progress bar. Hopefully someone experienced with how the events work can let me know what I need to do to get that part working so I can move on. I'm currently stuck.

[Gamester17]

Anyways, I followed the Wiki and got the source through SVN. I know the Wiki can become outdated, so let me know if I'm missing anything. I'm using Visual Studio 2008 Pro. I also have DirectX SDK (Summer 2004) installed. Everything compiles, runs and debugs fine. The only issue I saw was just a lot of warnings. Let me know if that's normal for you guys or if there is something else I need to do.

Which instructions did you follow? You should not need the DirectX SDK at this time as XBMC for Windows currently is OpenGL and SDL only.

So make sure that you compile XBMC from the "linuxport" branch and not from the trunk:
http://wiki.xbmc.org/?title=HOW-TO_compi...ource_code
http://wiki.xbmc.org/?title=Development_Notes
http://wiki.xbmc.org/?title=Developing_XBMC_for_Windows

Yes compiling from the "linuxport" branch and not from the trunk goes for both Windows and Mac OS X as well, (you see the "linuxport" branch have become the mainline development tree for all non-Xbox versions of XBMC, the trunk is only for XBMC on the Xbox).

Looking forward to seeing some patches on trac:
http://trac.xbmc.org

Happy coding!

PS! Send me a PM if you want write access to the wiki so that you can help keep it up to date:
http://wiki.xbmc.org/?title=XBMC_Online_Manual

[CrashX]

Have you updated header file for GUIProgressControl since the default behaviour is not to handle mouse clicks ..

Code:

Update Header file with:
virtual bool OnMouseClick(DWORD dwButton, const CPoint &point);

Update source file with:
bool CGUIProgressControl::OnMouseClick(DWORD dwButton, const CPoint &point)
{
  if (dwButton == MOUSE_LEFT_BUTTON)
  {
        return true;
  }
  return false;
}

This should work as shown in GUIButtonControl.

[WiSo]

Which instructions did you follow? You should not need the DirectX SDK at this time as XBMC for Windows currently is OpenGL and SDL only.

XBMC for Windows uses DirectX for the sound output.

[CrashX]

Just curious, any reason why it doesn't use SDL ? SDL_Mixer ...

[psypher]

Which instructions did you follow? You should not need the DirectX SDK at this time as XBMC for Windows currently is OpenGL and SDL only.

I followed the same instructions from the wiki that you just linked, under the section titled "Compiling XBMC using Visual C++ 2008 Express Edition" which in step #3 says to download DirectX 9.0c.

Can someone review the wiki and confirm that it is correct.

Have you updated header file for GUIProgressControl since the default behaviour is not to handle mouse clicks ..
This should work as shown in GUIButtonControl.

Yes, that is exactly what I did. I looked at the GUIButtonControl to see how it was set up and implemented the same methods for the progress control. When I click on the progress bar in the seek dialog nothing happens. I do know that the mouse click events are working in GUIWindowOSD even when the seek dialog is displayed. I'm thinking that maybe the OSD is somehow keeping the progress bar from getting the click events.

[WiSo]

Just curious, any reason why it doesn't use SDL ? SDL_Mixer ...

Can't tell. This was before my time. Anyhow we're trying to get rid of SDL yet.

Can someone review the wiki and confirm that it is correct

That's what my statement was about.

[psypher]

That's what my statement was about.

Ok greats thanks. Now I just need to get these mouse clicks events working in the right place

[psypher]

While messing with the skin to move and widen the SeekBar, I realized that I was looking at the wrong control earlier. The control that is actually used is the Slider which has all the mouse event handlers, but I have the same issue where they are not being called when I click on the slider control. I did see that the OSD is Modal which will probably cause issues with events in the SeekBar, but I haven't been able to get around it. Right now I've been trying to just get the SeekBar to always show so I can concentrate on its functionality.

[jmarshall]

The slider is what you want, not the progress.

It won't currently operate in DialogSeekbar.xml as-is, due to the modeless nature of that dialog.

However, if you ActivateWindow(DialogSeekbar.xml) from within the skin it should start up modal I think, and thus clicks should be detected. It may then work out of the box.

The trick then is deciding how to handle this in general.

Cheers,
Jonathan

[psypher]

However, if you ActivateWindow(DialogSeekbar.xml) from within the skin it should start up modal I think, and thus clicks should be detected. It may then work out of the box.

Sorry, could you elaborate more on this.

As for trying to get the dialog to start modal I tried to basically replace the OSD code with this Dialog, just to get to the point of having it start modal, but haven't had any luck with that.

But yeah, at some point when it all gets worked out there will definitely be an issue in handling the two seperate dialogs since only one can be modal at a time. Ideally both dialogs/windows should be modeless, but still allow for the mouse events/actions to process. I'll have to look and see where the main processing of the mouse is handled to see what can be done to be able to support multiple dialogs when none are modeless.

Thanks,
Adrian