I have multiple monitors on my computer. How can I use the serial monitor in a separate window, like in version 1.8?
Thomas
4 Likes
Hi @thomas_ftl . Currently, the Arduino IDE 2.x Serial Monitor can only be used as part of the IDE window.
The Arduino IDE developers are tracking the need to rework this as a separate window like how the Arduino IDE 1.x Serial Monitor works:
opened 07:48PM - 29 Mar 21 UTC
type: enhancement
topic: code
topic: serial monitor
### Describe the request
Allow **Serial Monitor** to be placed in a dedicated… window separate from the primary Arduino IDE window.
🙂 It will be possible for the user to control the display location of the Serial Monitor separately from the primary Arduino IDE window according to their needs and preferences.
🙂 This will provide feature parity with the Arduino IDE 1.x Serial Monitor.
### Describe the current behavior
Serial Monitor is a view in the bottom panel of the primary Arduino IDE window.
🙁 It is not possible to move Serial Monitor to a separate screen in order to dedicate all space on the primary screen to the Arduino IDE editor.
### Arduino IDE version
#### Original report
2.0.0-beta.4
#### Last verified with
2.0.1-snapshot-32d904c
### Operating system
All
### Operating system version
Any
### Additional context
The requested "tear off" capability would probably make sense for other windows ("**Output**" view) too.
#### Other requests
- https://github.com/arduino/arduino-ide/issues/1799
- https://github.com/arduino/arduino-ide/issues/1268
- https://github.com/arduino/arduino-ide/issues/755
- https://forum.arduino.cc/t/making-the-serial-console-a-dockable-screen-again/1079586
- https://forum.arduino.cc/t/ide-2-0-3-undocking-serial-monitor/1063170
- https://forum.arduino.cc/t/arduino-ide-usb-serial-terminal-issues/1049458/13
- https://forum.arduino.cc/t/how-to-get-all-my-1-18-19-libraries-installed-in-2-0-1/1050248/3
- https://forum.arduino.cc/t/serialmonitor-74880-baud-rate-in-ide-2-0-1/1046886
- https://forum.arduino.cc/t/windows-the-serial-monitor-window-needs-to-pop-out-please/1036538
- https://forum.arduino.cc/t/using-v-2-0-serial-monitor-print/1034093
- https://forum.arduino.cc/t/arduino-2-0-0-macos-unexpected-differences/1033549
- https://forum.arduino.cc/t/2-0-keyboard-shortcuts-dont-work/1033105/11
- https://forum.arduino.cc/t/arduino-ide-2-0-0-available-for-download/1031651/17
- https://forum.arduino.cc/t/serial-monitor-in-a-separate-window/1031455/1
- https://forum.arduino.cc/t/serial-monitor-in-a-separate-window/1031455/3
- https://forum.arduino.cc/t/serial-monitor-in-a-separate-window/1031455/4
- https://forum.arduino.cc/t/changing-ide-fonts/1028827
- https://forum.arduino.cc/t/serial-monitor-issues-hopefully-fixed-before-release/1026548
- https://forum.arduino.cc/t/serial-monitor-in-seperate-window/1022661/1
- https://forum.arduino.cc/t/serial-monitor-in-seperate-window/1022661/2
- https://forum.arduino.cc/t/serial-monitor-in-seperate-window/1022661/5
- https://forum.arduino.cc/t/automatic-build-external-screen-for-serial/1013958
- https://forum.arduino.cc/t/serial-monitor-with-new-ide/1010684/10
- https://forum.arduino.cc/t/ide-2-0-rc5-serial-monitor-problems/978293
- https://forum.arduino.cc/t/serial-monitor-characteristics-fail/943590
- https://forum.arduino.cc/t/how-to-dock-serial-monitor/942477
- https://forum.arduino.cc/t/how-to-dock-serial-monitor/942477/12
- https://forum.arduino.cc/t/no-support-for-esp32-boards-manager-2-01/940115/5
- https://forum.arduino.cc/t/first-impressions-and-comments/930873
- https://forum.arduino.cc/t/missing-serial-monitor-and-serial-plotter/924262
### Issue checklist
- [X] I searched for previous requests in [the issue tracker](https://github.com/arduino/arduino-ide/issues?q=)
- [X] I verified the feature was still missing when using the latest [nightly build](https://github.com/arduino/arduino-ide#nightly-builds)
- [X] My request contains all necessary details
If you have a GitHub
As a workaround, it is possible to have a separate Arduino IDE window to use for the Serial Monitor alone, while you do your sketch development in the other window. You can open additional Arduino IDE windows by selecting File > New from the IDE's menus.
4 Likes
Seconded! I'm shocked (and downgrading to a previous version) that 2.0 was designed this way.
6 Likes
The choice of a docked or separate window for the Serial Monitor would have been a sensible design decision. I'm disappointed this is currently not implemented.
5 Likes
Everyone is welcome to contribute to this free open source software project.
If you want a Serial Monitor in a separate window right away, feel free to submit a pull request that makes the necessary changes to the codebase. The decision has already been made by the project management that this change should be done, so it is only a matter of someone doing the necessary development work.
If you instead expect Arduino's paid developers to add this capability to the software they are providing you without charge, you will need to be patient.
5 Likes
People giving up their time for any Open Source project IS always awesome.
1 Like
srnet
November 12, 2022, 6:37pm
7
I think it is amazing how much effort and resources the Arduino team put into the free IDE.
You can open an empty sketch in another window and make the serial monitor box as big as possible.
5 Likes
BRILLIANT! (Seriously.) Thanks.
I am not sure I follow your question but I use Linux and I can have as many IDEs open as I want on each workspace and I currently am using 8 workspaces 1 monitor. I have been doing this since ver 1.1 through 1.8.18. Note I use an external editor Geany as my editor and when I go to the debug area I simply recompile the code the IDE checks for the updates and processes them. If I make a change with the IDE Geany knows about it and asks to reload. The only gotcha is I can only have one monitor window open at a time on a given sketch. I can close it and go to another sketch on the same unit and open it without a problem.
A workaround hack is cool of course, but why are users encouraged to use a single window?
1 Like
Dougl
January 29, 2023, 4:47pm
12
it looks like Drag-n-Drop capabilities are on the Eclipse-Theia radar but not ready for prime time.
opened 11:53AM - 09 Dec 21 UTC
proposal
secondary-window
# Summary
We would like to have fully featured multi window, a.k.a. floating … window support in Theia. This issue proposes a specific approach and may serve as the `Epic` to implement this feature in full.
We evaluated the approach with a PoC and created an initial list of development tasks. Also we added a rough risk assessment for each of the determined challenges.
We are looking for feedback in regards to the suggested approach and the overall assessments. Feel free to add suggestions on how to solve the determined challenges and please notify us when we missed a whole concept or even only a minor detail.
# Goal
* Views shall be movable into secondary windows.
* Views shall behave the same no matter whether they are contained in the main or in a secondary window
## Status Quo
Theia offers a ["New Window" action](https://github.com/eclipse-theia/theia/blob/c4c6cab037230fc05e39c7b124a681630c2f6a33/packages/core/src/browser/window-contribution.ts#L26-L30) which opens an additional window. In this window a complete new Theia frontend is instantiated, including, among others, the inversify container, frontend application and application shell.
The diagram above shows this case in a simplified way. The result is two completely separated frontend instances which do not share the same "UX context", e.g. they don't share a common selection or debugging state. They don't even share the same plugin process on the backend. They _almost_ behave like two completely different instances of the same Theia application, with the difference that they share some singletons via the backend. For example the "running task" list is synchronized between these two frontends via the backend.
### Downsides of Status Quo
* Views can not be dragged and dropped between the windows
* The same file or view can be opened in both windows, but they belong to their respective frontend instance. So for example the errors view will always be scoped to the corresponding window.
Overall it resembles a multi instance rather than a multi window approach
### Comparison to other frameworks
A good implementation of multi window support can be found in Eclipse RCP.
Here the user is able to detach windows from the main window into (one or more) secondary windows. These share the same context as the main window. In the screenshot above you can see the detached console and debug view which share the same state with the main window. Ideally we would like to see similar behavior in Theia.
Looking at VS Code, [multi window support](https://github.com/Microsoft/vscode/issues/10121) is one of the most requested features for years.
# Web technology
The reason why it's non trivial to support this for Theia and why VS Code does not yet offer this feature is the underlying tech stack. By relying on web technologies we also inherit their security model. Windows are almost completely isolated from each other.
By default the only way to communicate between windows is to send messages, either [directly between them](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) or via the Theia backend. This means that any shareable state needs to be fully serializable and a synchronization mechanism must be in place. Any functional callback must also be handled via messaging and corresponding proxy handlers.
This requires major architectural changes and influences the whole framework. Therefore a lot of effort is required to get this to work.
# Alternative approaches
Before we settled on the suggested approach described below we also discussed alternative approaches.
<details>
<summary>Expand for more details</summary>
## DOM Streaming
First on our list was to check whether there exists some DOM streaming techniques by which we would render the views in an invisible way within the main window and just project the results into the secondary windows.
However this was quickly aborted after we did not find a library or existing applications which use such a technique. Additionally there are some conceptual issues regarding the integration of user interaction. Also these might not even be possible for elements like canvas.
## Multi window concept as a first citizen
Another more obvious approach is to enrich Theia in generally with the concept of multi window support. As the windows can only communicate via serialized messages, this concept must be baked in for every single window, service and use case handled by Theia.
Moving a widget between windows then requires to close said widget and reinstating the same in the secondary window. Each service the widget consumes, for example a selection service, but also any 3rd-party service must also be provided in the secondary window and behave the same in the secondary window as in the main window.
Conceptually there are then no more "real" singleton injections (each window has it's own Inversify container). A consequence could be that singletons exists in both windows and need to know how to share state. Questions like how to share a dynamically registered callback must then be answered. Another solution could be a parent-child concept for them by which for example only the "child" variant is injected in secondary windows. Depending on the use case this might not be possible transparently and consuming widgets might need to handle both "real" / "parent" and "proxy" / "child" injections.
Use cases need to be adjusted for multi windows too. For example switching the workspace of the main window should also update the workspace of the second window. The same is true for the debugging state, theming etc.. Each use case must be evaluated on their own what it means for them to be distributed over multiple windows and act accordingly.
Very likely this then requires developing not only a main frontend but also a secondary frontend with a reduced application shell and differently registered contributions. These different frontend instances should also use the same plugin host in the backend, to make sure the plugin views and other integrations like LSPs also behave the same between windows. It's also unclear how well the Monaco services can be synced.
Overall we had the impression that this approach requires so many changes to the overall framework that even producing a non-trivial PoC with views which consume at least some services is a huge undertaking. Therefore we went for the suggested approach discussed below.
</details>
# Suggested approach
[Browsers](https://developer.mozilla.org/en-US/docs/Web/API/Window/open) and [Electron](https://www.electronjs.org/docs/latest/api/window-open) allow to create new windows which are controlled by the parent. Therefore we can access and manipulate the DOM of the secondary window from the main window.
We suggest to use this feature to render Widgets into secondary windows. Any interactions is automatically handled via the main window and therefore is executed in the same context.
Using this approach allows us to reduce multi window support to a UI problem instead of elevating it to a core principle of the whole Theia framework. There are no additional services or frameworks involved. Most of the existing code doesn't need to be touched and many views work out of the box.
# Proof of concept
We developed a proof of concept based on our suggested approach to check its feasibility and to identify challenges and risks and come up with an overall estimation of effort.
The proof of concept is available on [branch "multi-window-poc" in our Theia fork](https://github.com/eclipsesource/theia/tree/multi-window-poc). Please see the readme for instructions on how to build and run the PoC.
It showcases multi window support in the Electron example app. Views can be moved into a secondary window via the `Sample menu > Move currently active view to new window` action.
The PoC is not particularly polished but shows the feasibility of the suggested approach.
# Identified challenges
## PhosphorJS
* Architectured for single Windows (DOMs)
* [Changes in PhosphorJS necessary](https://github.com/phosphorjs/phosphor/blob/9f5e11025b62d2c4a6fb59e2681ae1ed323dcde4/packages/widgets/src/widget.ts#L1003-L1005) to being able to attach Widget to a secondary window
_For the PoC we removed a single line check in PhosphorJS_
## Styling
* [Theia CSS is bundled during the build step](https://github.com/eclipse-theia/theia/blob/de70cd3f0fa475d1c1932adb3bba9e06bdd6426b/dev-packages/application-manager/src/generator/webpack-generator.ts#L114-L116). It needs to be made available for secondary windows.
* Some internal CSS imports [use Webpack notation (“~”)](https://github.com/eclipse-theia/theia/blob/e5e6f928e39e88d51c4beb005ceb577fe0d3c26e/packages/core/src/browser/style/index.css#L17-L18), so they can’t just be used as is without webpack
* Some CSS also comes in via Monaco
_For the PoC we modified the frontend build one time to extract all CSS into a standalone stylesheet. This stylesheet is then loaded in secondary windows. We also execute [Monaco loading](https://github.com/eclipse-theia/theia/blob/e5e6f928e39e88d51c4beb005ceb577fe0d3c26e/packages/monaco/src/browser/monaco-loader.ts) in the second window to get the Monaco CSS._
## Javascript Global Access
Theia code often makes use of Javascript globals like `window` and `document`. This may break functionality in secondary windows.
For example let's say a Widget renders a `Button` and some other element like a `Searchbar`. On click the `Searchbar` shall be cleared. As the callback code in the widget does not have direct access to the Searchbar the access may have been implemented by using the `document` global like this:
This breaks with our suggested approach, as the `document` of the Main window actually does not contain the `Searchbar`. Instead it's rendered in the DOM of the secondary window. We can't do any tricks here like extending the behavior of `document`, as these global variables are especially protected and can't be modified.
Code like this needs to be refactored for the suggested approach to work. In general, and especially when using React, it should be avoided to manipulate DOM elements directly.
However there might be cases where this is required or it would afford a lot of effort to be refactored. Luckily most code can also be adjusted by avoiding the global access, for example like this:
By using `this.node.ownerDocument` instead of `document` within a widget the code can be generalized. Of course this fix might not apply to all situations, for example when accessing the DOM outside of a widget, but similar workarounds could be implemented.
_In the PoC we added this fix for the searchbar clear button in the preferences widget_
## Views contributed by Plugins (VS Code extensions)
Conceptually these are the easiest views as they are completely encapsulated already anyway. To get them to work in secondary windows they just need to be connected properly.
Main window and the webview host (this is not the plugin host!) [communicate via Window messages](https://github.com/eclipse-theia/theia/blob/e5e6f928e39e88d51c4beb005ceb577fe0d3c26e/packages/plugin-ext/src/main/browser/webview/pre/host.js#L53-L55). These messages must be relayed between the main window and second window.
_In the PoC we added a simple broadcasting in which all messages are relayed to all secondary windows and back to the main window_
## Monaco Editor
_In the PoC: Moving a Monaco editor into a secondary window results in non-highlighted text which does not allow modifications._
* [Color registry](https://github.com/eclipse-theia/theia/blob/e5e6f928e39e88d51c4beb005ceb577fe0d3c26e/packages/monaco/src/browser/monaco-color-registry.ts) and [Color contributions](https://github.com/eclipse-theia/theia/blob/e5e6f928e39e88d51c4beb005ceb577fe0d3c26e/packages/core/src/browser/color-application-contribution.ts) need to be synced to secondary windows
* The [Monaco Editor](https://github.com/microsoft/vscode/tree/3ba528bde5b18a713ca14aadf7d600a15f7095ec/src/vs/editor) also makes heavy use of `window`, `document` and `monaco` globals.
# Development Tasks
This sections lists a non-exhaustive list of development tasks for each of the overall topics
## Styling
- Extract CSS for secondary windows as part of the frontend webpack build or a separate build
- Load and apply color customizations for secondary windows
- Sync theme to secondary windows
- Content in secondary windows should resize with it
- _Issue: Tree View styles result in 0 height within the PoC_
## Theia Base Framework
- Extend `ApplicationShell` with the notion of widgets residing in secondary windows
- Adapt code base to these shell changes where necessary
- Adapt window specific use cases, like opening a dialog, to also support secondary windows
- Provide a proper base widget for secondary windows
- Adapt code base to handle being rendered in DOM of secondary windows
- Implement a robust secondary window handler
- Implement VS Code message bridge
## Platform specifics
- Allow Electron secondary windows with access rights to main window in a secure way
- Adapt new window for Browser and Electron (e.g. remove Browser and Electron menu bars)
## PhosphorJS
- Some modifications to PhosphorJS are necessary to get the suggested approach to work at all
- We expect further modifications are needed for polish work, e.g. drag and drop
- Check single document assumptions which are baked in PhoshporJS and might affect this negatively
As an additional challenge we can't just upstream PhosphorJS changes as the project is archived and no longer under development. A workaround could be source level adaptions during the webpack build however this is probably not ideal on the long run.
## Monaco
Background: Monaco is not built for the use case of rendering within a secondary DOM
_In the PoC Monaco editors are rendered read only and permanently show an insert mouse icon on hover_
- Monaco editors needs to be fixed or a workaround needs to be found
- Monaco views like "Output" need to be polished
# Risk assessment
We don't expect any conceptual problems in regards to the development topics Styling, Theia Base Framework and Platform specifics.
There is medium risk in regards to PhosphorJS as we don't know about unknowns within Phosphor which could increase the effort for a polished experience by a lot and we need some solution to its development situation.
It's unclear how much effort would be needed to generalize Monaco and get it to work in secondary Theia windows. It's also unclear whether Microsoft would even accept these changes. Maybe there are alternative approaches with secondary Monaco instances in secondary windows to solve this problem differently which could also be evaluated. Therefore there is a high risk for a lot of effort which is currently hard to estimate.
There is a low risk of the Window API being modified in Chrome or other Browsers to disallow the amount of access we need to successfully use this feature. The API exists for a very long time and is similar to the one of IFrames. Removing the Window API would break a lot of web pages, however certainly not the majority. Therefore this risk can't be discarded completely.
# Summary
Implementing multi window support with the suggested approach requires some work. However, except for Monaco, most of the work seems to have no conceptual risk and "just needs to be done". Overall the approach of implementing multi window support via the UI seems to encapsulate it rather well and does not require major architectural refactorings of the Theia framework.
Monaco is the most risky part however it's also the only one which could be considered optional. Having a polished multi-window feature without being able to place Monaco based views in secondary windows is already very useful.
We roughly estimated the effort to implement this in full in a clean and secure way to be in order of magnitude of 150 person days. However the work can be parallelized to a high degree and the feature could be released in an iterative manner, reducing the amount of work for the first iterations.
# Going forward
We are looking for feedback in regards to the suggested approach and the overall assessments. Feel free to add suggestions on how to solve the determined challenges and please notify us when we missed a whole concept or even only a minor detail.
We also can't stem the work on this feature on our own and are therefore looking for volunteers to take over parts of the work. From our point of view implementing this feature would add a lot of value to the Theia framework and many adopters would benefit from it.
You are right on the Serial Plotter launching in a separate window and it has me wondering how difficult it would be to hack the IDE to make Serial Monitor do the same based on a switch in general preferences.
the Serial Plotter is located here:
I've copied that director to one named arduino-serial-plotter-webapp2 and changed the name in package.json but I've not figured out how it's launched. I was thinking if I could add a 2nd Serial Plotter to the menu, I could try editing it so it scrolled the output instead of plotted the output.
2 Likes
Dougl
January 29, 2023, 8:46pm
13
@ptillisch maybe you can pass this on to the devs? It was posted to an eclipse-theia issue asking for 'floating' windows when I mentioned users asking for tearing off the Serial Monitor:
Implementing this should be fairly straightforward. Adopters need to implement the ExtractableWidgetsecondary-window
And it looks like Electron support is on the list and has an assigned dev -
opened 11:42AM - 08 Sep 22 UTC
electron
secondary-window
#### Bug Description:
The issue tracks a known limitation from https://github… .com/eclipse-theia/theia/pull/11048, where secondary or multi windows is not supported for `electron`. The goal is to add proper support for the desktop use-case which already has code in place but is not yet enabled.
#### Additional Info:
- Theia Version: as of a07b74644372ebc6c5f04e153bd7d8607a5afc5c.
2 Likes
Thank you. Just what I need to know...for now.
I think the plotter looks great. Looking forward to the monitor following suit. Thanks for all the hard work.
2 Likes
It's good to read that this feature is likely to return in a new release.
1 Like
This is becoming a HUGE problem for me, especially on my 13” MacBook!
2 Likes
I too would vote for an option to have the serial monitor in a separate window. I have long since realised that the serial monitor can be left open in one sketch (I had not thought of an empty sketch) whilst working on another.
1 Like
If this feature gets implemented will there be a way to switch back to the normal one?
My wife uses a 96" monitor with her computer, when she is not using it we use as a TV. I use 4K 36" TV for my monitor, works great. Works great as I do not need the extra capability that is needed for games. Amazing what you can plug into a HDMI port.
