Mine had disappeared, too. What I did was first confirmed the scripts were still there in the %localappdata%\darktable\lua directory. The with darktable not running, I changed this line in %localappdata%\darktable\darktablerc
from:
lua/_scripts_install/initialized=TRUE
to:
lua/_scripts_install/initialized=FALSE
…I think that’s the correct line! 
Then restart darktable and the script manager will show up, assuming you’ve not disabled it in preferences.
I agree, and I wonder how well this change has been thought through. I think a proposed change like this could benefit from an airing here in the forum before actually making it. However @Terry , I’m just curious how much time you allow for an edit! - I mean it doesn’t take long to go into WB and set “as shot” in two clicks.
It’s not practical to have these discussions on two separate forums (github is the place for discussing such things), though it’s great to have so many people testing master. The more people using master the better the chance of spotting issues before new versions are released.
Edit: Of course there’s nothing really stopping new feature proposals from being discussed here, but if you want to be sure the developers will participate, github is the place.
Did you see the post where I realised (thanks @priort ) that you can set the new workflow options to “none”, which seems to bring back legacy WB, then create a style or auto-applied preset to turn on filmic or sigmoid? As pointed out to me, one does lose out on the exposure +0.7 default and the filmic auto-adjust but for me it works fine as I always adjust all these anyway.
I will give this a try. I am just a little surprised that we have had an option taken away from us and I have not yet understood why that had to be done. If it is a maintenance or coding issue fair enough, but what I like about DT is that usually the user is given the freedom to choose what suits them and this change has restricted that for a reason I don’t understand. I will just have to modify my workflow a little.
Considering I edit hundreds or even thousands of photos the extra clicks begin to add up and creating a style will not solve the problem. I would much rather the two extra clicks be the few occasions that I want to use the CC module. It just seems that we have lost the freedom of choice and gained nothing that wasn’t already there.
I think its time to let it go…set the workflow to none…You get legacy WB with the camera data …ie as shot. If you want sigmoid or filmic just create an auto preset to apply it… its rare that nobody touches it. Same for sigmoid if that is the choice and finally you could make a style that toggles sigmoid and filmic or the reverse depending on which one you start with… The same for exposure… if you want the default 0.7 EV or whatever auto preset that too…Do it once and then no extra clicks… I don’t think it was a hugely necessary change but so be it… if setting it to none wouldn’t give you legacy wb then that would be a pain…
I will definitely let it go if it gets implemented in the stable release and find a new workflow that works for me. I just grumble a little so the developers can realise not everyone likes the change and then hopefully they will consider if the change is needed. The current scene referred workflow was always there in 4.2 by default, but now it is being forced onto me in its totality. I will try your suggestion and put up with what ever change happens.
Works fine.
Just a remark, the issue for this change was opened by me on Nov 15th:
The implementation merged on Jan 2nd.
So 1.5 month of discussion possible. The developers take decision on what is discussed, no magic.
A lot of users - non devs - learn about those changes after they have been merged. So some kind of ‘what?!’ reaction is to be expected .
I encounter images quiet often where the modern setting just doesn’t work. Now i recognize it and i can set and adjust my defaults , so no problem for me.
But it does increase the amount of ‘default rendering’ images where less-technical users would go “what is DT doing ?!”
I was under the impression that the first impression was important to the devs (that’s why the modern flow had ro be chosen before , and the ‘clipped’ HLR method was the default for a long time ).
But i haven’t read the discussion, nor do I care enough to make a big deal about it now :). I do expect a lot of newer users (with Sony cameras / sensors ) going to ask what’s wrong with skin tones of the image was shot with ‘indoor’ lighting (or something just very far removed from the daylight reference ).
Those must be told to fix the white balance 'to be more correct ’ in the WB module , and then reset CC to as shot and ignore the warnings about double white balance the modules then give.
What i dont understand , is that the cam16 code in rawtherapee expects 'a more of less correct white balance ’ and recommends setting the WB to temperature-correlation auto mode first.
While DT sets it to a fixed (D65?) White balance
Pascal, there are two kinds of changes:
I think if you want to make a change to make the tool easier to use for users, discussing it only on GitHub is not the right choice, as most users are not there. Discussing the technical details can and should take place there
I think the way sigmoid 1 2 or color calibration was discussed here, even when things went into the details, was very useful. I understand that it’s a pain to have separate discussion threads running.
This idea that merging is somehow an irrevocable process is problematic for me and it’s not the first time it’s been suggested or implied. I am a regular github user (a “dev” for want of a better term). I monitor the issues and the pull requests on a fairly regular basis. I don’t always have time to examine and consider the implications of every change. Sometimes the impact of a change isn’t felt until it’s used or some “aha” moment is encountered. Sometimes I think of something but I don’t have time to discuss/test and sometimes I don’t even have time to read beyond the first paragraph. Ideas that seem good at first glance don’t necessarily pass muster after serious consideration.
There is no length of time after which mistakes can no longer be reverted.
Nothing irrevocable, we can adjust when needed and this has already been done numerous time. We had comments about simplifying the workflow setting, this has been done. There is corner cases not foreseen, no problem we can adjust when we we’ll have a clear idea of the blocking problem. Reading latest comment I’m still not sure we have blocking issues, especially with:
But sure I already said it, I’m not for reverting except when it is plain wrong. We need to move forward.
Sometimes moving forward means realising that we have not improved things and that reverting to a previous state is the best (least bad) approach. It feels like you are saying that only major bugs should cause us to reconsider a decision already made. Anyway we’ve had this discussion before about other things so I’ll leave it there.
@Terry I posted this on this thread. If the change had a negative impact, start an Issue on GitHub. Explain your case with details. There is no need provide a solution (eg Revert!). But grumbling (your words) here is not an effective way to provide feedback and start a change. There is plenty of time before 4.4, so plenty of time to address issues.
I searched on GitHub and I don’t see an Issue for this.
That looks good! Assuming the WB module responds to initialization by reverting to as shot, that would solve any remaining issues for me. Great 
I meant no offense with my grumbling here. I see this forum as an informal way of discussing issues and learning solutions. It is not possible for all users to follow every conversation between the developers on GitHub so I was unaware of the coming change. I download and use each weekly build for Windows to keep track of the changes and improvements as well as I presume beta test the changes to DT. I feel my comments here are just a response about the beta testing of the change. Please take it as constructive comments of my observations and not any attack on the work of the developers. I would never do that.
I plan to persevere with the change and find my own solution with the help I have received here. If I truly can not resolve the issues I have with the change I will then post a comment on GitHub with details to explain my case, but I don’t want to add noise to GitHub until giving the change a fair chance.
I feel this informal forum can be the right place to at least express our original reaction. Then others can give advice and help in overcoming our reluctance to change.
Again, thanks to all the developers for their efforts creating Darktable and moving it forward at such an incredible pace.
Edit:
I have set my workflow to none and then created a style applying modules that I want such as filmic. This seems a reasonable solution to me at the moment and I will test it out as I continue processing images. Thanks for the suggestion which is obvious in retrospect. BTW, I did not include white balance in the style as I suspect it would apply the WB from the image I created the style in.
EDIT: I discovered that raw black/white point must also be excluded from the style or bad results can occur.
Interesting point, I’ve asked about that where Pascal Obry linked.
It does at the moment, but I’m not sure if anything else could affect it…