bldrs-ai / share Goto Github PK

Probably grow the ItemProperties panel with tabs

The link sharing component should include an optional QR code

1. The QR code should embed the current URL, so that a user who scans the code will be brought back to where it was generated.
2. The QR can be opened separately and printed to PDF.
3. The QR code can be embedded in a given PDF, e.g. a 2D cross section plan in a PDF in the same repository. This would enable a CI/CD workflow to publish plans to construction site production and bring the user there back to check if the on-site plans are the correct version for production.

Possible libs:

https://www.nayuki.io/page/qr-code-generator-library

This is a tracking bug for TODOs.

src/utils/asserts.js should import tests for each function that test the relevant conditions, then just add throw Error if test is false. This is to help with cases where the caller might want to log (as warn or error) instead of fail.

Consider using JSONata queries on the IFCjs JSON as the advanced query format.

Full req:
https://docs.google.com/document/d/1JgLDfkghG6wqyYIplCQisSqyUK2XnRu43UEUEwAe8YI/edit#heading=h.h0vwu021rmhd

Probably under some menu like about or profile or smth.

Also include version in analytics.

e.g. prePick call is generating this stack trace.

but switching models via change of URL, e.g. to https://bldrs.ai/share/v/gh/IFCjs/test-ifc-files/main/Others/479l7.ifc, gives no problem.

https://docs.google.com/document/d/1JgLDfkghG6wqyYIplCQisSqyUK2XnRu43UEUEwAe8YI/edit#heading=h.hpg8z2gxjmsx

We currently run yarn lint locally with a pre-commit script. This should be run on git checks to get that green PR button love.

https://bldrs.ai/share/v/p/tinyhouse.ifc/84

Click on the Project elt in the NavTree and then open the properties panel gives stack track and white screen of death.

Open file currently opens a system dialog, but should tell the user the upload is temporary and alternatively point them to a guide on the Wiki showing how to host IFCs on GitHub, G Drive & Dropbox and then use them in Bldrs.

We chopped up the original requirements doc to start moving things here, but also didn't have a lot for Versioning requirements. That wasn't just being lazy ;) Our idea for versioning is to pass through GitHub functionality to the app. We don't expect everything to be useful as git is overly complicated, but some subset of versioning functionality.

1. So for instance here's a file you can view in Bldrs by pasting it into the search bar:

https://github.com/Swiss-Property-AG/Portfolio/blob/main/KNIK.ifc

the "main" path segment is the branch the file is in, and without any further information, this means the HEAD version of the main branch. That currently works.

2. GitHub also provides hashed and tagged versions, which we should support soon.

Supporting these means both in the URL (see also https://github.com/bldrs-ai/Share/wiki/URL-Structure) and also in the UI, by having some component to help explore previous versions and branches.

EDIT(Aug 18): The Share URL structure actually already supports versioning! So changing this issue to track development of the UI control. Example of versioned file:

https://bldrs.ai/share/v/gh/Swiss-Property-AG/Portfolio/770153b703d7aa59f7be0cb87930f29f162f666f/KNIK.ifc

Stretch: Lastly, we'd like to support checking in changes and resolving diffs. This is where things get complicated, so we'll need to revisit this more later.

https://docs.google.com/document/d/1JgLDfkghG6wqyYIplCQisSqyUK2XnRu43UEUEwAe8YI/edit#heading=h.n7zd6veqixhr

If there’s a file in the git repo, make the URL to share it formulaic, so we can share the IFCs in a repo before we implement the full UI directory component.

Full requirement:
https://docs.google.com/document/d/1JgLDfkghG6wqyYIplCQisSqyUK2XnRu43UEUEwAe8YI/edit#heading=h.1cwhpa145gax

Current cam positions are working repeatably when both position and target location are included in the url:

.../share/v/p/index.ifc#c:-15.18,9.32,52.05,14.69,8.96,11.19

But toggling the flag viewer.IFC.loadIfcUrl(..., fitToFrame=true|false, ...) yields slightly different results (below). We're good with the default of fitToFrame=false, but that means no autofit for uploaded models. I have a workaround for now which is to enable this flag after the first load. Pretty lame

but this means there's yet another camera parameter needed to specify camera after a frame refit, which may happen after a double-click centering. I haven't seen this yet, but probably an issue

Code walk starts in IFCjs:
https://github.com/IFCjs/web-ifc-viewer/blob/92ca8c8117e942fc7e452859bd999ee2f8eebc79/viewer/src/ifc-viewer-api.ts#L139
https://github.com/IFCjs/web-ifc-viewer/blob/92ca8c8117e942fc7e452859bd999ee2f8eebc79/viewer/src/components/context/camera/controls/orbit-control.ts#L37

Then over to the camera-controls library:
https://github.com/yomotsu/camera-controls/blob/07fc3c2c8ebae2816a56a80e1cbc2f6892d20a58/dist/camera-controls.module.js#L913

with loadIfcUrl(fitToFrame=false), we get the right position, but needs the temporary workaround so that later models get autofit:

I want to use loadIfcUrl(fitToFrame=true) all the time, but the recorded position (from above) gets jogged over:

Users should be able to click on a link to open a tool that performs some function/manipulation on their IFC tile

error occurs on load

The NavTree broke completely, and then after a partial fix showed element types as names, not element names.

The selection of an IFC element causes latency in the application for the models larger than 20MB.
Enable monitoring of separate portions of the app to diagnose the problem areas that require performance optimization.

Page is blank with error fro web-ifc. Fix is ready.

https://docs.google.com/document/d/1JgLDfkghG6wqyYIplCQisSqyUK2XnRu43UEUEwAe8YI/edit#heading=h.rh99cx6i6qu7

Setup GA4. Added event tracking for open and search.

Cleanup names and values for property set.

We already have some properties handled well, but need to handle more cases.

This appears to help: https://www.npmjs.com/package/jest-transform-css

https://docs.google.com/document/d/1JgLDfkghG6wqyYIplCQisSqyUK2XnRu43UEUEwAe8YI/edit#

e.g. in a sample IFC:

#49124= IFCMATERIALCONSTITUENT('Component 1 in St\X2\00FC\X0\tzensegment 1',$,#10932,$,$);

These look like extended characters that need to be decoded.. currently we're just passing through the backslash.

We need to have a Image button preview of a screenshot of Tinyhouse, which when you click takes you to the GitHub path to the Momentum tinyhouse project.

This will also require some comments setup on their repo to work well.

But really for now we just need the button somewhere.

Maybe we tuck settings into an expando or accordion or move it back out into a separate ControlButton

https://docs.google.com/document/d/1JgLDfkghG6wqyYIplCQisSqyUK2XnRu43UEUEwAe8YI/edit#heading=h.5h9gvbtqsc10

How about using the "b" from our logo as our favicon?

Also, reminder for myself to add a useful title sub-path, e.g.:

"BLDRS: tinyhouse/.../window" something?

To enable information management for building elements we need to be able to extract the data from an ifc in a structured way. Depending on the source of the ifc, each element (e.g. walls, slabs, windows) contains a set of ifc property sets and attributes.

As a BIM coordinator I want to be able to use this information across various workflows and across various tools.

In a first step the information could be extracted by the user providing information on what elements and what property sets/attributes are needed. Ideally the tool would show an overview of the elements and property sets/attributes and the user could select the data for the extract. Additionally, this could also be part of an API for buildrs.

We should include an tracking event to count how often users are opening IFCs. This will also may help distinguish crawler traffic from real use.

Enable typescript + define types for the viewer

https://docs.google.com/document/d/1JgLDfkghG6wqyYIplCQisSqyUK2XnRu43UEUEwAe8YI/edit#heading=h.hpg8z2gxjmsx

Asking for /foo.png works on localhost and production but does not work on the personal fork.

iOS & Android

• AboutDialog alignment issues, the bullet list and also the cookies slider pops out
• NavTree has a horizontal slider showing

https://docs.google.com/document/d/1JgLDfkghG6wqyYIplCQisSqyUK2XnRu43UEUEwAe8YI/edit#

• Open existing files in the repo, i.e. from a dialog that shows what IFC files are present in a subdir.
• Open a URL pasted in by the user.
• Stretch: open files in the organization.
• Super stretch: open files from GitHub, e.g. using a search index.

See TODO: https://github.com/buildrs/Share/blob/main/src/Containers/CadView.jsx#L97

Adding on to #26, we need to use routing for:

• Different IFC files
• Search
• Nav to item/select

We're including gtags in our pages, but should have a cookie toggle for this. I'm thinking a bar:

Cookies: [F----N----T]

With a slider from F<->T

F: functional: e.g. theme, list of recent URLs
N: navigational: things which change URL
T: telemetry: fine-grained

I think a trim version of this could be included in the About panel and suffice for our gdpr notice.

'nuff said.

But actually, this should go along with Bldrs logo as the index.ifc, and a tooltip prompt for the open dialog to make sure users know what to do. Probably depends on #114 being live.

Wire snackbar to model loading