I am really not happy with the Ide 2.1
The startup time is 3 to 5 times higher than Ide1.8.19
The serial monitor window is not a seperate window but cover the coding
Save is not anymore easy to click
The worst ...... my file names get changed and strange date figures are added
Hi @classic. I'm sorry that you were not satisfied with Arduino IDE 2.x. Thanks for taking the time to share your feedback.
The Arduino IDE developers are tracking the request to move Serial Monitor to a dedicated window as it was in Arduino IDE 1.x here:
There is some related work in progress now to at least mitigate the negative user experience for some by allowing the Serial Monitor to be moved from the bottom to the right side of the IDE window:
I suggest enabling the "Auto save" preference. If you do that, Arduino IDE will automatically save changes as you edit your sketch. This may be more convenient if you typically manually saved frequently enough to feel the need for a dedicated button on the toolbar.
In case you want to retain control over when changes are saved, I recommend using the keyboard shortcut (Ctrl+S). Once you get used to using it, you will find this is even far more convenient than the button because you can very quickly trigger a save without even having to move your hand off the keyboard.
I'm not sure what you mean by this. I would be happy to investigate if you can provide detailed instructions I can follow to reproduce the behavior.
My original file name: Project-2021-10-v1.5-Attenuator-240x240
when I saved the file a new name was given:
_Project_2021_10_v1_5_Attenuator_240x240_copy_20230628094057
That does not qualify as the "detailed instructions I can follow to reproduce the behavior" I requested.
Did you do a "Save...", or did you do a "Save As..."? If you did a "Save As...", then this is the normal and expected behavior when the folder already contains a sketch of that name.
If you only want to save the sketch in place, then just select File > Save... from the Arduino IDE menus and it will work as expected. File > Save As... should only be used when you want to save a copy of the sketch with a new name.
That is definitely unexpected. I tried it and am not able to reproduce the problem.
By the way, the replacement of non-alphanumeric characters in the original filename with underscores when "Save As..." generates a unique default name in the case of a collision is a known bug:
I have used IDE 1.x now for several years.
I have been looking forward to 2.x
I really dont understand why I have to report these problems.
I have spend several hours trying to setup / solve the problems - but NO.
The visual changes i really lived because my eyes are NOT happy with normal white ......
But I have to decline all the other problems with 2.x as for now.
Because if I am the only one with this ..................I will stay with the IDE 1.x
The rename on save as I understand it stampes the file with _year,month,day,hour,minute,seconds. I like that feature as I do it a lot manually but I also understand why many do not. Make an option and most will be happy. I still use 1.8.18 or 1.18.19 on Linux machines, they work ok.
Really? mucking with files names is normal and expected for "save as"?
I would definitely say no to that.
Maybe it is the expected behavior for IDE 2.x for the developer who wrote the code to work like that, but I've never seen an app muck with a file name when using "save as".
(IDE 1.x doesn't do this)
The behavior I'm accustomed to is that when you do "save as", the app doesn't muck with the file name but then brings up a file manager type window in the directory where the original file exists (or sometimes in a fixed location or a location where the last "save as" was done) and then the user can navigate around in the file system for a place to save the file, can create new directories and/or change the name if he wants to.
But if he doesn't change the name and attempts to save on top of the original / existing file, the app tosses up a dialog box stating that the file exists and asks the user if he wants to replace it. And the user is allowed to say yes / confirm to do that.
THAT is the behavior I would expect for "save as" since that is what other apps do including IDE 1.x
I would not expect the IDE 2.x app to have a nanny mode mucking with my file name in an attempt to protect / prevent me from overwriting over my original file.
where I brought up the bug of using an external editor on library example sketches not working. This appears to be due to the code in IDE 2.x going out of its way trying to prevent users from modify a library example sketch.
There are a lot of hidden and unexpected behavior related to this IDE 2.x nanny / guardrail protection mode related to library example sketches.
Here is my guess as to what is happening @classicdesign is working on an example sketch down in a library
He goes to save the sketch and gets a very unexpected behavior, a behavior that is not only very different to the behavior in IDE 1.x but also annoying, and unhelpful.
This likely due to the IDE 2.x nanny mode code that tries to prevent a user from overwriting a library example sketch combined with the IDE renaming files that have certain characters in them.
I see similar behavior as @classicdesign is seeing if I bring up sketch using [File]->Examples... method to load the sketch into the IDE and then use "save".
That is that the IDE silently and unexpectedly decides to rename the file when saving the sketch and brings up a "save as" dialog when just doing a "save" whenever there is a dot in the sketch file name.
Also, whether you use "Save" or "Save As" or "CTRL-s" you get the same behavior when a library example sketch is involved.
That is the IDE mucks with the library example sketch file name and brings up a "save as" dialog, including when just doing a "save"
I'm guessing that the "copy" part in the file name may be related to something happening with auto save interacting with the IDE 2.x nanny mode file renaming.
As you explained in the thread with me, the IDE 2.x nanny mode code, silently and unbeknown to the user, makes a copy of the sketch whenever the sketch is library example instead of working on the actual sketch file.
This design implementation is creating unexpected and annoying behaviors.
In terms of these new / different behaviors between 1.x and 2.x , as I stated in the other thread, just because the IDE 2.x code may have been intentionally implemented to work that way does not mean that a user would expect or even want it to work that way.
Sorry, but I had to say that 