How to: combine mtvcompress pages (1 Viewer)

[VdR]

I want to combine three pages related to 'mytvcompress' ('mytvcompressmain', 'mytvcompressauto' & 'mytvcompresssettings') onto one page.

The 'main' page is just a menu and the menu buttons all have hyperlinks, so it should be possible to move this menu into one of the other two pages. But, the 'auto' and 'settings' page both have controls that are linked to the code by their ID, and the IDs overlap. Is it possible to bring these controls on the same page?

VdR

 

[Bagal]

Not without changing the code. For instance if you have 2 buttons both with an ID of 10 and you click the second one, what will most likely happen is the code will think you clicked the first one and perform that action which is not what you would have wanted.

 

[VdR]

Thanks for the confirmation. I will have to settle for going from three to two pages for now.

I know nothing about the MP code, so let me ask a dumb question; wouldn't it be beneficial (i.e. much more flexibility) if the IDs for the functions where unique throughout MP?

You would then probably need the possibility to carry IDs over when using an imported 'common. .xml' file (like: define #id.list:50).

VdR

 

[DarkWader]

This brings me to an idea..
To have the lyrics on the same page as the nowplaying..? It should be plenty of room for it, in any skin.

 

[Bagal]

Well, I'm not one of the devs but my answer to that is although it sounds like a good idea, practically it's not because you'd need to centrally manage the list of IDs.
If you were writing a plugin, you'd then need to ask whoever managed the list to allocate you a range of IDs for your plugin and so on, otherwise you could end up with multiple plugins all using the same ID.

I would think that a better idea going forward would be to scrap integer IDs and move to string based ones, so for instance instead of using a screen ID of 5678, it would be 'mypluginname' which is a lot less likely it would be duplicated. Of course this would require a massive amount of work, not only on the MP codebase but all plugins would also need to be updated, so I guess it's unlikely the current system is going to change.

 

[VdR]

Understand what you are saying.

Yet, the strings (labels) are centrally managed right? And, it would be possible to assign a range of IDs to a plug-in (MyFridge gets IDs 1200 through 1299).

Of course the naming you suggest would work too.

And, it would be possible to have MP handle both ID systems together to allow a smooth transfer?

Ignorance can be a blessing ...

VdR

PS
For those who are wondering about the MyFridge plug-in. This plug-in would show a layout of our kitchen refrigerator, showing my wife the standard location for the most used commodities, such as the butter and milk. She could then have a look every time she puts something back and follow the layout. Then I would not have to go through two weeks of food supply every time I need the b*** butter ...

Maybe I should put this on the development requests page?

 

[Bagal]

The string IDs wouldn't need to be centrally managed as it would very unlikely that they wouldn't be unique, the only thing you'd want to do is have a naming guide, so if I was writing a plugin I'd probably use something like the following:

mypluginname

• mypluginname_screen1
  • mypluginname_screen1_button1
  • mypluginname_screen1_button2
• mypluginname_screen2
  • mypluginname_screen2_button1
  • mypluginname_screen2_button2
• mypluginname_screen3
  • etc.

And, it would be possible to have MP handle both ID systems together to allow a smooth transfer?

That would probably be the best way of handling it, yes. You could probably implement the string ID system so that they dynamically get allocated integer IDs when MP starts up, so effectively your still using the same system. This is a simplified view, as you'd need to consider many other things such as how events are handled by the plugin when it doesn't know the integer ID etc......

 

[VdR]

Small update. Even combining two of the three skins doesn't work. There is still an overlap of IDs.

Using the same ID within screens in one and the same plug-in really limits the skinning possibilities and could be easily avoided.

VdR