I'm struggling for quite some time to find out which is the best module to do what I need, and worst is that I find a lot that promise much but are either unfinished or have some bug that isn't letting me do what I want.

But worst of all is fighting will all the versioning strategies and all the different versions flying around out there.

So I was wondering about one thing: why can't we have the name of the module settled and include versionning information inside it? Why not have a function in the module that returns the version information. It would then be possible to fix a format for versions xx.xx.xx or whatever else, but have everyone stick to it!

In this case, instead of having : "popup2-2.04.dll" we could just have "popup.dll" and let Litestep (the NetLoadModule) take care of the version information through some simple tag to add.

It was probably already discussed someplace but I didn't find it yet. How big a challenge would it be to i,plement something of the kind and spare everyone from manually editing "theme.rc" or renaming files?

One more idea, the Theme Installer seems clever enough, so why not provide the modules needed with the theme and have him install them at the same time?

Cant do it like that because each newer version could break functionality and themes depend on modules in which they where written for.
Sometimes you can upgrade modules in a theme and it has no dire results and other times the theme just will not run.

If you have the modules included with the themes it makes the theme much more bloated when it is released. The point when you release it is to make the file size as small as possible.
OTS2 solved this by placing all theme modules in the module folder for all themes to use requiring only 1 existence needed on the hard drive.

Just a side note andymon has been working on all the xmodules and they are very good to use in a newer litestep theme.
So I'd suggest starting with those modules.
Be aware that there are modules he released using xpaintclass.dll and IMHO these modules are really for ppl who want to make imageless themes.

Just read the docs that come with the modules and see if it is an XPC = xpaintclass module.

So all in all stay with the newer modules because they will have more features you might want.

It's also a licensing issue; not all modules are GPL'd and thus they may not be included with a theme.

How come people can make non GPL modules for a GPL program? Can anyone else use their modules for a theme?

Back to breaking functionality, wouldn't it be helpfull to have the module creator check compatibility inside the module? He knows best what he has changed/repaired/added.

Picture this : !NetLoadModule popup 1.96.5
But the popup module installed is 2.02.3 A function inside the module could check the version against a table of compatibility and say wether the theme will run all right or not.

I'm thinking that asking if each and every function needed wouldn't be a good idea since functions can be changed to do something different and it would make too much more code. But asking for versions and checking their compatibility can be easily done and implemented!

P.S. I'm delving into the xmodules

Since the modules are updated more frequently than the themes (and generally updates come out *after* the theme has been released) how can a themer know whether or not they are compatible?

Well, he knows with which module, and which version he built his theme. He will just ask the module that is installed on the machine to be compatible with the one he used. It's up to the programmer of the module to maintain compatibility between module versions, not to the theme developper to do it! That's why I think it would be good if the module could provide a method to check his compatibility agains the version on which the theme was built!

Problem with that is sometimes you find a bug that must be fixed...and in order to fix it you must break compatability with a previous version. Just look at LSXCommand. You have Umpteen versions but the last couple had memory leaks or broken features so people use the older versions intentionally.

How would NetLoadModule know what the newest versions were for each module? Right now anyone can drop module zips on a server and use it as a module archive. (I've shared the zip dir on one machine and used it as an archive for another.)

Modules will break compatibility between versions from time to time. What are you going to do to prevent it, fire the developer? Nobody's paying developers to think ahead when they design their configuration so that it will seamlessly support new features.

Similarly, expecting them to make note of compatibility changes is naive, you're lucky the documentation is kept accurate and up to date. Sometimes compat. breaks unintentionally too.

The bottom line is that there's more work involved in "fixing" this than in just dealing with it, and that work would have to be done by those spread the thinnest.

Word is, you can see right through RabidCow, at least in bright lighting.