Another thing that would help a lot would be to allow users to hold specific versions of addons. In general, I want automatic updates enabled, but sometimes I would like to hold a specific addon that I know behaves in a way I don't like.
It would also help in the case that a user makes local changes they don't want overwritten. That's not really a good practice, but users do it all the time, particularly with skins. Usually it's because they really want a given feature that the addon/skin author won't get around to implementing for a while. Could take it one step further and do it like aptitude does, allowing not only indefinite holds, but also temporary holds that release when the next version comes out. I personally think that these changes -- plus the warnings to the user as Jezz and Amet mentioned for "major" updates -- would solve the problem entirely without limiting the skin authors' creativity/freedom. -j On May 24, 2012, at 2:59 AM, Zeljko Ametovic wrote: > if after the roll back user still gets the "old" look and settings than all > is fine IMO. > > I think we should not limit the skins to a guidelines, they will all end up > looking the same we should give authors freedom to do anything they want. > > update process could be made a bit cleverer by only auto-updating maintenance > versions (1.0.x) and asking in case of minor and major bumps. > > this is all coming from someone who hasn't changed the skin since 2009 so > feel free to ignore me > > cheers, > amet > > On Thu, May 24, 2012 at 10:33 AM, Martijn Kaijser > <[email protected]> wrote: > Also agree on this. > > A skin is still a 3rd party app this is installed and maintained outside the > scope of XBMC. > If removing features isn't allowed this is starting look like Apple store... > Users will always complain what ever you do (forum is full of examples). > > I think the idea of Jezz_X is good. > For every major revision pop-up a dialog that tells the user a major update > is available and he might loose some of his customization. > Loosing a skin they like isn't the end of the world cause they are replaced > with something 'simulair' or even better. > Perhaps they complain the first week however after that they probably don't > even remember. Like already said this happens perhaps once a year? > Eden isn't released that long ago so you can still see this as a final > release that belongs to that release and the 2.0 version was more a pre-Eden > skin. > > Limiting skinners (and perhaps scripts) in the creative proces to provide > users with a better and easier to use skin is wrong IMO. > > Small note: > We (the ones in this mail thread) are in no way even representative for the > actual user opinion. > Having a poll about this on the forum wouldn't even be representative as well. > > regards, > Martijn > > > > On Thu, May 24, 2012 at 4:30 AM, Philipp Temminghoff > <[email protected]> wrote: > disagree.. if the skinner thinks he can replace a view / widget / whatever > with something better he should be allowed to do that. and if he thinks a > feature is superfluous, he should also be allowed to remove it. > as ronie said, it´s just annoying to work with a skin if you are not allowed > to make it look / behave how you want it to. > > On May 24, 2012 4:21 AM, Cory Fields <[email protected]> wrote: > Jezz: "No functionality should be removed" only applies to automatic > updates. Neither of your examples fit in that case. > > Maybe I should clarify, this is an example of what I consider to be a > violating change: > > 1. User configures the views they like > 2. Automatic update is applied that removes a view. > 3. User no longer has the view they liked. > > Surely we can all agree that's rude? > > Let's set config and resetting to defaults aside for now and focus on removal. > > Cory > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Xbmc-addons mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbmc-addons > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Xbmc-addons mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbmc-addons > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ > Xbmc-addons mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbmc-addons ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Xbmc-addons mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbmc-addons
