[TODO] Add scale unit selector for x3d exporter #18

New Issue

Cedric Steiert · 2024-09-10T00:41:40+02:00

Cedric Steiert commented

2024-09-10 00:41:40 +02:00

Similar to the importer (added in #16) the x3d exporter should also have a unit type selector for consistency reasons.

Importer:

Exporter (currently only scale param):

Similar to the importer (added in https://projects.blender.org/extensions/io_scene_x3d/pulls/16) the x3d exporter should also have a unit type selector for consistency reasons. Importer: ![grafik](/attachments/4719caf7-1d5b-4d51-aabb-4357c0b9cfc3) Exporter (currently only scale param): ![grafik](/attachments/5a49d07d-35e1-4be1-aaf4-8ba1f45eee0d)

grafik.png

7.5 KiB

grafik.png

6.9 KiB

Cedric Steiert added the

enhancement

task

labels 2024-09-10 00:41:40 +02:00

Cedric Steiert changed title from ~~Add scale unit selector for x3d exporter~~ to [TODO] Add scale unit selector for x3d exporter

2024-09-10 00:51:49 +02:00

Hombre57 self-assigned this 2024-09-10 08:59:45 +02:00

Hombre57 referenced this issue from a commit

2024-09-12 21:01:36 +02:00

Fix issue #18: Add scale unit selector for x3d exporter

Cedric Steiert referenced this issue

2024-09-12 22:33:45 +02:00

[TODO] Implement wrl exporter #9

Cedric Steiert commented

2024-09-15 01:14:42 +02:00

Hi, just tested your branch, works perfectly. Want to merge it to master? Or are there any unfinished tasks?

Hombre57 commented

2024-09-15 12:48:07 +02:00

Hi @Bujus_Krachus, thanks for the test. I merged this simple feature. Let me know if you want to merge branches yourself for now on.

Hombre57 closed this issue

2024-09-15 12:49:18 +02:00

Cedric Steiert commented

2024-09-15 13:22:02 +02:00

Tbh i genuinely don't care. Do whatever feels right.

In my opinion minor fixes/feature additions (like this one) etc. that don't require a lot of testing or code style review can be comitted or merged directly to master by the author (if the commit rights to teh repo exist).
Other changes, e.g. longer lasting development (WIP) or error prone changes (when not sure it works), are better off with a Pull Request (for review of functionality and code style); then the merge can happen by both reviewer and author, depending on who makes the last changes/comments.

On a side note: I personally usually prefer working directly on master branches, especially if it's ongoing development of the app, as other code parts may depend on it. More often than not i don't see the point in creating the so called and beloved feature branches, they often result in stale branches and merge conflicts later on.

Tbh i genuinely don't care. Do whatever feels right. In my opinion minor fixes/feature additions (like this one) etc. that don't require a lot of testing or code style review can be comitted or merged directly to master by the author (if the commit rights to teh repo exist). Other changes, e.g. longer lasting development (WIP) or error prone changes (when not sure it works), are better off with a Pull Request (for review of functionality and code style); then the merge can happen by both reviewer and author, depending on who makes the last changes/comments. On a side note: I personally usually prefer working directly on master branches, especially if it's ongoing development of the app, as other code parts may depend on it. More often than not i don't see the point in creating the so called and beloved feature branches, they often result in stale branches and merge conflicts later on.

Sign in to join this conversation.