Comments URL: https://news.ycombinator.com/item?id=42887803

Points: 6

# Comments: 4

I hope that with them gone the project doesn't revert to the mindset of "everyone gets their own fiefdom (workbench) to manage" that's resulted in instabilities and fractured user experience in the past.

Not trying to disrespect the other FreeCAD developers, but it seems like things have improved remarkably since ondsel started taking a more active role.

The project seemed to exhibit a (common) impulse to prioritize extensibility too much. The "workbench" architecture and python API let you do some really neat stuff if you're willing to dig into the weeds. But, from the perspective of a community outsider (so take it with a grain of salt), the development process seemed to be a good example of Conway's Law in action. The workbenches let everyone have their own sub-projects to manage without stepping on each other's toes. This led to a lot of resulting complexities, inconsistencies, and instabilities, which made the approach a net negative (imo) in terms of tradeoffs.

With ondsel, there's been more focus on holistic improvements and getting the individual modules working together more smoothly, which I greatly appreciate.

If not, you might run into [this bug](https://old.reddit.com/r/linux4noobs/comments/uj58i5/psa_fix...)

FWIW my solution was using equivs to create a dummy package to satisfy www-browser and installing that.

I've also been running into an annoying issue where hover menus will randomly stop working---it seems like the mouseout event is firing before the click event is handled.

But all in all not annoying enough to switch.

    void log(Supplier messageSupplier);

    log(() -> log.info"User is \{someExpensiveFunction(user)}");

The only way to have the option to have your preferences met in a large and mature enough market is to be completely price insensitive.

Of course, this is a loophole big enough to sail a cruise ship through. And the Senate takes full advantage of that loophole in practice.

Another possibility is writing a native app that works like a shim: reading from the COM port and using APIs (e.g. SendKeys on Windows) to re-transmit the characters as keystrokes. But the most robust solution is probably a different scanner.

The complaints in the original article fell rather flat to me, but this is one area where it's absolutely fair to criticize VS. More generally, the reason that build tooling in the .net sphere is such a mess is because of historical baggage from VS.

With that said, if you're coloring within the lines[1], VS is very powerful and productive.

[1] To an extent. There definitely are use cases that are "supported" only in name.

They've already started down that road with s mode, which is default for new installs and not a separate SKU (anymore) that you can avoid.