PDA

View Full Version : Xbmcscripts.com scriptbrowser. suggestions?


EnderW
2005-06-11, 02:24
hi,

it's time to ask people for some help. it will not be about coding at this point. i sorta like doing things on my own, although the final product might suffer. the idea was that people can improve on my code later - that might sound stupid, but co-working on code can be quite the mess too...especially since i come up with how things should be as i code it.

what i really need help for is suggestions for a name and design. the name scriptservice is perhaps not the best, and it was actually more of a random name i thought about when introducing the idea to you. scriptbrowser is one suggestion, but i'd like more.

also, i'd like comments on the design. these are some early suggestions on the installer part:

http://enderw.emutalk.net/suggestion01.png
http://enderw.emutalk.net/suggestion03.png
http://enderw.emutalk.net/suggestion02.png

the bright bar at the bottom is a download progress bar. changes color after status etc and position after progress (doh). the rounded status bar above this will slide in and out when theres activity. is there something that would be crucial to an installer? button help etc will be on it's own screen, activated by whatever button i find left over.

please keep in mind that this is the installer part. i might do that one "completely done" first and release it, as waiting for me to finish the browser part too might take a while.

also note that the theme is far from done. the background will change, as will most other things too i guess ;).


there is also another thing i'd like to know. in the script specifications...i somehow need to know what file to execute when there's more than one .py file. this could be solved by <execute> tags or something like that in the script.xml , or it could be solved by everyone using a standard name on the main .py file, like script.py . the advantage with the first method is that i can write tags to script.xml on scripts that isn't specs compatible, so that it remembers what file it should run even though the scripts doesn't follow the specs. please reply with suggestions...i don't want to make decisions myself without getting some input from the community.

the xml so far:


<info>
* <name>xbmclyrics</name>
* <author>enderw</author>
* <version>1.0</version>
* <updated>05-05-20t15:16:12</updated> #will be written to by script with data from site
* <description>fetches lyrics from the song you are currently listening to. uses lyrc.com.ar as a base. some more information could be here i'm sure, but i can't come up with any at the moment.</description>
* <changelog>xx-xx-xx: added animations on startup and end.</changelog>
* <firstrun>this will be displayed on first run</firstrun>
* <execute>xbmclyrics.py</execute> <---good or not?
</info>

Bernd
2005-06-11, 03:45
looks promising!
as for the name: why not call it "scriptaller" or "scriptstaller" or "scriptomatic"? don't know any better ones. names are always really hard.

as for the xml: i'd prefer the execute tag maybe it should be called "run" or "startup". but "execute" would be ok too.

maybe you should add a version attribute to the info tag. this way you could recognize future versions of the xml file.

i also would recommend four digits for years in dates.

maybe the changelog tag should contain subelements so people can add more than one entry.

cheers
bernd

Tomkun
2005-06-11, 08:04
i don't know if this has been suggested before, but if it has consider it a bump.

i would like for all the common parts that usually require editing in scripts to be placed in a seperate file to avoid repetition and also to allow scripts to work 'instantly' as it were.

i have found in several of my scripts that i have to type in the ip address of my pc or router, or usernames or something similar. would it be possible to get put all these in a seperate file so i would only have to do it once? or even better, get it from xbmc itself... i know that xbmc stores the internet gateway, as well as the pc's ip address in kai etc...

perhaps it's just a dream, but it would be nice.

good luck with the script! since scriptrunner stopped working, i have been waiting for this to come out!!!

EnderW
2005-06-11, 20:31
looks promising!
as for the name: why not call it "scriptaller" or "scriptstaller" or "scriptomatic"? don't know any better ones. names are always really hard.

hmm...no offense, but i somehow don't like them. names are really hard for sure.



as for the xml: i'd prefer the execute tag maybe it should be called "run" or "startup". but "execute" would be ok too.


"run" would be a more straightforward name i guess. i think i will go with that.

maybe you should add a version attribute to the info tag. this way you could recognize future versions of the xml file.


yeah, that's a good suggestion. will do.

i also would recommend four digits for years in dates.


hmm...i actually though i had that already, but obviously i don't. will change i guess unless i find an argument not to.


maybe the changelog tag should contain subelements so people can add more than one entry.

hmm...perhaps a cdata storing a string? i have very little knowlegde about xml so for me suggesting what's best is stupid. i'll look around for some more info.

thanks a lot for the suggestions, i really appreciate it. keep the feedback coming everyone...

tomkun:

i don't think that centralized settings will happen anytime soon. what's more likely is that someone will implement info functions for ip/proxy and whatnot in xbmc. that would be handy.

Nuka1195
2005-06-11, 21:39
'script manager' or 'xbmc extensions manager'

jaga
2005-06-12, 17:03
scriptzilla, scriptmonger, or scriptlink

jiz_king
2005-06-12, 20:31
python-strike
scriptninja
python installation engine (p.i.e.) ..easy as pie etc.
script messiah / python messiah

etc, etc blah, blah...


:verysad:

Asteron
2005-06-13, 01:28
hmmm. that's not too bad of a mockup. the progress bar is a cool idea that seems doable. im going to have to fix up my stuff to get ready for this thing. but a thumbnail would be pretty nice.

names are always tough.
is this script going to be integrated into your script runner one too?

if so maybe you want to call it scripter or xbmcscripts.

Ph03n1x
2005-06-13, 01:37
looks great so far... :kickass:

i have a suggestion though, would it be possible separate the server-side of things so we could choose from a list of mirrors/local hosts, i have a feeling this script will become very popular in the future! :nod:

as for names how about keeping it simple and to the point, something like xbox/xbmc script installer (xsi) sounds good imho.

EnderW
2005-06-13, 16:05
thanks for the suggestions. i have no decided on a name yet, but xbmcscripts is good option. somehow i like scriptninja, but i guess it would be too weird?

sadly things doesn't look as great on tvs as on a pc monitor, and the picture below should give you an idea how the final will look. it looks worse on a tv with overscan, believe me...will have to adjust that.

http://enderw.emutalk.net/screenshot014.png

as for thumbnail support - while i don't get why it's so important, you don't see much out of a thumbnail anyways - would be way more work than i will put into this. the reason is that the system (server-side) i use now doesn't support it easily.

as for mirrors and so on, the idea is that you shouldn't need a mirror. modifying the script for use on other sites wouldn't be hard, and if same xml format is inputted to the script it would be very easy.

the script will feature both a local browser and an installer, but i will finish and release the installer first i believe. can't hold onto this thing forever either...

thanks for the suggestions so far, but i'd love more feedback and suggestions!

-edit-
one more thing, you don't need any info inside the zip for it to work with the installer, but it needs to be inside a folder in the zip. the installer just unzips the zip into the script folder, so a subfolder (scriptname) is required.

Asteron
2005-06-13, 16:35
is it me or is the texture on the spin controls lacking an alpha channel? ??? never noticed that before. probably can't tell on a tv anyway.

the screenshot doesnt look too bad actually :) is that progress bar functional yet? it is really eye-catching.

what do the numbers signify? popularity?

EnderW
2005-06-13, 17:34
is it me or is the texture on the spin controls lacking an alpha channel? * ??? * never noticed that before. *probably can't tell on a tv anyway.

the screenshot doesnt look too bad actually :) *is that progress bar functional yet? *it is really eye-catching.

what do the numbers signify? *popularity?
the progressbar isn't functional yet, struggling a bit with that as i have split things into two files and i need to get the percentage out of the module. i have made the code for it, but somehow it isn't working...have barely tried fixing it though, had more important things i needed to add.

as for the numbers they show what category the file belong in. will of course not be in the final version, it's just for testing purposes :)

DonJ
2005-06-21, 00:05
as enderw and me are planning the new backend we also came up with the idea to include script category in the xml.
if you want to upload the script xbmcscripts.com the category has the be one of our predefined ones (to avoid chaos).
what do you think of the idea?
what categories should there be?

thx for ur feedback

DonJ
2005-06-21, 11:59
hi,
this is my new proposed xml layout which every script should have to contain:

new proposed xml layout:

<xbmcscript>

*<name>xbmclyrics</name>
*<author>enderw</author>
<category>media</category>
<version>1.0</version>
<xbmc_revision>1.1109</xbmc_revision>

<description>fetches lyrics from the song you are currently listening to. uses lyrc.com.ar as a base. some more information could be here i'm sure, but i can't come up with any at the moment.</description>

<execute>xbmclyrics.py</execute>

<changelog>
<change>
<date>
<day>12</day>
<month>11</month>
<year>2004</year>
</date>
<info>added fancy new logo</info>
<info>updated language file</info>
</change>
<change>
<date>
<day>10</day>
<month>11</month>
<year>2004</year>
</date>
<info>fixed bugs</info>
</change>
</changelog>
</xbmcscript>


it features:
- an enhanced changelog,
- category
- xbmc revision the script was designed for (or tested with)
- removed firstrun element: i think the xml isn't the right place for this. if you want to show a popup or something on the firstrun you should solve thise somehow else. this is not a function the majority of scripts need

what do you think? i will work on a xml schema to validate the xmls...
please contribute towards this, as it is an important task to establish some standards for xbmc python scripts.

EnderW
2005-06-21, 13:00
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.

DonJ
2005-06-21, 14:07
well i know what you mean. the simpler form of the changlog:

<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.

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_revi sion 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.

Asteron
2005-06-21, 20:41
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.

DonJ
2005-06-21, 22:03
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/xbmc/xbmc/changelog.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:
http://www.inetgmbh.net/schema.png

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.

Asteron
2005-06-21, 23:34
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.

DonJ
2005-06-22, 08:28
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?

DonJ
2005-06-22, 08:30
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.

EnderW
2005-06-22, 20:01
<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...

idaeus
2005-06-23, 11:34
that is such a quality idea...


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

www.caustic-design.com

we will be happy to produce them for you

DonJ
2005-06-24, 10:21
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:
http://www.inetgmbh.net/schema2.png

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

DonJ
2005-06-27, 11:29
i started to write a module for 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

Phunck
2005-07-05, 12:09
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.

lusken
2005-07-07, 14:57
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.

EnderW
2005-07-17, 04:14
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:

http://enderw.emutalk.net/screens/screenshot001.jpg
http://enderw.emutalk.net/screens/screenshot002.jpg
http://enderw.emutalk.net/screens/screenshot003.jpg
http://enderw.emutalk.net/screens/screenshot004.jpg

Livin
2005-07-17, 09:32
nice!

Kain
2005-07-17, 17:34
looks great dude :kickass: now when can i get my grubby hands on it ;) lol

solexalex
2005-07-18, 22:45
nice !!
what about multilingual ? did you think about it ? did i missed something ?
i would be happy to propose myself for translations needed.

EnderW
2005-07-19, 00:41
sorry, can't really see the need for it. there are 6 buttons (likely 7 when script is done) and i think most people understand what they mean. descriptions can't be translated on serverside and i am absolute certain it would be a mess if they were. thanks for your offer though.

m3tro
2005-07-23, 02:50
this sound just superb.
been waiting for something like this for al long time now.

- to put every script in its own folder is very tidy and smart.
- wish people would stop making their script look for backgrounds and other pictures from the skin-folder, the pictures that belongs to the script belongs in the same folder as the script...
- the main .py file should be named default.py or somthing like that.
- will your script include a local scriptbrowser too?
* *ex. script that lists all default.py found in q:\scripts\ and below....


you get the picture? this would make things a lot easier,
local script browser and xbmcscripts.com downloader should be integrated in xbmc.

:pirate: