Add fuel consumption recipe for products

[Dorus]

Fixes #76

This adds the option for products that are usable as fuel, to select a recipe based on that fuel consumption. YaFC will then attempt to add said recipe using the selected fuel.

I had to do some performance optimization since the electric power, or biomass, tends to select most py recipes (!), i saw over 8000 of them in my debugger. It now pre-sorts the list when the popup is opened, not each time you move the mouse over.

[shpaass]

example

For some reason, I can't see the example image in your initial message. Have you put it into a message differently from pasting it with Ctrl+V?

[shpaass]

This adds the option for products that are usable as fuel, to select a receipt based on that fuel consumption.

Did you mean recipe instead of receipt?

[Dorus]

example

For some reason, I can't see the example image in your initial message. Have you put it into a message differently from pasting it with Ctrl+V?

Oops, i tried to copy the image from #76 (comment) and somehow messed up. Should work now.

This adds the option for products that are usable as fuel, to select a receipt based on that fuel consumption.

Did you mean recipe instead of receipt?

Yes.

[shpaass]

For clarity, I advise to fix the recipe typo across this PR and the linked issue. This word has been used quite a number of times in them.

[shpaass]

Fixes #76

I think that Hint: ctrl+click to add multiple needs to be shown only once instead of thrice.

I also think that headers like Add consumption recipe need to be a bit smaller because now there are more of them.

[Dorus]

Made it so the hint only shows up once. Also decreased the header size. This will affect a few more pop-ups since this display function is reused a few times.

[Dorus]

One question, do we prefer to keep a linear commit history to see how we progressed and improved the code, or would a rebase that squashes it all minor changes together be preferable?

[shpaass]

do we prefer to keep a linear commit history to see how we progressed and improved the code, or would a rebase that squashes it all minor changes together be preferable?

Our goal is to make the commit history as understandable as possible. It means that ideally we want changes to be separated into logical steps of digestable size, without ad-hoc hotfixes or previous versions.

However, I also understand how much effort and energy that can take. So I would say go for low-hanging fruits like squashing hotfixes, and separating formatting updates from logic changes. The rest is optional and depends on how good you want it to be.

[Dorus]

My typical commit history is an utter mess of small tries and fixes so i prefer to rebase a lot and squash related changes together. If only because that makes it so much easier for myself to review the changes and make later rebases so much smoother too. I'm also getting quite adept with the git rebase -i command ^_^

[shpaass]

I see you're a man of culture as well. Props to a git rebase -i enjoyer :D
Don't forget about git commit --fixup=%commitHash% and git rebase -i --autosquash.