[Blackbolt]

hostility? i told you straight up why i think this is a bad idea.


you however make this into a general thing about us not listening to/wanting new features



who's negative and hostile again? you can't seem to stand the fact that i criticize the feature you suggest.

I personally didn't suggest the feature, Equinox did. I don't care how this feature is done, whether its python or built-in, but Equinox really thought this was a good idea and it seems a few others do too. So why shoot it down so easily.

The hostility I mention is this: 'whatever, take the oh-i'm-so-offended-and-the-victim-of-your-cruelness-routine, i don't care one bit'. How is that constructive?

[EqUiNoX]

What i think the issue is here is that you may feel its a bad idea but surely some positive feedback can be given to make it something you would be happy with.

If you feel it would cause xbmc to freeze, we could background thread it.

If you feel problems would occur if location not available, trap the exeption and return a blank string.

So much could be suggested to make things positive.

[spiff]

you got that after your "constructive" whine. i didn't start, i just pointed out that you can whine all you want, it doesn't change anything.

anyways, i totally agree this discussion is anything but constructive so let's just leave it.

if you want to hear my take on it; this needs to be formalized. if we want skin news support, we need to support it natively in some form. and we should definitely NOT be reading xml instructions from the web without any way checking exactly what will be done prior to dl'ing the data (i.e. the xml should sit local, just the data should be read from elsewhere). one way to format such data is through rss. there are builtins to force reloading the rss xml's, maybe we could use some reserved set id and allow a rss.xml in the skin.

[Blackbolt]

And Team XBMC didn't give you that, spiff did that why under his nick on the forum it says "Grumpy Bastard Developer" the views of one are not always the views of the whole team people are allowed personal opinions

I appreciate that Jezz mate, but on the XBMC.org forums, when a developer says something like that, it gives me the impression as a user that that is what everyone at the team must be feeling. As if anyone in the team I work with, if they said anything on the forum negative, they know they're representing all of us when they do.

Anyway I appreciate that spiff is a bastard, err grumpy bastard and this is his usual string of converse, but in the same vain, it gives me every right to get annoyed when spoken to like that.

[Blackbolt]

you got that after your "constructive" whine. i didn't start, i just pointed out that you can whine all you want, it doesn't change anything.

anyways, i totally agree this discussion is anything but constructive so let's just leave it.

if you want to hear my take on it; this needs to be formalized. if we want skin news support, we need to support it natively in some form. and we should definitely NOT be reading xml instructions from the web without any way checking exactly what will be done prior to dl'ing the data (i.e. the xml should sit local, just the data should be read from elsewhere). one way to format such data is through rss. there are builtins to force reloading the rss xml's, maybe we could use some reserved set it and allow a rss.xml in the skin.

Cheers, thats all's I was after and I am sure Equinox was too, some feedback that we can work from.

[Jezz_X]

Your taking this too personally. The final say on if this patch makes it way in has not yet been decided. In the end it will come down to if jmarshall thinks the patch is good enough quality and has a decent use (aside from adverts).

Not every patch or request gets added (go look at xbmc.org/trac) back in the mc360 days as you said we were very lucky that the stuff we requested got added. You also seem to forget that many of Equinox's patches and requests have allready made it in over the last few months. So if one doesn't get added or takes months to get added proper you really need to accept it as the one that got away and move on or try to make it better so it does get added.

EDIT: HEH 3 posts since I typed this

[Blackbolt]

Your taking this too personally. The final say on if this patch makes it way in has not yet been decided. In the end it will come down to if jmarshall thinks the patch is good enough quality and has a decent use (aside from adverts).

Not every patch or request gets added (go look at xbmc.org/trac) back in the mc360 days as you said we were very lucky that the stuff we requested got added. You also seem to forget that many of Equinox's patches and requests have allready made it in over the last few months. So if one doesn't get added or takes months to get added proper you really need to accept it as the one that got away and move on or try to make it better so it does get added.

EDIT: HEH 3 posts since I typed this

I appreciate that not everything can make it into XBMC, I honestly do and I am not selfish or egotistical enough to think that everything pete does should be included. The only thing that has annoyed me really is that there wasn't much constructive criticism on the idea. It felt like it was simple just shot down every step of the way with no real help.

I will try not to get so fed up in future though. Maybe I just care too much about XBMC as I spend such a large amount of my free time working with it.

[EqUiNoX]

I would like to point out the readstring method does not download any xml data as i deviated from that due to the worries in the ticket I had created and am pretty sure that is clear from the start of the thread.

See http://trac.xbmc.org/ticket/7257

As you may see rather than working in a include style it is now just a label (info tag) property so is only a string...

<control type="label">
<posx>0</posx>
<posy>0</posy>
<width>1000</width>
<height>90</height>
<font>Default</font>
<align>center</align>
<info>readstring( http://www.teamblackbolt.co.uk/a.txt)</info>
</control>

As you say a rss.xml in the skin would also be great and I had previously created this thread for the original ideas... http://www.xbmc.org/forum/showthread.php?t=58452

I think the readstring method is way better and more flexible than the include method i had done.

[spiff]

AAH. my poo for not reading closely enough. that isn't all that nasty, although it has ads written all over it.

okay, my main issue with this would be freezing while we waiting for the label. we would need some kind of async grabbing with a placeholder string. in addition, since info labels are pull, we'd need some kind of cache for this. afaik we only have a bool cache in the info manager.

[EqUiNoX]

are you able to point me to some code snippets regarding doing things in a thread and the caching side of things. I am using "ConditionalStringParameter" to get the label to be passed thru altho that works i understand there is a better method but not sure what?

Like you i dont like the idea of adverts and this is not my intention and hopefully not anyone elses in the future. Im sure if anyone intended in doing it would of done it by now using python. Maybe some kind addition to the license agreement could stop that?

[spiff]

you can't tag on conditions to gpl'd software

hmm, what do use as an example. i guess the guilargetexturemanager.cpp is the best one.
in particular the usage of CJobManager.
for the cache see the m_persistentBoolCache stuff in GUIInfomanager.h/cpp

[Blackbolt]

are you able to point me to some code snippets regarding doing things in a thread and the caching side of things. I am using "ConditionalStringParameter" to get the label to be passed thru altho that works i understand there is a better method but not sure what?

Like you i dont like the idea of adverts and this is not my intention and hopefully not anyone elses in the future. Im sure if anyone intended in doing it would of done it by now using python. Maybe some kind addition to the license agreement could stop that?

I don't think ad's are much of a worry, the beauty is people are not forced into using skins, so they can always choose to use another skin instead. If for instance someone made a skin with a lot of ads, people wouldn't stand for it and use something else.

Our usage for this idea was an updates page within the settings, letting people know updates to the skin and what XBMC where upto etc. Just generally keeping people more upto date, with a new graphic and such.

[AnalogKid]

I don't think ad's are much of a worry, the beauty is people are not forced into using skins, so they can always choose to use another skin instead. If for instance someone made a skin with a lot of ads, people wouldn't stand for it and use something else.

Our usage for this idea was an updates page within the settings, letting people know updates to the skin and what XBMC where upto etc. Just generally keeping people more upto date, with a new graphic and such.

I can see a use for that.
I'd say this though.... maybe a better way to approach it (and I know you didn't create the request in the first place!).... would be to say...

"OK, without designing the solution first, here's the requirement.... we'd like a means of being able to dynamically indicate the existence of a new skin update, and possibly, in the future a means to install the update too!.... what's the best architectural way to build this into XBMC?"


The trouble with little 'one off' hacks (as smart as some of them are), is that most of them do not take a holostic view of the impact...it's quick and dirty and seems to work. You can already see the mess created by Aeon, and all the quite appalling state of fanart / thumbnaming conventions in XBMC... that are almost certainly results of short term thinking and rapid implementation.
Nothing's future proof either, so can't blame everything on fag packet design!

Before you know it... someone's using the trick to place ads, or to detect when you're using the skin (call home?) or initiate a DoS attack.

Always, the best option is to state the problem... then let multiple minds figure the solution.

Apologies for making it look like YOUR issue... it's just that your post prompted me!

[jmarshall]

Now that the thread has settled down (it's nice to live in a timezone where all this hassle is out of the way when one wakes :p), my comments:

The current implementation of readstring if it is to be accepted needs the following done as has already been pointed out in the trac ticket and here:

1. It should accept any file, http or not. Just use the normal virtual filesystem for this.
2. It needs to be backgrounded, and updated at whatever time interval suits. See the BackgroundInfoLoader.cpp stuff for instance, though I shall be cleaning that up to use the job manager as spiff points out.

Those changes would be enough for me to accept the readstring function purely in terms of the code side of things, however, I'm still not convinced this is the best way to go. Given this, I would prefer the discussion to move away from the specifics and more to where the use of this function is.


This request seems to be focusing on providing information to the user that the user themselves hasn't specifically requested. In my view it is not the skins role to provide content to the user - that's the users responsibility. The skin is there to present that content to the user in an attractive and accessible manner. However, in some cases I agree that this may be a useful thing - indeed, we provide that facility with XBMC itself via the rss ticker. I would have thought that supplying skin-based news could occur in a similar manner.

As you know, we've been working on an addons system (tarting up the SVN installer is the idea) which will allow addons such as skins, scripts, plugins, scrapers and the like (and perhaps XBMC itself) to be obtained from within XBMC. This would ofcourse incorporate notifications of updates, changelogs and so on. How this is presented to the user needs discussion, but may in fact cover most of the bases you need. Given that it's centralised, it's something that every skin will get for free - no need for any extra coding on your behalf (other than producing the changelog and pushing the update ofcourse!)

So, under the assumption that we have some sort of an addons manager that does goodness such as telling the user that updates are available, showing them what those updates are and so on, what role does readstring() then play? Is it needed at all, or is it something to be used temporarily until a better system is in place? As I'm sure you're aware, I hate adding anything that I may have to later touch or remove (the first one rules out almost everything...)

Cheers,
Jonathan

[EqUiNoX]

1. It should accept any file, http or not. Just use the normal virtual filesystem for this.
2. It needs to be backgrounded, and updated at whatever time interval suits. See the BackgroundInfoLoader.cpp stuff for instance, though I shall be cleaning that up to use the job manager as spiff points out.

I started to try to use these methods but have hit a brick wall and really could do with a hand on how to implement these. If anyone is willing to volunteer a helping hand it will be greatly appreciated

Thanks