decompme
Let the user set custom m2c flags
Is your feature request related to a problem? Please describe. I use m2c locally, so I can set custom flags, but some people working on our project prefer decomp.me. I plan adding new flags to m2c which I'd like my colleagues to be able to use on decomp.me, so it'd be great if there was an initial support for some of the already existing ones.
Describe the solution you'd like Have checkboxes and input fields for m2c flags like this does.
I believe this is covered in #449 - but yeah I'd love it if we provided a ui and api plumbing to configure m2c. We'd need to add the decompiler options to the Scratch model as well as update the relevant api calls to handle that field. then in the frontend, we can do something similar to what we do for compiler / diff options.
Sure, please do! I think it should be done in a way where we can easily add option support as we go (probably handled the same way diff flags is) but open to ideas
Great!
we can do something similar to what we do for compiler / diff options.
I would create a similar UI, yes, but this one only makes sense on the scratch creation page, right? Should we add these flags to the presets and then let the user manually tweak them under the Context text box?
I think it should not be on the scratch creation page in order to keep that page as simple as possible. Like the diff options, it can be on the scratch options tab. The idea is that you'd be able to change settings as you want and then re-run the decompiler. Of course, if the scratch is created via the API, the settings can be specified there at creation time, and if they're not specified, they should inherit the decompiler options of the given preset.
Ohh, I completely forgot that we had a decompile button... That makes sense a lot of sense then. At the same time I also find it very important that the latest flags stay in local storage and are used automatically when creating a new scratch.
That makes sense, yeah. I guess we can make it collapsable, in which case I'm more open to having that on the /new page. It's just that some people won't know what options to choose and it's more daunting when learning how to use the site to see tons of ui / options right at the beginning. So if it's collapsed by defualt, I'm cool with it being there
I see. What I described is also possible with the approach where it's only in the scratch options page though. That would save it in local storage and the new page can use it. It just depends on what you prefer, collapsable options on the /new page that defaults to the preset/save ones or only using the latter. If we have a collapsable one, can it have the exact same UI on both pages?
What I described is also possible with the approach where it's only in the scratch options page though. That would save it in local storage and the new page can use it.
Oh, yeah you're right... I guess I'd prefer it not part of /new, so if you're cool with keeping it only in scratch options, I'm happy with that too. This makes the most sense to me. If people clamor for wanting it in /new for some reason, we can revisit that later
Ohh, I completely forgot that we had a decompile button... That makes sense a lot of sense then. At the same time I also find it very important that the latest flags stay in local storage and are used automatically when creating a new scratch.
so in summary, yeah, I agree with you. the m2c flags, which ultimately will be stored as a text field or yaml or something, should get saved in local storage the way other things currently do
Yes! I will try to future proof it by not making it specifically for m2c, but for the decompiler in general.
So do we want to save the flags only in local storage or would it make sense to also do so in the scratch? I can see the latter working.
My intention / thought was to have it be another field alongside diff options for scratch