It doesn't bug me too much. I vote for leaving it in "just in case". (unless it could be split into a separate option easily)
Back to top

Dido that Crust. I also vote like you. Does not hurt to leave it on.
Back to top

Modules built through smxi should have been opt-in from get go. The problem is not every user cares to know what module initializes what piece of hardware, so it's a balance.

If you force everyone to sit through minutes of painful module downloading and building, users stop using smxi or they get the wrong impression (especially if it's a configuration option you can change).

So, the best solution IMO is to ask the user which modules they'll like (and a brief description of what they do) so they can avoid burning time on modules unnecessary to _them_, but still retain the functionality of their system without any serious time loss from using smxi.

Some users don't even want that, and they are better off not using automation scripts (like me ;) ).

PS, h2 why did you have to go and change the X detection logic, you bastard :(
Back to top

smxi has always had module remover option, and it only tests installed modules, the problem here was installing every module known to man in the first place, rather than having it be opt in on initial sidux install.

I didn't change any x option, you must have a bug in your stuff damentz, haven't touched that logic for probably a year or more.

Again, if you remove unwanted modules, the download will still test for non liquorix, but the reinstall only does what you have installed on running kernel, the assumption being of course that you want it since you have it running. And the download step, I've actually used that before by the way, you never know when you will need a module, I could add an option to skip it, like -! 41 or something, and users could hard set that in sticky prefs if they so choose, but I am finding that the abundance of options is already not really used much, so I suspect that this one too would largely go unused.

and for liquorix, this stuff is all skipped since there are now no liquorix modules.

While it's always easy to say a sentence, such as: feature x should be more fine tuned and interactive, that takes time, that's average about 2-4 hours to code it, then a few days to get bug reports and feedback from people who didn't want it, don't like it, or find bugs with it. So I'm not as enthusiastic as I once was about implementing every single feature, especially given how the existing stuff isn't even used, damentz, for example, has asked for custom stuff that was already in sgfxi, supported, as an advanced user set option, but he didn't read enough on it to see that, so adding even more options isn't something I'm going to be doing much of in the future, unless really needed.
Back to top