would it be possible to have a feature in nlm to do something like

or something like that (maybe just not give a version number?) to have netloadmodule just download the most recent version of the module? that would give users something like an auto-update notification for whichever modules they want, which i think would be pretty helpful

possibly just have it pop up a window asking if the user wants to update this module, and giving a changelog between the current version and the version the user is currently running (this would be made much easier with a standard layout for documentation...)

this way, the user could see how backwards compatible it is and what needs to be changed... and would be a much more user friendly way of updating modules for those people in the process of learning more about litestep, or who are just lazy (like me(: )

this probably shouldnt be included in any theme distributions, since there is no guarantee of compatibility between versions, but it would be a useful setting for the user to be able to specify

most of the time, updating modules means updating step.rc
if it's not the case, there's no need to update modules
...

I think it's a good idea. Obviously updating step.rc (or forthcoming theme.rc) is often a part of updating the module, but bugs and leaks could be updated this way...

most of the time, updating modules means updating step.rc
if it's not the case, there's no need to update modules.

Wow, I'm glad there is such confidence in the module authors to so assume our modules never have bugs or anything that needs fixing. :)

If the first thing I had to do after downloading and installing a new (old) theme was to update step.rc for three or four modules I'd rather go back to my old theme.

Perhaps there is some way to mark a version as either a bugfix release or a feature release. NLM would find the next higher release that didn't add any new features.

and most releases are both bugfix and feature releases, but usually when features are added, they wont break backwards compatibility... just because a feature is added doesnt mean you have to use it, you could just upgrade for the performance/bug fixes... there should be a way to mark a release that is not backwards compatible though

Would it be possible to contact a module's author for feature requests instead of just waiting for them to find out? ;)

There's a very important reason why NLM can't do this right now: It has no way of knowing what the most recent version is. NetLoadModule is very stupid. It just pastes the module name into a url and downloads it. It doesn't really know what module it is, what version it is, whether a version is included in the name, anything. Somebody told it that there's a dll in a zip file somewhere that it should load, and it believes them.

Themes and incompatible module updates would make this really nasty. What if a theme doesn't include the version number and some version of the module already exists? What if more than one exist? How will it know which themes have been updated for what versions of each module?

Auto-updating is an obvious extension of auto-installation, but I think this should be handled by an external application/module updating the version numbers in the theme's rc files. (The addition of !NetReloadModule et al changes things a bit though... I may have to rethink this.) This would keep record of what version of module to load for each theme.

Another benefit of this would be that I don't have to hardcode the UI for it. Modularity! Yay! (and I'm lazy! yay!) Seriously though, I'm sure some themers would want to do strange things with the update notifications. And since updating often means changing the theme, maybe this update tool could check for updates to the theme so we don't have everyone needing to manually update their themes. Now that would be neat.

As for NetLoadModule, I'm happy with its scope: net load modules. :D

Personally when I read about OTS version 2 I was a bit disappointed. In my opinion, sacrificing compatiblity for the newest versions of modules and non-cloggered directory structure would have been cool and a better option. Just one directory with the modules, and then the theme would say "load Rainmeter" and lo, it would, the version that exists in the directory ie. the one the user has decided to be the correct one. Of course it does that now, but somehow it bothers me that there can be ten or twelve rainmeters on my computer. On the other hand, if I understood it right, you can point all the releases of a DLL to anything you want, but still... You want to use the newest releases of modules for buglessness anyway, and updating an old theme before prolonged use is always a neccessity.

Hmm.
After reading this now, the post seems just like a testament for an irrational fear of development and automation. Disregard at will.

rabidcow: sorry for not emailing you(:
this would be a setting that would definitely not be included in any theme distributions, but i can see how this would be kinda nasty for multiple themes using different module versions... nlm could keep track of that though, maybe keeping a list of which module versions to load for each theme in netloadmodule.ini, and the highest version number hat the user doesnt want to update to, or maybe just whether or not the user wants to update that particular module in that theme... it would be complicated, but i think it could work

ive been thinking it would make more sense to pass the module name and version number as two separate arguments anyway, although that would make nlm more complicated... i dont know, its just an idea(:

hmm, if a setting like "*NetLoadModule tasks-current" isn't going to be used in themes (I know I wouldn't use it, I can't imagine what would happen to my old themes if they automatically loaded new versions of the modules they use ;) then how much of an audience is there for such functionality?

personally of course, i'm happy with NLM as is... all of you can continue making feature requests, i for one am going to ally myself with the forces of inertia, stand against the universe and try not to contribute to the increase of entropy. (lol, talk about a lost cause. ;)

and now, let's build ots2 themes:)

Warma: I'm not sure what the complaint is, but I think OTS2 is an improvement over OTS1 in this regard. Both will load the version of the module that the themer specified (unless you do a search and replace to change that), but OTS2 will only keep one copy of each version of each module, while OTS1 would keep one for each theme, even if they're the same version.

doy: NetLoadModule doesn't know what theme is loaded, or if you're using the old method of putting all your settings in the root step.rc.

I thought about separating the module name and version number, but instead (for the purposes of an auto-updater) you can just use the first - as a delimiter. Passing them separate wouldn't really make things more complicated by much, but as long as module names don't contain hyphens, there's no gain.

My complaint was that I would have preferred one version of a module per Litestep installation.

I admit that as it is now, the themes are easier to use and no compatiblity problems exist, but the idea of just copying a .DLL to my \modules -dir and automatically updating all modules while I did, would have been nice.

But as noted, the above can be accomplished by never allowing NLM to download modules and modifying the ini to point all versions to whatever you have installed.

All is well, so to say.