Add scoop functionality to EcoBin classes

[graelo]

Hi, many thanks for this Addon, I love it. I was just missing the scoop for EcoBins.

This PR extends scoop support to both EcoBin and CustomEcoBin classes, bringing feature parity with standard storage bins.

Changes

• EcoBin: Added scoop properties and shape generation logic
• CustomEcoBin: Added scoop properties with proper custom shape integration (scoop is trimmed by inside_wall_negative

Both classes now expose Scoop (boolean) and ScoopRadius (length) properties in the UI. Default scoop value set to False for backward compatibility

Implementation

The implementation reuses the existing make_scoop() function and follows established patterns used by other features like label shelves. For CustomEcoBin, the scoop is properly cut by the inside wall negative to handle custom shapes correctly.

Testing

• Code passes linting (ruff) and type checking (mypy)
• I could not identify any breaking changes to existing functionality
• Maintains backward compatibility with existing EcoBin objects

This addresses the feature gap where scoops were available in standard bins but missing from eco bins.

Here's an EcoBin with a scoop (radius: 12mm)

The underside is unaffected:

It also works for 1x1 EcoBins

and custom EcoBins

[greg19]

Nice, cool to have it, thanks for contributing 🙂

[graelo]

Question for you @greg19:

I'm getting this FA100 warning from Ruff, and I'm wondering what's the most appropriate way for this repo to fix it:

freecad/gridfinity_workbench/feature_construction.py:196:58: FA100 Add `from __future__ import annotations` to simplify `typing.Optional`
    |
196 | def make_scoop(obj: fc.DocumentObject, *, usable_height: Optional[int] = None) -> Part.Shape:
    |                                                          ^^^^^^^^ FA100

I think we have to keep it work for Python 3.10 because I believe that's what FreeCAD still uses, so I went for Optional for the type hint. Would you prefer me to apply the advice for FA100?

Sorry, FreeCAD uses 3.11, I can go with the new notation.

[graelo]

Thanks for the feedback, it's indeed better now.

[graelo]

Hello @Stu142, a kind ping for this PR.
In any case, take care.

[Stu142]

@graelo thanks for the contribution I'll have time to take a look at it this weekend, I've been unable to find time over the summer but things are cooling down now and I have some catching up to do.

[greg19]

@graelo can you resolve the conflicts?

[graelo]

Hi, sure I’ll do this within a day.

[graelo]

Hi @greg19, I rebased on the latest master and fixed the conflicts. Cheers

[graelo]

I'll rebase soon.

[graelo]

Note: when running ruff check locally, I'm still seeing issues that are probably not linked to my PR.

[Stu142]

@graelo I have the same problems with the ruff check in the import block as well always have since this was implemented by a contributor and was unable to find a fix. I just had to leave it as is and manually make fixes.

[graelo]

Hi @Stu142, thanks! I was anyway rebasing following the previous PR merge. Here's the updated version. Ruff and Mypy checks passed locally. We'll see how it goes!

[graelo]

I found that I had been having issues with Ruff import sorting locally due to the fact that macOS filesystem is case insensitive. On macOS (case-insensitive filesystem), ruff classifies FreeCAD as first-party because it matches the project's freecad/ directory. This causes it to expect a blank line between import Part (third-party) and import FreeCAD (first-party), and to sort Part before FreeCAD. On Linux CI (case-sensitive), both are third-party, so ruff expects them in the same block, alphabetically sorted — and flags the macOS ordering as I001.

The fix adds known-third-party = ["FreeCAD", "FreeCADGui", "Part"] to the isort config so classification is consistent across platforms.

I squashed the commits. Now I need to test this still works. I'll report soon here.

[graelo]

Yup, it still works! You can see the thin stacking lip from Glenn in the last hour and the scoop applied to an ecobin.

and still no artifacts below, it seems correct from all sides

and it seems to work well with the think stacking lip too

[graelo]

Hi, I simply rebased on the latest master. Thanks in advance!

[Stu142]

Sorry for the extended delay to merge it seems to work great.

I found that I had been having issues with Ruff import sorting locally due to the fact that macOS filesystem is case insensitive. On macOS (case-insensitive filesystem), ruff classifies FreeCAD as first-party because it matches the project's freecad/ directory. This causes it to expect a blank line between import Part (third-party) and import FreeCAD (first-party), and to sort Part before FreeCAD. On Linux CI (case-sensitive), both are third-party, so ruff expects them in the same block, alphabetically sorted — and flags the macOS ordering as I001.

Interesting I am on windows but I think others were linux so there may be something similar going on I'll have to look into it.

[graelo]

Thanks!