Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

[Confluence] Addon shortcuts update #1313

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
5 participants
Contributor

classicspam commented Aug 21, 2012

Addon shortcuts should act like going to addons sub-menu and selecting the addon for the particular menu it is assigned to (so that views work properly when an addon has more than 1 provides type).

Contributor

bossanova808 commented Aug 22, 2012

Is this related to: http://forum.xbmc.org/showthread.php?tid=131358 - and/or will it fix this??

Contributor

classicspam commented Aug 22, 2012

It will make using the home menu addon shortcuts operate like running the addon from programs (or the associated addon sub-menu). I will currently argue that the addon shortcuts for the home menu are currently broken for the following reasons:

  1. If a addon has more than 1 provides type (i.e. - Video, Music, Image, Program) then running it from the home window addon shortcut (i.e. calling addon through runaddon) will always default to running the addon in a view which may not be the correct one (i.e. if an addon provides Video, Music and Pictures the view will always be Pictures and not allow one to use the Video/Movie Views such as Media Info List or Music Views...)
  2. Running addons from the home window through addon shortcuts uses the "return" behavior of ActivateWindow which would probably be the wrong behavior to use as most addons need to re-download updated Movie, Episode, Song, etc lists (i.e. most current information, especially if they build their own item lists to display) and just returning to the last window that the user was on completely bypasses this functionality...

@ghost ghost assigned JezzX Sep 4, 2012

@classicspam classicspam [Confluence] Addon shortcuts should act like going to addons sub-menu…
… and selecting the addon for the particular menu it is assigned to (so that views work properly when an addon has more than 1 provides type).
108fadb
Member

JezzX commented Oct 14, 2012

Sorry this took so long ..
I really don't like this because it breaks being able to assign program addons/scripts to the other windows. The issue you speak of is a side effect of addons being able to do more than 1 content type that was changed recently. It forces the addon to run in the wrong window. I have noticed this with the twit.tv addon that it always tends to run in the music window even though its pretty much all video.

@cptspiff you have any idea on how to compensate for this (since you made runaddon) because the whole point of RunAddon was so the skinner does not need to have to think about this kind of stuff and could just run them from anywhere in the skin and not care

Member

jmarshallnz commented Oct 14, 2012

The fix is wrong for scripts I think?

If you know the preferred content type, then the preferred content type could be specified in RunAddon() I guess.

Member

JezzX commented Oct 14, 2012

that works nice for confluence that separates them out in home, but when you get other skins like "Touched" that just has 1 big list of favourite addons it fails because people can set any addon type and I have no idea what one it is meant to be

I really think the only fix here is either

  1. don't let addons be for multiple types, why they are anyway seems silly to me but I guess it cuts down on dupe code if they actually get coded properly (the twit.tv one does not as it shows video feeds in the music sections)

  2. make addons have a default content type that they show in which is probably as easy as setting the correct order in the tag

Member

ronie commented Aug 14, 2013

closing this.

as Jezz_X suggested, this should be fixed elsewhere.

@ronie ronie closed this Aug 14, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment