@Dineatriz

This was probably the most technically dense update so far, as I restructured the Learn mode to be modular and implemented a much more powerful calculation engine.
The Learn mode is no longer a single sequence of lessons but now has thematic modules (Ohm’s Law, Series vs. Parallel, and Multimeter in Practice (which is still to come)). Now, when entering Learn mode, you choose the module (1, 2, 3), and Esc always returns to the selection instead of exiting the entire mode.
Until now, the simulator could only perceive a single closed series circuit; it couldn’t build real branches. So, I implemented a new serial/parallel reduction-based engine that can correctly calculate any combination of series and parallel resistors mounted on the screen, including switches and buttons as part of the network. This engine coexists with the old one, and when the circuit has an LED or Motor, it continues to use the series chain logic, but when it’s just a resistive network, it uses the new engine. But there is still a limitation, since “bridge” circuits (which would require Kirchhoff’s Laws) are not supported for now; the program warns when it detects this situation instead of giving an incorrect result.
For now, the series and parallel module has 3 lessons: calculating total resistance in series, in parallel, and physically assembling two resistors in parallel to achieve a target current.
I also fixed a layout problem where longer statements went off the panel; for this, I implemented automatic line breaks that adjust the panel height depending on the text.

As I mentioned in the last devlog, I’m making changes to the learning method. In the last hour, I added things that were really missing from the simulator. I created a new type of lesson, “assemble_circuit,” where instead of typing a number, the user assembles the circuit on the screen and presses Enter for the program to automatically check if the assembled circuit meets the request (e.g., “achieves a current of ~15mA”). The verification uses the existing calculation engine, comparing the present components and the resulting current with what the lesson asks for, with a tolerance margin. While testing this, I noticed that there was still no way to adjust the component values ​​after they were placed (the resistance always stayed at 1000Ω, the battery always at 9V), which made Lesson 5 impossible to complete as planned. Even though I wanted to include this function from the beginning of this project, I hadn’t yet taken the time to do it. So I finally added value editing with the mouse wheel; now hovering the mouse over a resistor or battery and rotating the wheel adjusts the value in real time. The current value now appears below the component name (e.g., “Resistance (470Ω)”) (I wish I could add a screen recording to show this working, but it seems that only screenshots are allowed).
This ended up being a much bigger improvement than just “fixing” Lesson 5, since the simulator became much more realistic and experimentable, as before all components had fixed default values.

I forgot to mention on the last devlog, but answers now have a 5% tolerance if your calculator gives a wierd number for some reason

In this devlog and the next, I will mainly work on the learning mode, because the idea of ​​this simulator is precisely to teach people.
Instead of a single fixed lesson, there is now a list of 4 Ohm’s Law lessons, with increasing difficulty.
When you get a lesson right, pressing Enter again automatically advances to the next one. When you complete all of them, “All lessons completed!” appears and you exit Learning mode automatically.
During the tests I did, I noticed that Lesson 4 asked to calculate the resistance (given the desired voltage and current), but the code only knew how to check current responses, that is, the lesson was structurally inconsistent with the question it asked. So I corrected the Lesson class to support two types of questions (“current” and “resistance”), each with its correct formula, tolerance, and unit. The answer box now shows “mA” or “Ω” depending on what the lesson asks for.

In this devlog I only added things that I felt were missing. I implemented exporting the complete circuit to JSON for each component (type, position, color, inversion state) and specific properties (battery voltage, resistance value, switch state, multimeter mode), plus the wires and probes, all referenced by indexes so that everything can be reconstructed later quickly and without errors. I also implemented reverse loading; it reads the JSON, recreates all the components and ends first, then connects the wires between them in the correct order.
Shortcuts I defined: S to save, L to load.
I had left the saving and loading only sending an output to the terminal with print(), but I preferred to replace that with a visual notification on the screen itself. It’s basically a small box with a message that appears at the top saying “circuit saved” and “Circuit loaded” (in the printouts these messages still appear all in Portuguese because it’s my native language, but later in the project I intend to add support for other languages). This message disappears automatically after 2 seconds, so the user always knows that something has happened without having to look at the terminal.
With this update, I think the simulator is getting a really well-made graphical interface. Now I’ll probably work on adding the “Learn” mode, which currently only exists in the “initial” phase, which is through the terminal.

This devlog took longer than usual (I’ll try to make sure this doesn’t become the norm, even though the last one was already delayed), but at least it had a reason; this was the most technically demanding part of the project so far, especially because of the multimeter.

I made several corrections and refinements, such as the multimeter probes, which previously looked rather unsightly floating and disconnected from the multimeter, but now have a visual wire that always connects them to the instrument body, even when it’s moved across the screen. I also added the ability to invert/mirror components with polarity, LEDs, and batteries; by pressing F while the component is selected, the component flips. This is useful for assembling circuits in a more natural and organized way, without being stuck with a single orientation (and it was annoying me having to have one cable crossing over another). I thought I would do this quickly and easily, but after some attempts, I still had a subtle bug: the electrical logic continued to assume the same orientation, ignoring the visual inversion. That is, even if, after inverting, the + appeared as -, the code still assumed that the polarities were in their original place and therefore did not correspond (I hope that makes sense). So, I had to correct it so that the pins were physically fixed and the… The logic “asking” if the component is reversed, instead of trying to move the pins.

Now, the part that took the longest and also the last thing I did in the code, a multimeter with two modes. The multimeter was very “basic” and I wasn’t liking it very much, so I changed its appearance and decided to change its behavior as well. Now the multimeter has V mode (voltage, measured between two points without interfering with the circuit) and A mode (current, alternating with the M key). The A mode was the biggest challenge, since the two probes could now be part of the electrical circuit itself, that is, I cut a wire, connect each end to one side of the cut, and the multimeter measures the current that passes exactly there, just like a real ammeter. This forced me to rewrite the algorithm that traverses the circuit to know how to “pass through” the multimeter when it is in A mode, but ignore it (not interfere) when it is in V mode.
This involved a lot of experimentation and some positioning bugs along the way. (The probes were placed in the wrong spot, inheriting the position of the palette instead of the position where they were dropped), but now everything is working as you would expect from a real multimeter.

A lot has happened since the last devlog; this was the phase of making the simulator more complete and visually clear. (I apologize for adding so much time to a single devlog, but I kept having ideas and working on them, I didn’t even realize it had been 3 hours without any breakdown.)

In terms of interface and usability, it’s now possible to delete components and wires with the right mouse button (deletes the component + connected wires, or just an isolated wire).
The components are no longer generic rectangles: now they have real electrical symbols, a battery-style cell (with +/-), a zigzag resistor, an LED as a triangle + bar (also with +/-). (I used a bit of AI in this part of the element design to make sure it’s well done and with the correct symbols, since I sometimes get confused with the symbols.)

I also added new components (and I still intend to add more):
Switch, clickable, toggles between on (closed green line) and off (open, red); If switched off, the circuit shows “Open circuit”.
Capacitor, symbolized by two parallel lines, currently “transparent” to the calculation (still without simulation of charge/discharge over time).
Button, like a switch, but only stays on while the mouse holds it down.
Motor, symbolized by a circle with “M”, treated as a series voltage consumer (like an LED, but without requiring polarity or current limit). The motor was what gave me the most trouble because I tried to use it with the same logic as the LED, but to do so I had to rewrite the motor calculation in my code.

As I mentioned before, I rewrote the calculation engine to traverse the real circuit chain starting from the battery (instead of just grouping connected components), and this allowed the simulator to support multiple LEDs in series (summing the forward voltages of all of them), detect LEDs connected backwards (current entering through the cathode), with an explanatory warning, mix different types of “consumers” (LEDs and motors) in the same circuit (the problem that made me want to change this part of the code), and I fixed a bug where a circuit with only a motor (without an LED) showed no results.

At this moment, the simulator already supports 7 different components (battery, resistor, LED, switch, button, capacitor, motor), all with their own symbols, pedagogical error detection, and a calculation engine that traverses the real circuit instead of always assuming the same fixed structure.

Now I want to add a multimeter, which will be different from the others because it’s not another link in the chain, but a measuring instrument that connects to a point of your choice.

I consider this to be the most important milestone so far because I’ve connected the visual interface to the electrical logic. Until now, I had the two parts separate, the “brain” (calculations and warnings) and the interface (drag/drop), but now they work together.

What changed:
Each visual component now has a real electrical object associated below it (a Battery, Resistor, or LED).
I implemented a simple grouping algorithm: it goes through all the wires and discovers which components are connected to each other (even indirectly).
Each connected group is passed to the existing logic (SeriesCircuit), which validates and calculates the circuit.
The result appears in a real-time panel in the corner of the screen: voltage, current, power, and status if everything is okay, or a red warning if there is insufficient resistance or excessive current.
In other words, I can now drag a battery, resistor, and LED onto the screen, connect them with wires by clicking on the pins, and immediately see if the circuit is correct, and if not, understand why and how to fix it.

Since the last devlog, I’ve started working on the graphical interface with pygame (I chose pygame instead of tkinter because it gives more control over drawing and mouse interaction).

What’s already done:

Base window working, with main loop and correct closing.
Components represented as draggable rectangles with the mouse (VisualComponent).
A fixed side palette with Battery, Resistor, and LED. When dragging from the palette to the main area, a copy is created, and the original is always available in the palette.
Each component now has connection pins (left and right), visible as small circles.
I implemented the wires: you click on one pin, then another, and draw a yellow line connecting the two components.

That is, I can already drag a battery, a resistor, and an LED onto the screen and visually connect them with wires. Now I just need to make this visual connection “mean” something, combine it with the electrical logic I already had (voltage/current/power calculation and the pedagogical warnings).

Since the last devlog, I’ve focused on thoroughly finalizing the electrical logic before moving on to the visual interface.

Since then, I’ve completed the circuit validation. Now, in addition to detecting when a resistor is missing, the program also detects when the chosen resistor is too low and the current would exceed the LED’s limit (always with an explanation and suggested value, never just “error”):
“Current above LED limit
With this resistor (100 Ω), the current would be 70.0 mA, but this LED
can only handle up to 20 mA.
💡 Use a resistor of at least 350 Ω.”

I also started the “Learn” mode, creating a Lesson class that generates a statement (e.g., “9V and 1kΩ, what is the current?”), accepts the user’s answer, checks it with a tolerance margin, and always explains the formula used:
“You have a 9V source and a 1kΩ resistor. What will the current be?
Your answer in mA: 9
✅ You got it right!
I = V / R = 9 / 1000 = 9.0 mA”

This project, Learnware, is intended to be an electrical circuit simulator in Python, designed to teach electronics interactively to those who want to work more with hardware, focusing on explaining the why of things, not just showing results.
The ultimate goal is to have an area where you drag and drop components (batteries, LEDs, resistors, buttons, capacitors, motors, Arduino/ESP32, etc.), connect them with wires, and the program calculates everything in real time. There will also be a “Learn” mode with lessons, and later, connection to real hardware (ESP32/Arduino).

So far I’ve created classes for the components (Battery, Resistor, LED) using dataclasses, a SeriesCircuit that connects battery + resistor + LED and calculates voltage, current and power, and the part I found most interesting is that, instead of just giving an “error” when the circuit is poorly assembled (e.g., LED connected without a resistor), the program explains the problem and suggests the correct resistor to use, such as:
⚠️ Excessive current
This LED does not have a resistor to limit the current.

In a real circuit, this can damage the LED.

💡 Try adding a 350 Ω resistor.

And when the circuit is correct, it shows:
Voltage: 9 V
Current: 7.0 mA
LED Power: 0.01 W
Status: 🟢 Functional circuit

(In the initial development phases, everything will be written in Portuguese from Portugal, but I plan to add support for more languages ​​in future updates)

It’s been about 6 days since the last update as I haven’t had much free time to work on the project lately, but I managed to make some good progress today.
In this update, I introduced preview information for non-image files and specific plugins. Previously, the app only displayed a simple preview for images and fell back to showing just the filename for everything else. To make the interface much more informative, I added a new optional method, get_preview_info, to the base plugin contract. Any plugin automatically inherits a default behavior that calculates and formats the file’s size (in KB or MB) alongside its name. Individual plugins can easily override this method to display metadata unique to their format. For instance, the Image Plugin now pulls exact dimensions and displays them right alongside the file size (e.g., 1920x1080 • 2.4 MB). The main window updates dynamically based on the active plugin, instantly giving useful context as soon as a file is dropped into the app.
In the development of this update I found a pretty usefull website full of symbols and wanted to share it here: https://coolsymbol.com/

In this update I added support for STL and 3MF files, making the app even more useful for 3D printing. The new plugin currently includes two actions. The first one shows the model dimensions and volume, while the second estimates the print’s weight and material cost based on the material density, filament price and infill percentage. The results are saved into a text file so they can be easily viewed later. To support this, I also extended the parameter system by adding a new float parameter type. This means plugins are no longer limited to integers or predefined choices and can now request decimal values whenever needed. Adding support for two completely new file formats only required creating a new plugin, without changing the plugin manager or the overall application structure. I also think these features will be genuinely useful for anyone who regularly works with 3D printing models.
This update was very simple and I was able to do it pretty fast(I has already started working on it but forgot to mension in the last devlog)

In this update I added 2 more plugins, .zip and .pdf, I also added support for dropping multiple files at the same time. This allowed me to implement the first action that actually requires more than one file (merge PDF). Now, when you drop a single PDF, the app shows the actions that make sense for one file, like rotate and extract text but if you drop multiple pdfs together, those actions are replaced by merge, which combines all the selected pdfs into a single document while keeping the original order. To make this work, I had to change the plugin architecture so that plugins now receive a list of files instead of just one. This means that every plugin can decide which actions should be available depending on the context, without requiring any changes to the UI. I really like this update because it makes the project much more scalable.
The .zip plugin is pretty simple, it lets you extract a .zip file or convert it into .7z

It’s been a little while since my last update(2 days) because I haven’t had much free time recently, so I’ve only been able to work on this project in short sessions, making small improvements whenever I had the chance.
For this update, I focused on connecting the UI with the plugin system. Now the app can detect the correct plugin for the dropped file, displays messages saying what was done and has options that were missing before, like image dimensions or output format.
Although these aren’t the most exciting features, they’re an important thing to be done, because the application is becoming truly modular, which means future plugins (PDFs, videos, archives, STL files) should integrate with very little additional work.

The idea behind Flow is simple: instead of opening multiple applications to perform common tasks like compressing an image, converting a file, or extracting text from a PDF, users can simply drag and drop a file into Flow and instantly access the actions available for that file type/extension. My goal is to reduce the number of steps required for common tasks.
So far I have designed the overall architecture of the application, created a plugin-based system to make the project easily extensible, implemented a plugin manager that automatically discovers and loads plugins, defined a base FlowPlugin class that all plugins will inherit from, built a simple test plugin to verify that the plugin system works correctly, started developing the graphical interface using CustomTkinter and tkinterdnd2(basically a window that only detects when something gets dropped in there).

This is probably my final update and I’m very proud of how this app ended.
This update was focused on polishing the app to look and work better. I finally added multi-language support and this was what took most of the time because I encoutered some bugs along the way(incorrect translations and displaced things) but now its working great.
Also added a tutorial(only appears the first time you use the app) that explains how to use the app and has a very important warning. You should read it very carefully.
I changed the app behaviour so that now it starts visble until you hit alt+v(before it started “closed).
Although individually small, these fixes significantly improved the application’s overall quality and reliability.

I really liked this update because, even though it took a long time, it basically makes the app look more professional and “modern”.
I focused on improving the user experience by making the interface cleaner, faster and easier to use(but had to fix some of bugs that were occuring for weird reasons).
With this update, managing tags became much more convenient and now, when you are adding a tag you can write a new one or choose between the ones that you already have.
I also improved the search/filtering system. Now you can view all clipboard entries(as always) but you can also show only favorite items or filter them by their tags(I really liked this one because now you can have a lot of items with a tag for a project and view them at once instead of looking for them).
And now what I would like to say that was the biggest improve(but everything on this update was awesome:)), the interface. I completly remade the interface because it was kinda ugly. Now it has a really nice dark theme, with much more recognizable widgets(items) layout, better spacement and aligment and so, a cleaner layout.
The only thing left to add is multilanguage support(for now its in Portuguese but I’ll add English), and I would also like to make a simple “Tutorial”.
FORGOT TO MENTION EARLIER, but I also changed the hotkey to alt+v because ctrl+shift+v would always paste something

In this update, I’ve added two things that, in my opinion, are the most important in this project:
I added a search bar that, as the user types, the clipboard history is filtered, searching both the clipboard content and any assigned tags. To support this, I refactored part of the interface by creating a single function responsible for drawing the clipboard list. This eliminated duplicate code and greatly facilitated future interface updates.
The biggest addition in this update was automatic content detection, whenever something is copied, the application now analyzes it and classifies it automatically. Currently, it can detect youtube links, github links, generic urls, email adresses, code, and, as always, normal text. Each detected type is stored in the database and displayed with its own icon(emojis), making the clipboard history much easier to identify.

During development I encountered an issue where copied code snippets were being detected as plain text instead of source code .After debugging the detection logic and verifying the values stored in the database, I identified and fixed the problem. The application now correctly classifies supported code snippets and displays the appropriate icon.

The code has already achieved its original objective of providing a persistent and more intelligent clipboard history than the default windows clipboard. The only thing left to do is to create a better interface.

I made it work more like a real background application and to achieve this I configured the application to launch when the computer turns on, run silently in the background and keep the shortcut always available.
I also added some simple organization features, Favorites and Tags. Now you can mark an item as favorite by selecting it and pressing “F”, favorite items are displayed with a ⭐ icon, and by pressing “T” you can also add a Tag that is displayed next to the item