multiple stability problems with 0.11 on macos 10.13.6 and maybe others ...

[paschlie]

Sorry, but I can't reliably duplicate most of these problems observed over the past several days:

• The ide often looses its mind after running for several hours, and then can't be quit or save any recent edits; so it has to be force-quite, and edits are lost unless first cut and pasted elsewhere.

• Similarly the ide appears to get confused about the state of the serial port emulated over usb; seemingly trying to open multiple connections, with most failing. (sometimes fine, sometimes not); and on occasion loosing initial serial data even if attempting to first sync using "while (!Serial){};" ?

• Lastly I'm not sure if it's intentional, but the ide quits if the last open window is closed, which is annoying because if a new file is opened before the current one is closed, any console messages on one, also appears within the other file's console display as well; so it becomes a bit confusing which open file the messages are meant for?

[ubidefeo]

hi @paschlie thank you for this report

The ide often looses its mind after running for several hours, and then can't be quit or save any recent edits; so it has to be force-quite, and edits are lost unless first cut and pasted elsewhere.

we are aware of this, and yesterday made some progress searching for the source of this particular issue. Hope to tackle it soon

Similarly the ide appears to get confused about the state of the serial port emulated over usb; seemingly trying to open multiple connections, with most failing. (sometimes fine, sometimes not); and on occasion loosing initial serial data even if attempting to first sync using "while (!Serial){};" ?

the serial monitor is handled through the underlying CLI and forwarded to the IDE's UI, we'll improve it over time as more reports (internal and external) come through

Lastly I'm not sure if it's intentional, but the ide quits if the last open window is closed,

very much intentional, as this is the behaviour of our Java IDE and we're aligning one's functionalities to the other: last window closed, IDE quits

which is annoying because if a new file is opened before the current one is closed, any console messages on one, also appears within the other file's console display as well; so it becomes a bit confusing which open file the messages are meant for?

this buffer sharing between windows is something we're actively looking into, because it's source of confusion to the user (I have fallen for it myself). When it comes to UX we're aware of many faults and have active tasks concerning them.

The kind of report you posted here is extremely useful to us, so please keep testing when you have time. Also as of yesterday we also have change-log notes for each Nightly Build, which will help tracking down if a specific issue has been resolved.

Thanks again for the feedback 🙌

[ubidefeo]

@kittaakos I know we have these tasks already but I'll still make you an assignee for this so you can keep track and close it when it's time

[paschlie]

Regarding: "Lastly I'm not sure if it's intentional, but the ide quits if the last open window is closed," Responce: "very much intentional, as this is the behaviour of our Java IDE and we're aligning one's functionalities to the other: last window closed, IDE quits"

As it seems very awkward to have to leave an editor window open to open another project file from within the IDE (finding it seems much more natural to close a current project file, prior to opening another), please reconsider this decision. Currently even if I close all files within a currently open editor window, prior to opening another, a new editor window is opened, leaving the prior empty window open for me to close; which seems like a lot of needless steps just to switch project files within the IDE. Overall the simpler solution would seem to simply not quit the IDE when a project is closed, as I suspect many would prefer who often work on multiple projects or versions there of, allowing more recent projects to be selected via the ide's menu.

Not to mention what when the ide is opened, it automatically opens the last open file, which is fine, but when the user then closes the window (wishing to actually open a different project), the ide quits, and then the user has to start all over again with the same results).

[ubidefeo]

@paschlie I understand your frustration when it comes to this particular one. As we move towards a 1.0 release we're trying to incorporate as much as possible of the Java IDE's behaviour, and this one (which has been a gripe of mine which I had to make peace with) has been brought over.

Let me create a task for this to examine with the team, maybe we could introduce a setting in preferences that can mimic this behaviour or leave the IDE open for a new project to be started (or not).

I believe it's a good suggestion for advanced users, although it would probably default to the current behaviour to accommodate for beginners' needs. Remember, we've all been beginners at some point :)

[paschlie]

@ubidefeo I may be wrong, but suspect enabling the IDE to remain running until explicitly quite would be the expected behavior for even "beginners". (Maybe an open file dialog/window should appear upon the closing of the last open file/window, to conveniently allow the user to open or begin a new project; which if dismissed without doing so, the app will then automatically close.)

Further, especially for beginners, the IDE should minimally enable the convenient opening of any header file #include'd by the currently open file for review (initially "read-only" to prevent accidental modification, but which may be explicitly enabled if desired).

Currently I, and suspect many others, end up having to use to use a text editor in addition to the IDE to view/modify supporting files/libraries used by the current sketch. This should not be necessary, and is certainly not helpful for beginners, who would likely greatly benefit by being able to conveniently review the header file content relied upon by their code.

I'd even guess that it may be a good idea to disable the silent/invisible automatic inclusion of header files in Arduino projects, such that at least #include is required at the beginning of each sketch (which may itself include other library headers as may be desired by default), so the beginner understands that the functions that they're calling don't magically appear, but in fact are specified in header files which they should be able to easily inspect, and thereby better understand what's going on.

However regardless, I know the development team likely already has more than enough on their plate, so please just consider the above at least one person's opinion. Your efforts are appreciated.

[ubidefeo]

hi @paschlie

There's a huge distinction between "beginners who are curious and wants to dig in" (more hacky that the majority) and "beginners who want to dip their toes in the pool before jumping in... maybe 15 minutes later". You probably are (like me) one who wants to quickly know what's behind the scenes, but this is not true for the majority of our users who spend their time doing copy/paste from examples, tutorials and hack their way around slowly.

We struggle to preserve the simplicity of the tool at a level that very rarely scares new users off. I started there, in 2006, and had never touched a line of C. I didn't even know what a header was, and later on found myself struggling with understanding why you'd need a header and a c(pp) file. This didn't scare me off, as I was already programming other languages, but having been teaching for 20 years (arduino since 207) I can assure you that many novices get confused pretty easy.

This is mostly related to showing includes and letting libraries be edited.

As per the Pro editions of our tools we're working towards an IDE in which advanced users can edit whatever they please and dig into libraries, hidden includes and so on. When it comes to offering a basic version of the IDE we'll have to maintain the paradigms that have worked and still work very well with our new users, hence some things while up for discussion and clearly deserving a bit of UX/UI love, will stay close to the legacy in their initial iteration.

I really appreciate your feedback, it's food for thought. Hope you'll want to keep testing this product as we move forward and will feel comfortable in expressing your opinion and ask for things you consider enhancements. Goes without saying that if a request for enhancements receives a large consensus we'll put it up for discussion, like it is in every community-driven project :)

[paschlie]

@ubidefeo Thank you for your detailed explanation.

Admittedly I may no longer appreciate what a beginner needs; as I began programming using teletypes, card readers/writers and paper tape for source code storage well over 40 years ago. Thanks for your patience and continued efforts to make a nice tool better.

[ubidefeo]

It is my pleasure, @paschlie You seem to have started a little before I did (I'm generation C64) We'll keep crunching, hoping to get our ideas out and have them influenced by people like you.

Cheers ubi

[per1234]

The ide often looses its mind after running for several hours, and then can't be quit or save any recent edits; so it has to be force-quite, and edits are lost unless first cut and pasted elsewhere.

This has been fixed.

the ide appears to get confused about the state of the serial port emulated over usb; seemingly trying to open multiple connections, with most failing. (sometimes fine, sometimes not); and on occasion loosing initial serial data even if attempting to first sync using "while (!Serial){};" ?

I haven't been able to reproduce this with the latest version of the Pro IDE so I think its fixed now.

the IDE should minimally enable the convenient opening of any header file #include'd by the currently open file for review (initially "read-only" to prevent accidental modification

You'll be happy to learn that the latest version of Arduino Pro IDE does have this capability via the context menu's "Go to definition" and "Peek" (though of course it's still in the alpha development phase). But it's not limited to the header files. You can use it with any code! I agree that making the underlying code more accessible to the curious, yet read only to prevent the accidental introduction of confusing bugs, will be very valuable for learning.

Since the remaining issues you reported are the intended behavior, I'll go ahead and close this as resolved. If you give the the new 0.1.4 release of Arduino Pro IDE a try and find that the issues are still occurring, feel free to comment here and we'll investigate.