Xbmcscripts.com scriptbrowser. suggestions?
#16
well i know what you mean. the simpler form of the changlog:
Quote: <changelog>
<change>
<date>1968-03-27</date>
<info>added fancy new logo</info>
<info>updated language file</info>
</change>
<change>
<date>1968-03-27</date>
<info>fixed some bugs</info>
</change>
</changelog>

would save some time but is still extra work for the coder. the benefit is clearly that its much better structured.
best way to go is to make the date and info tag optional imo.

Quote:xbmc revision is a bit pointless since everyone is "assumed" to have latest version anyways

well yes, you should have the latest version, but if the script is very old, will it still work with your copy of xbmc? i think the tag is good.

i finished a first draft version xsd file for the xml which will be used to validate the xml. it places the following restrictions on the xml file:

the tags: name,author,category,description,version,xbmc_revision and execute have to exist and there has to be exactly one of them.

the tag changelog is optional.

category can only be one of a list of predifined ones.
description can have a maximum of 450 characters (just a guess of me should probably be higher)

the revision can have maximum 4 fraction digits (think thats what xbmc uses)

the changelog can either be text or have to as many change tags as wanted in them.

change tags have the tags date and info in them.
date has to be a valid date (yyyy-mm-dd).

version has to be a decimal number.

i'll post the xsd as soon as i have completed and tested it.

please post any comments that you have.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#17
the individual tags does seem like overkill for the changelog.
i cant imagine what use having that resolution would be... what would you do with a changelog but read it?

i like having an xbmc version (cvs date?) as occasionally new functions are exposed in the python and its nice to know what the target is.

though those who download python scripts are also the type to update xbmc frequently i would think (and they also the ones who release bundles with the scripts included).

is an xsd like a dtd? i have some xml experience but not much.
Reply
#18
hi, yes xml schemas are the successors of dtds. see http://www.w3schools.com/schema/schema_intro.asp for more information.

i'm not talking about resolution, i mean revision. this is more or less the same as cvs date but more specific. you can see the revision in the changelog (http://cvs.sourceforge.net/viewcvs.py/xb...ngelog.txt). the latest is 1.1109 for example.

the new system at xbmcscripts.com that i am planning could take advantage of a structured changelog, but like i said lets keep it optional.

here is a diagram of the schema that i have in mind:
Image

you can download the first draft of the xsd and a sample xsl at http://www.inetgmbh.net/xbmcscript.rar

thx for your feedback asteron.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#19
ok so you are defining the xbmc revision as the cvs version of the changelog.txt file.

i think people are more likely to know the date of when their build was updated rather than the revision. unofficial binary distributions are labeled with the date as well and its probably more meaningful to people.

i am fine with a complex format if its optional. i guess with a structured change log you could populate a table or something. might as well add an optional 'type' tag or attribute that can take on values
'fixed', 'removed', 'added', 'changed', 'updated'.
maybe an optional 'author' field in the log for collaborative works.
Reply
#20
you are right, built date is probably the better choice.

i was thinking of the 'type' tag before aswell. but as u can have as many info tags per change as you want you would need one 'type' tag for every info tag.

i intended to have an info tag for every change. for example you could have:

<change>
<date>2005-03-27</date>
<info>updated: xxx</info>
<info>added: yyy</info>
</change>
<change>
<date>2005-01-23</date>
<info>fixed: zzzz</info>
</change>

the best way todo this is probably to put the 'type' and author tag within the info tag.

as in:
<change>
<date>2005-03-27</date>
<info><type>updated</type> xxx</info>
<info><type>added</type> yyy<author>me</author></info>
</change>

the other option is to only allouw one info tag per change tag:

<change>
<date>2005-03-27</date>
<type>updated</type>
<info>xxx</info>
<author>me</author>
</change>
<change>
<date>2005-03-27</date>
<type>added</type>
<info>zzz</info>
</change>

personally i feel the second choice would look nicer, but the first choice is probably faster to type for the coders.

what do u guys think?
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#21
another alternative which i thought of would be:

<change>
<date>2005-03-27</date>
<info><type>updated</type> xxx</info>
<info><type>added</type> yyy</info>
<author>me</author>
</change>

so you have one change tag per entry from an author. i think that's probably the best choice.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#22
<info type="updated">blabla</info> is the "real" way of defining different types in xml as far as i know. but then again, i barely know anything about xml...
xbmcscripts.com administrator
Reply
#23
that is such a quality idea...


if you need help with graphics and such, u can pm me or use my forum...

http://www.caustic-design.com

we will be happy to produce them for you
Reply
#24
putting type as an argument is probably a good idea.
so lets have it this way:

<change>
<date>2005-03-27</date>
<info type="updated">xxx</info>
<info type="added">yyy</info>
<author>me</author>
</change>

author tag and type tags are optional again..
i'll finish a new schema soon and post it here.

edit:
new schema diagram:
Image

new files:
http://www.inetgmbh.net/xbmcscript2.rar

the xsd could probably be cleaned up a bit more but it works for the moment.

also have a look at: http://www.inetgmbh.net/schema/ for more details
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#25
i started to write a module for http://www.xbmcscripts.com to support the xml files and improve the site.
a couple of other tags for the xml came to my mind:

<creationdate>2005-03-27</creationdate>
<copyright>this template is released under the gnu/gpl license</copyright>
<authoremail>xxx@users.sourceforge.net</authoremail>
<authorurl></authorurl>

think those are useful?
thx for ur input
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#26
(enderw @ june 21 2005,11:00 Wrote:i know i wouldn't bother writing a changelog if that was the way to do it. i still think it should be plain text, there's absolutely no reason to make it more complex than neccessary. also, xbmc revision is a bit pointless since everyone is "assumed" to have latest version anyways.
i agree with enderw...

i think the original text field was the optimal solution for the changelog, because it allows you to copy-paste the from your changelog.txt/readme.txt file.
Reply
#27
this looks absolutely amazing! i have been hoping for such a script for ages. i just want to suggest a name. how about just "scripts"?

if it gets both an installer and a launcher function, i bet this will be "the" way to handle scripts on xbmc and thus it earns the name "scripts".

just my 2 øre.
Reply
#28
sorry for the lack of updates. i haven't worked on it for a long time due to various reasons, but i started working on it again tonight.

to be honest i am starting to like the interface, and the progress bar is now working. the status thingy in the corner is also animated and pops in and out depending on status
etc. you'll notice some things in the screen below, eg that description doesn't match list object but that will be fixed...just forgot about it when taking these.

i have no set release date yet as there's lots of testing to do. also most scripts on the site are in rar format so i need to convert these into zip and also make sure all scripts are in their own folders. seeing as there are over 70 scripts on the site and probably 30-40 of them are in rar that can take some time, but i'll get to it soon. the edges aren't shown on a normal tv with overscan, but i'll likely change it so it looks nice on all tvs. now to the screens:

Image
Image
Image
Image
xbmcscripts.com administrator
Reply
#29
nice!
I'm not an expert but I play one at work.
Reply
#30
looks great dude :kickass: now when can i get my grubby hands on it Wink lol
Reply

Logout Mark Read Team Forum Stats Members Help
Xbmcscripts.com scriptbrowser. suggestions?0