Hi Ionut, When launching the installed application, the window immediately renders a Microsoft Edge WebView File not found (ERR_FILE_NOT_FOUND) screen. I’ve tried a clean reinstall including clearing both %appdata%\ro.ciuntucbimstudio.lapin and %localappdata%\Lapin, but the app continues to recreate the folder and hit the same missing path error on startup. Please see attached Thanks!

Hi everyone, Some of you used the first Lapin in the browser, and some of you noticed it went quiet for a while. That pause was on purpose. Lapin has been rewritten from the ground up. Today the first test builds are out for Windows, macOS and Linux, and a web version runs the very same engine right in your browser. Here is what changed, why, and how it works under the hood. Why I rewrote it The first Lapin was built on a fork of ifc-lite by accident. I've miss-understood the requirements for ifcsheets given by @Petru Conduraru , and distiled and exposed into the UI editing functions in ifc-lite. The project only needed documenting ifc models, so I split the project. I wasn't expecting the popularity jump that in got in only 3 days. It was a great place to start. It let me prove that a modelling tool on the IFC schema, with layered walls, joins, roofs and drawings, could feel fast and simple. But a fork is a borrowed house, and I had three reasons to build my own. 1. One engine, my engine. For a while I've been building BubbleBIM Pro, a C# engine with its own geometry kernel, session, undo and module system. Running Lapin on a different core meant maintaining two worlds and solving the same problems twice. I wanted Lapin's ideas, workflows and test cases re-linked onto the BubbleBIM Pro core, written in one language, with one architecture I understand end to end. 2. A modelling tool, not a coordination platform. ifc-lite is rich in tooling for BIM management and coordination: viewing, federating and checking models, and working with them across a project. That is valuable work, but it's not my field, and I'm honestly not the right person to carry it. Lapin has one job: authoring a model. Forking a large toolkit meant carrying a lot of code I didn't need, didn't fully understand, and couldn't maintain well. 3. Less friction with a community I respect. I admire the ifc-lite project and the people behind it. A fork that keeps diverging creates confusion: whose code is this, which licence applies where, and what should flow back upstream? I'd rather each project be clean and fully itself. Lapin and ifc-lite now meet where they should, at IFC files, with no tangled history in between.