You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> The project works on the Vue Simulator and aims at completing the vue-simulator. We have achieved several milestones like Authentication model, a beautiful Release Pipeline for Tauri simulator, version sync for v0 and v1, a brand new Testbench UI and many more. Let's dive into them right away !!**
18
+
> The project works on the Vue Simulator and aims at completing the vue-simulator. We have achieved several milestones like Authentication model, a beautiful Release Pipeline for Tauri simulator, version sync for v0 and v1, a brand new Testbench UI and best of all pushed vue-simulator to production. Let's dive into them right away !!**
19
19
20
20
## Major statures that have been added and merged include:
21
21
- Pushing the Vue-Simulator to production
22
22
- Authentication model for Tauri Simulator
23
+
- Conventional-commits workflow
23
24
- Release Pipeline for Tauri Simulator
24
25
- An improved Testbench UI/UX
25
-
- Vue-Simulator integration with the primary codebase
26
26
- Legacy feature sync to v0 and v1
27
27
28
28
---
@@ -31,15 +31,60 @@ Welcome to my final blog for Google Summer of Code 2025 for the project **Deskto
31
31
32
32
---
33
33
# 1. Pushing Vue-Simulator to Production
34
-
**Deliverable:** We have finally pushed the vue-simulator to production, we faced a lot of tricky problems along the way but finally after 4 gsoc projects we are here with vue-simulator in the Production. The users can use legacy simulator by just clicking on the simulator at the homepage(URL - `https://circuitverse.org/simulator`). For using vue simulator they need to change the URL to `https://circuitverse.org/simulatorvur` which is equivalent to `https://circuitverse.org/simulatorvue?simver=v0`. This sets the `v0`(base) version for vue-simulator. Users can also change the URL to `https://circuitverse.org/simulatorvue?simver=v1`, this sets the version to `v1`. We will be using `v1` to rollout the beta updates for new features, after thorough testing and positive user response we'll move those updates to `v0`. Users can freely choose to work on either of the three versions,`legacy`,`v0`,`v1`.<br>
34
+
---
35
+
**Deliverable:** We have finally pushed the vue-simulator to production, we faced a lot of tricky problems along the way but finally after 4 gsoc projects we are here with vue-simulator in the Production. The users can use legacy simulator by just clicking on the simulator at the homepage(URL - `https://circuitverse.org/simulator`). For using vue simulator they need to change the URL to `https://circuitverse.org/simulatorvur` which is equivalent to `https://circuitverse.org/simulatorvue?simver=v0`. This sets the `v0`(base) version for vue-simulator. Users can also change the URL to `https://circuitverse.org/simulatorvue?simver=v1`, this sets the version to `v1`. We will be using `v1` to rollout the beta updates for new features, after thorough testing and positive user response we'll move those updates to `v0`. Users can freely choose to work on either of the three versions,`legacy`,`v0`,`v1`, The working of the Embed view can be seen in the video attached below.
36
+
37
+
---
35
38
36
39
**Let's tape the tale:** Pushing the vue-simulator to production has been the biggest objective for this project. The vision of vue-simulator being giving users option to use the various versions at will gave rise to a lot of contengencies. Let's start with the first major bug we faced: <br>
37
40
38
41
## 1A. The Embed-Vue failure [#643](https://github.com/CircuitVerse/cv-frontend-vue/issues/643)
39
42
40
-
When a user saves a circuit it can be viewed in the Dashboard. When going into the Embed view i.e. when we click on `more` under the circuit we are directed to another page where we see the Embed view. The issue was that the paths were only handled properly for the legacy simulator causing the whole simulator being loaded in the Embed area instead of just a lighter version of the simulator like how it is meant to be for embedded format. To fix this we had to really dvelve into the codebase. We first tried to create an extra column in the schema to store the `simulator_version` but midway through that approach we realised that we might already have some varible like that being stored somewhere. After a lot of prmpts on the `rails console` we found out that we were transmitting a variable called `simulatorVersion` from the vue simulator while trying to save the ciruit. We looked more into it and this is the solution we came across: <br>
43
+
When a user saves a circuit it can be viewed in the Dashboard. When going into the Embed view i.e. when we click on `more` under a circuit we are directed to another page where we see the Embed view. The issue was that the paths were only handled properly for the legacy simulator causing the whole vue-simulator being loaded in the Embed area instead of just a lighter version of the simulator like how it is meant to be for the embedded format. To fix this we had to really delve into the codebase. Here on is the crux of the situation and how we tackled it. <br>
44
+
45
+
#### Problem
46
+
47
+
- The `simulatorVersion` was not stored as a separate column in the database. Instead, it lived inside a JSON field (`project_datum.data`).
48
+
- Many older projects did not have `simulatorVersion` defined at all, since they were created using the legacy simulator.
49
+
- Because of this, we could not reliably read the field directly without risking errors or breaking compatibility.
50
+
51
+
#### Solution
52
+
53
+
**Step 1:** Extract the simulator version from project data
54
+
We added logic in the **Project model** to safely read `simulatorVersion` from the JSON field.
55
+
- If the field exists, we use its value.
56
+
- If it does not exist (as in legacy projects), we default to `"legacy"`.
57
+
58
+
This gave us a consistent way to determine whether a project was created with the new Vue simulator or the old legacy one.
59
+
60
+
**Step 2:** Add a helper method to detect Vue simulator projects
61
+
In the model, we introduced a method that checks the simulator version and returns whether the project is a Vue simulator project or not.
62
+
- Vue simulators are identified by versions `v0` and `v1`.
63
+
- Legacy simulators fall back to the default `"legacy"` tag.
64
+
65
+
**Step 3:** Decide the embed path in the controller
66
+
In the **Project controller**, we used the helper method to set the correct embed path.
67
+
- If the project uses Vue simulator, we assign the Vue embed path.
68
+
- Otherwise, we assign the legacy embed path.
69
+
70
+
This kept the decision-making clean and consistent.
71
+
72
+
**Step 4:** Render the correct simulator in the view
73
+
In the **show page**, instead of hardcoding the iframe path, we used the path determined by the controller.
74
+
This ensures that the correct simulator (legacy or Vue) is embedded based on the project’s version.
75
+
76
+
---
77
+
78
+
**Why this approach works**
79
+
80
+
- It supports both old and new projects without breaking anything.
81
+
- It avoids errors when `simulatorVersion` is missing.
82
+
- It centralizes the version-handling logic inside the model, keeping the controller and view simple.
83
+
- It makes the application future-proof, since any new versions can be handled in one place.
# 2. Authentication Model for Web and Tauri Simulator
69
-
**Deliverable:** Added an Authentication model to Tauri Simulator. For the Tauri simulator the users now will face an Authentication model specifically made for the application. They only have to login once, their profiles will be stored up until they themselves log out from the application.<br>
114
+
---
115
+
**Deliverable:** Added an Authentication model to Tauri Simulator. For the Tauri simulator the users now will face an Authentication model specifically made for the application. They only have to login once, their profiles will be stored up until they themselves log out from the application.
116
+
117
+
---
70
118
**Technical Tale:** The reason we needed a seperate Authentication model for vue simulator is because of Tauri. Earlier we were simply changing the `path` in the `URL` to direct to the Login page of Circuitverse for Authentication. This particular method fails for the Tauri simulator because:<br>
71
119
- It is a standalone simulator with no connection to the primary codebase.
72
120
- We want the Tauri simulator to also work when user is offline.
@@ -124,8 +172,11 @@ These are some of the snaps of the Authentication model -<br>
**Deliverable:** Now the commits to the cv-frontend-vue require to follow [`conventional-commits`](https://www.conventionalcommits.org/en/v1.0.0/) this is to add more meaning to commits for both humans and machines.
178
+
179
+
---
129
180
**Why and How we did it:** We have added `conventional-commit` to the workflows, this ensures smoothness in the Automation for version tag generation. This also helps give the maintainers a good holistic view of where the simulator stands at, in-turn helping them choose the `minor`,`patch` or `major` version bump in the Release. ([PR #656](https://github.com/CircuitVerse/cv-frontend-vue/pull/656))<br>
130
181
From here on the commits made by everyone would be needing to follow the [conventional-commits](https://www.conventionalcommits.org/en/v1.0.0/), Some of them are as follows:
131
182
#### Types
@@ -144,7 +195,10 @@ The **type** indicates the nature of the change:
144
195
145
196
146
197
# 4. Automating Cross-Platform Desktop Releases
147
-
**Deliverable:** An Automated Release pipeline has been added to the vue-simulator. With one click by the maintainers a Release is created and assets(Artefacts for `Windows`, `Mac` and `Linux` subsystems) are attached with the Latest Release under `Releases` heading on cv-frontend-vue primary codebase. There is also another file called `CHANGELOG` that is created, it holds the logs of current and all of the previous Releases.<br>
198
+
---
199
+
**Deliverable:** An Automated Release pipeline has been added to the vue-simulator. With one click by the maintainers a Release is created and assets(Artefacts for `Windows`, `Mac` and `Linux` subsystems) are attached with the Latest Release under `Releases` heading on cv-frontend-vue primary codebase. There is also another file called `CHANGELOG` that is created, it holds the logs of current and all of the previous Releases.
200
+
201
+
---
148
202
**How we did it? -** One of the key deliverables for the GSoC project was a reliable release pipeline for the CircuitVerse desktop app. We initially explored fully automated tools like semantic-release and release-it!, but they offered less manual control than we needed. The ideal solution needed to balance powerful automation with maintainer oversight.
149
203
150
204
The breakthrough was using GitHub Actions' workflow_dispatch. This allows us to trigger the release manually, providing input on the version type (major, minor, or patch), giving us the perfect blend of automation and control. This approach culminated in the final workflow that now powers our desktop releases.
@@ -185,7 +239,7 @@ From there, everything is automated. Within minutes, a new, cross-platform relea
185
239
186
240
{{< video src="/videos/Harsh_Rao/release-pipeline-final.mp4" controls=true preload=true >}}
187
241
188
-
# The Artistic new Testbench UI
242
+
# 5. The Artistic new Testbench UI
189
243
190
244
This has been the artistic side of the project. We have had the Testbench UI for a while now, upto now it had recieved 2 major UI revamps during some of the previous GSOC projects. This time we went outside the current colour palette a bit. We have used the classic Circuitverse green with white, which gives it a soft and user-friendly look.
191
245
@@ -199,9 +253,11 @@ Here is a video showcasing the working of the new Testbench
199
253
200
254
{{< video src="/videos/Harsh_Rao/Testbench.mp4" controls=true preload=true >}}
201
255
202
-
# 5. Legacy version sync to versions v0 and v1
256
+
# 6. Legacy version sync to versions v0 and v1
257
+
---
258
+
**Deliverable:** This was a requirement for Versioning of vue-simulator. This is not a new feature but rather a major pillar of versioning.
203
259
204
-
**Deliverable:** This was a requirement for Versioning of vue-simulator. This is not a new feature but rather a major pillar of versioning.<br>
260
+
---
205
261
**And what is that major Pillar?** After the previous year's GSOC project on implementing version control, we needed to sync the legacy simulator versions to the versioned folders while syncing the changes in the src folder to v0 and v1 too. This was carried out in 3 steps.<br>
206
262
**Step 1:** This step was brute-force copying all of the files from the `src` folder to the versioned directories `v0` and `v1`.
207
263
**Step 2:** Then we compared all of the changes that existed in `src` and not in `v0` and `v1`. We came across many small features that were missing for `src` which needed to be re-written, for eg: the version mismatch dialogue for the vue simulator in `openOffline.vue`. ([PR #599](https://github.com/CircuitVerse/cv-frontend-vue/pull/599))
@@ -215,7 +271,7 @@ Here is a video showcasing the working of the new Testbench
0 commit comments