Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

assignments made in src/settings.scad override assignments rather than merely providing defaults #213

Open
jskubick opened this issue Jul 25, 2024 · 1 comment

Comments

@jskubick
Copy link

What version of OpenSCAD are you on?
current dev commit as of 7/24/2024 (19f0d2f, I believe)

Describe the bug
I'm not really sure whether this is a bug, or just a documentation-deficiency.

To Reproduce

  1. check out the latest version of the repo (19f0d2f, as of today)

  2. edit keys.scad:

// for low-profile Gateron KS-33, which are similar to low-profile Cherry MX
$stem_type = "rounded_cherry";
$stem_inset = -1;
dcs_row(3, 0) legend("x", size=9) key();
  1. Hit f5.

  2. note that the changes to stem_type and stem_inset made in keys.scad are completely ignored.

  3. switch to v2.3.0, make the same changes to keys.scad, hit f5, notice that it now works.

  4. switch back to 19f0d2f, change both values directly in src/settings.scad, and notice that they work.

So... it looks pretty clear that something that changed between v2.3.0 and the latest dev commit is now causing src/settings.scad to override assignments made elsewhere, instead of merely serving as default values if they aren't set elsewhere.

@jskubick jskubick changed the title assignments made in src/settings.scad override assignments rathern than merely providing defaults assignments made in src/settings.scad override assignments rather than merely providing defaults Jul 25, 2024
@jskubick
Copy link
Author

OK, I found the problem.

In v2.4.0 and earlier, src/settings.scad gets recursively included by keys.scad when it imports includes.scad.

At some point after v2.4.0, someone decided to add include <../settings.scad> directly to all the modules in src/key_profiles, so it's no longer possible to override them via ./keys.scad prior to generating the key.

===

At the moment, I'm working from v2.4.0, because something in the latest developer version in the repo is causing the keycaps to have diagonal chunks shaved away from the front and rear. It's not stopping me from hacking and slashing away at it to implement support for Gateron KS-33 stems (which are just different enough from Cherry's low-profile stems to create keycaps that kind of fit... but jiggle... and nothing I've tried with $stem_slop or $stem_slop_inner seems to make any meaningful difference.

Also, v2.4.0 has a problem with negative-inset stems poking through the top of the key. I fixed it by making this change to functions.scad:

function stem_height() = $total_depth - $dish_depth - (($stem_inset < 0) ? 0 : $stem_inset);

It seems to work (in the sense of, "after I made the change, the stems quit poking through the top of the keycap")... but I don't know enough about the implications of how stem_height() gets used elsewhere to know whether I've just traded one problem for a bigger one I haven't discovered yet.

===

So...

  • assuming "settings.scad" is just supposed to contain default values (and not be edited directly when generating keycaps), and
  • assuming the decision to import src/settings.scad at the start of each profile (causing those settings to override anything defined in keys.scad) was deliberate and intentional,

what is the intended way for users to call something like sa_row(3) using stem_inset=-1 and stem_type=rounded_cherry (or my as-yet-unwritten gateron_ks33 type) in the new dev-build scheme of things going forward?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant