Critical Flaws in V2 IDE

Development Tools IDE 2.x
1

I have found two problems with the V2 IDE, one serious and one annoying.

  • CRITICAL, If, for some reason the sketch that is open in the IDE happens to not be owned by the logged user, neither using the save option in the file menu nor responding YES to a save prompt when closing the IDE, the file DOES NOT save and there is NO warning message. Hence all edits are LOST.

  • Annoying, the V1 IDE is superior in respect to the serial monitor; it can be opened in a separate window. In V2, the serial monitor occupies the lower have of the window restricting the number of lines that are visible in the editor at any given time. The floating window should be restored.

2

I'm using a single user environment in Windows so can't confirm the first point.

The second point has been known since inception of IDE 2.x (release candidates). The workaround is to open a second instance of the IDE and maximise the Serial Monitor in there; that way it's very similar to IDE 1.x.

I'm glad that you did not complain about the fact that one can not copy the full content of the serial monitor, only the visible part.

3

Hi @DoctorDan. Thanks for your feedback.

Although it is not currently possible to move Serial Monitor to a dedicated window, it is already possible to move it to the right side of the main Arduino IDE window instead of to the bottom. You might prefer that placement as it provides more vertical space.

I'll provide instructions you can follow if you want to configure the Serial Monitor location to the right side panel:

  1. Press the Ctrl+Shift+P keyboard shortcut (Command+Shift+P for macOS users) to open the "Command Palette".
    A menu will appear on the editor toolbar:
    image
    image440×112 11.9 KB
  2. Select the "Preferences: Open Settings (UI)" command from the menu.
    ⓘ You can scroll down through the list of commands to find it or type the name in the field.
    A "Preferences" tab will open in the Arduino IDE main panel.
  3. Type arduino.monitor.dockPanel in the "Search Settings" field of the "Preferences" tab.
  4. Select "right" from the menu under the "Arduino › Monitor: Dock Panel" setting.
  5. Close the Preferences tab by clicking its X icon.

The Arduino IDE developers are tracking the request here:

If you have a GitHub account, you can subscribe to that thread to get notifications of any new developments related to this subject:

screenshot of Subscribe button
screenshot of Subscribe button402×437 20.3 KB

4

Thanks, that will be helpful - after I recover3 hours of lost work due to the first problem. Hope my memory doesn't fail me now

5

As you may have guessed I'm using linux. I have several old laptops (12 and years old) that I use for arduino development because I csn easily tske them to where my iot stuff is mounted. They don't run windows very well anymore.

7

Arduino ide 2 is running extremely slow on macbook pro 2019 intel with ewgb ram and on win 11 with ryzen 7 and 64 gb ram. Would faster machines improve this?

From Perplexity:
Faster machines may not necessarily improve the performance of Arduino IDE 2.x significantly, as its slowness is often due to software inefficiencies rather than hardware limitations. The IDE’s reliance on Electron, single-threaded compilation processes, and potential compatibility issues (e.g., running on Intel or ARM-based Macs via Rosetta 2) are common bottlenecks.

I understand that electron is nice for developer but every app that I use that has switched tp electron rns worss and is harder to use because of UI limitation of. The platform.

So, I'm questioning the long-term merits of the electron approaxh over weiring natice code.

Also from perplexity chat:
If the Arduino IDE were rewritten in a native language (e.g., C++, Rust, or Go), it could indeed be cross-compiled for Windows, macOS, and Linux on both Intel and ARM architectures. Here’s how this could work:
Language Suggestions
1. C++: A widely-used language for cross-platform development. It has mature toolchains (e.g., GCC, Clang) and libraries like Qt for GUI development.
2. Rust: Offers memory safety and modern concurrency features. Its cross-compilation support is robust with tools like cargo.
3. Go: Simplifies cross-compilation with built-in support for multiple platforms and architectures.
Cross-Compilation Feasibility
• Cross-compilation is a well-established process where code is compiled on one platform to run on another. For example:
• Use GCC or Clang to target specific architectures like x86_64 or ARM.
• Docker containers can help standardize builds across platforms, especially for macOS users.
• Tools like CMake or Meson can simplify build processes for multi-platform projects.
Challenges
1. Dependencies: Managing third-party libraries consistently across platforms can be complex.
2. GUI Frameworks: A cross-platform GUI framework (e.g., Qt, GTK) would need to be adopted to avoid writing separate interfaces for each OS.
3. Testing: Ensuring consistent behavior across all supported platforms requires extensive testing.
Benefits
• Native code would likely improve performance and reduce memory usage compared to an Electron-based IDE.
• Cross-compilation would allow developers to release binaries for all major platforms and architectures efficiently.

Just a hthought, because for methe current ide has become virtuallu unusable.