[jimk72]

one quick question about the 2.0 skins. once this is complete, how long before more changes are made? at the rate changes are being made now a skin editor is unusable. there is no way to implement the changes in time for usage with xbmc unless they have an older version.

i hate to say it but it seems there may not be any further work on the skin editor after v2.0 as the rate at which changes are made. i do not want the changes to stop though because you guys(xbmc devs) are doing such a great job and adding great features. the problem is the way i load the xml files into the editor is specific to the code and any added tags or controls will not be loaded and saved and thus will be removed rendering the editor useless for any newer versions of skins.

the only thing i can think of is a control editor that will allow you to create a custom control and add tags to it. it would have all the basics like id, posy, posx, description, ect.. and any extras could be added, including textures ect... the problem i am having with this is that there seems to be only about 6 people that have even contacted me or posted about the editor and they were not even all good. so do i take the time to add all the new features to be 2.0 compatible and add a control editor that saves the data in a data file that can be downloaded and be done or just not waste anymore time with it and move on to something that is more usable to the community?

as of now i have had 217 downloads. 2 emails and a couple of replys about it. is anyone even using it? or maybe waiting for the first full release? i have gotten almost no feedback at all.

as far as open source it is built using delphi 7 so if any delphi 7 users are interested in helping please let me know. it would be nice to have input from a fellow delphi coder.

[jmarshall]

i'm not planning any major skin changes post v2.0 for the next wee while. once i have the layout of v2.0 sorted (it won't be till the new year) then i'll let you know.

imo it's an extremely valuable resource - i think the thing that is stopping people who are unfamiliar to xbmc skinning using it is that it takes a little bit to get up and running (textures.xpr the largest hurdle - how are you going on that front?), plus they're waiting for it to be "officially" released i guess. perhaps a small amount of code to auto-fill in the media, font and skin folder locations (assuming they don't already exist) based on the location of the xml file the user first loads would improve the users initial experience?

please do open the sources so that others can work on it. we can host them on our sf site no problem at all.

cheers,
jonathan

[Loto_Bak]

just posting to voice my support and thanks for your time, effort and hard work jimk72. i hope you have time to support your application until the skining structure and features are solidified.

thanks again,
loto

*edit
open source would be cool as well but thats your decision

[KoTiX]

yes, keep working on it !!!
finally we have a pc skinning tool, don't put it in the trash, we were waiting for it for years.
really tnx for your work

[modplug]

please continue working on the skin editor. it's a giant step for xbmc-skinning! great work so far

[los93sol]

another post here to show my support in your efforts to build a skin editor. i've not made any skins myself, but have taken a bit of time to check out what you've done and your app is quite nice, and i agree with everyone else, this is such a valuable tool it would be a shame to see it gone. if you do decide not to continue development, it would still be a huge contribution to open source the app so other developers could have a play at keeping things in working order.

[Livin]

i'm on the support the skin editor side too!

i think we should dump the textures.xpr totally... even jm said in a previous post that it does not speed up the loading much at all.

jm... how about the 2.0 spec not include it?

[jmarshall]

if you use bmps it will be almost as fast (still not as fast though) plus ofcourse you won't have alpha.

textures.xpr is significantly faster with jpeg or pngs. i have code already to extract (which i have given to jimk72, though it's in c++), and changing the injector to be free of the xdk is doable, so i don't really see it as a huge obstacle to skinning at this point. the most complicated bit is getting the xml files right, which is why jimk72's work is so valuable

cheers,
jonathan

[C-Quel]

please! don't dump xpr's they make a huge difference to performance and you can tell especially when you have fr example an rss feed running. thus being one of the main reason i dont use multiimage unless i add to main xpr.

because i'm a bit of a smoothy

[Smokehead]

you also have my support, with your skintool project, now a days it can be really a pain in the 4ss sometimes for everybody whois unformiliar with making a good skin for xbmc.

about the textures.xpr part, i see it more as prior art of the skin content itself.. protecting what the skinner made and worked on so hard. the skin also works fine if you put all the textures in media without packing it in a .xpr file..maybe you lose some speed..but hey it works..

[jimk72]

i will def. update it to 2.0 and should have all the controls working for editing. that was never an issue. i guess i will just see what happens after it is released and base the further updates off input from the users. this will mean if no bugs are found then no bugs will get fixed. if no updates are requested none will be given.

the current setup with the gui editing is not as smooth as it was before and some skins(orbs) make moving items around a little distracting but it is alot more stable. i am looking into setting up a way to add tags to controls and new complete controls without releasing a new version...

i have not the time now to work on it but after this sunday i should have time to get it up to 2.0 standards.

as of now xpr extraction is out. i spent way to much time trying to get it implemented only to get an error everytime i try to lzo decompress an image. if the images for all the main skins were not opensource and avail. i would spend more time on it but lately my time has been short on the pc as it is. any one that is making a real attempt at skinning will have already downloaded the images anyway so it is really just an extra feature to help the lazy. one that has eaten up alot of time. i would like to thank jmarshall for his time that he put into the code he gave me! if i do find time i will take another look into it. i think it has to do with the way delphi uses pointers(all variables are in a sense a pointer already) and the way c++ stores a pointer. i get an access violation from the decompressor so i think the image stored in memory is not accessible from another app when declared in a procedure. in c++ you have control and access to memory on the stack but when a variable is declared in delphi i believe it is private.? not sure?