[Feature request] Add configuration file to have custom defaults.

[quasipedia]

Hello there (again! 🙂 )

I take this doesn't exist (or anyway: if it does, I failed to spot it), but what I would find very useful would be to have a simple configuration file (TOML seems a great option here).

What happens today is that at every start of the server, all checkboxes and tools are reset to their default as per software author.

What I would like is that at every start of the servere, everything would be reset to my liking 😉 .

Something like a yacv_defaults.toml file with a content on these lines:

[ helpers ]
show_faces = false
show_edges = true
show_vertices = false
axis_width = 3
grid_width = 1

[ parts ]
show_faces = true
show_edges = true
show_vertices = false

[colors.helper]
faces = "#FF0000"
edges = "#FFAA00"
vertices = "#000000"

...etc... (the syntax / content does not need to be exactly that, but you get the drift...)

[yeicor]

The server (backend) does not communicate with the frontend to exchange user preferences.

Instead, whenever I made an opinionated design decision that others might want to customize, I listed it here:

yet-another-cad-viewer/frontend/misc/settings.ts

Lines 8 to 48 in 438d315

	let settings = {
	preload: [
	// @ts-ignore
	// new URL('../../assets/fox.glb', import.meta.url).href,
	// @ts-ignore
	// new URL('../../assets/logo_build/base.glb', import.meta.url).href,
	// @ts-ignore
	// new URL('../../assets/logo_build/location.glb', import.meta.url).href,
	// @ts-ignore
	// new URL('../../assets/logo_build/img.glb', import.meta.url).href,
	// Websocket URLs automatically listen for new models from the python backend
	'<auto>', // Get the default preload URL if not overridden
	],
	loadHelpers: true,
	edgeWidth: 0, /* The default line size for edges, set to 0 to use basic gl.LINEs */
	displayLoadingEveryMs: 1000, /* How often to display partially loaded models */
	monitorEveryMs: 100,
	monitorOpenTimeoutMs: 1000,
	// ModelViewer settings
	autoplay: true, // Global animation toggle
	arModes: 'webxr scene-viewer quick-look',
	zoomSensitivity: 0.25,
	orbitSensitivity: 1,
	panSensitivity: 1,
	exposure: 1,
	shadowIntensity: 0,
	// Nice low-res outdoor/high-contrast HDRI image (CC0 licensed) for lighting
	environment: new URL('../../assets/qwantani_afternoon_1k_hdr.jpg', import.meta.url).href,
	environmentIntensity: 1.0,
	// Uniform (1x1 pixel) medium gray background for visibility (following dark/light mode)
	skybox: (window.matchMedia("(prefers-color-scheme: dark)").matches ?
	"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABAQMAAAAl21bKAAAAA1BMVEU4ODiyn42XAAAACklEQVQI" +
	"12NgAAAAAgAB4iG8MwAAAABJRU5ErkJggg==" :
	"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABAQMAAAAl21bKAAAAA1BMVEW6urpaLVq8AAAACklEQVQI" +
	"12NgAAAAAgAB4iG8MwAAAABJRU5ErkJggg=="),
	// Playground settings
	pg_code: "", // Automatically loaded and executed code for the playground
	pg_opacity_loading: -1, // Opacity of the code during first load and run (< 0 is 0.0 if preload and 0.9 if not)
	pg_opacity_loaded: 0.9, // Opacity of the code after it has been run for the first time
	};

All of these settings can be adjusted using URL query parameters, allowing the frontend to load directly with your preferred configuration.

Currently, the available options are limited in scope. For example, you can:

• Toggle all helpers on or off (loadHelpers=true or loadHelpers=false).
• Adjust the edge width globally (edgeWidth=<number>).

Interested users should add their settings here (along with changes to the frontend code) and submit a pull request.

[quasipedia]

Again: in another comment you clarified this project is geared towards your personal use, so I appreciate that you may be unwilling to change this, as it will cost you time (if nothing else to review a PR), but won't bring you any benefit...

For the sake of documenting the thought process though, here a few points why I think a server-side solution would be a more flexible design, should you decide to put more emphasis on other potential users as well:

• If a user has defaults that are significantly different than the default, the URL would become unruly. Even saving it as a bookmark, would require the first time the URL is to be used to be typed (error prone, tedious). A file with a python-friendly syntax (e.g.: JSON, TOML, INI...) would lower the cognitive load.
• At least for me, while some preferences are user-centric (e.g.: thickness of lines, tied to how acute my eyesight is) some are depending on the project: if I use realistic colours for the objects I may have different backgrounds and colours for the edges, if I have few parts I show the joints, but if I have an assembly with 10, I don't, etc.. A file-based solution would allow for project-specific settings.
• A saved bookmark is not portable (in the sense that it lives outside of the project repository and requires extra actions to be replicated on different machines). A file-based solution would be together with the CAD code, checked in in the same repo.

Again: I understand your "low priority" is tied not to "not understanding the user case" but "not interested in investing time on this specific issue", so I respect your choice to de-prio this. 🙂

Would you potentially be open to a PR though? (Not necessarily by me though: I never dabbed in ts before! 😅 ).

[yeicor]

I’m open to reviewing a pull request for this feature if someone would like to contribute.

I’ve also added a CONTRIBUTING.md file to outline the contribution process and encourage community involvement.

[quasipedia]

That is awesome. I have started to look into the code (I am not a professional coder since a VERY long time though, so there is a curve for me to climb before I can contribute, and new technologies - like vue - to learn).

What I would find helpful, provided that you have the time and will to do so, is a high level description of the architecture in the CONTRIBUTING.md file. I'm thinking both the HOW and WHY (for the latter, it should be clear what is "non-negotiable", if anything).

Here I stress the "high level" bit: I'm not looking for a professional enterprise-level full-blown documentation, but a one-pager that can help a newcomer (like me!) to start looking at the code in the right place. Something along the lines of:

• What are the big moving parts (BE, FE, the viewer? tassellation? external libraries?), what is their role in the pipeline and what is the file with their entry-point (like yacv.py for the BE for example).
• How do they communicate which each other (mono-directional? bi-directional? http? web sockets? pulling? pushing? if API based, what are the endpoints...)
• What data is exchanged at each interface (and in which format)
• What is in-scope and not and what is non-negotiable (if anything). Stuff like: this will never support debugging, or use of a certain library over a different one.
• Any guidelines for code style (e.g.: testing or documentation requirements, linter/formatter settings - probably a good idea to include the editorconfig file or equivalent...)