- it does not let me enter a host name - it should,
- it does not let me paste IP - it should
- also i should be able to enter port# that's unlisted
- cmd-C / cmd-V (copy and paste) shortcuts don't work - contrary to what right-click hints say
- when clicking on the console screen, would be nice keyboard still to go to the entry line (instead of having to click on the thin line first)
- cmd-F should do search in the console text (as is in Terminal)
It's rather massive at 100 MB for a telnet client, no?
If going that (browser engine) route, why don't you just plug into VSC's console API? And for the same price we get an IDE too
... In the (unlikely?) event that a Roku is not discovered, you can manually enter its IP address. You can also enter a name for your Roku in the Friendly Name field. All device table entries will persist across shutdowns. I don't see a use-case, pertaining to Roku debugging, for entering a host name -- unless, perhaps, you're debugging Rokus on another subnet?
Again, for a Roku-specific debugging tool, I don't see a use-case for entering a port number that isn't in the list of ports used by a Roku device.
... The existing code works on Windows and Linux systems. This was the main reason I was looking for feedback from Mac developers - to discover any implementation-specific issues that I wasn't able to test since I don't have a Mac. Good catch!
First, assuming the "thin line" is the input text box, note that you can increase the size of the entire UI and make that box bigger by using Window>Zoom In (or the macOS control key combination listed for that menu item).
Second, there may be other reasons you'd want to click on the console screen without automatically jumping into the input text box, e.g. clicking and dragging to highlight text to copy, or text to find (not yet implemented). What I could do, however, is implement another key shortcut that will put the cursor back in the input box (In my current test version, if I press Ctrl/I the cursor will jump into the input box).
In the meantime, if you anticipate wanting to search the debug output, you can open up a log file from the connection's right-click menu. The log file with contain your entire debugging session, which you can open in your favorite editor and search all you want.
Does size really matter? There's been a lot of debate in the Electron community about why these programs are so large. Basically they contain huge chunks of the Chromium browser as well as the node.js binary. The team has been asked to look at reducing program size, but that doesn't appear likely in the near-term as they have many more things they're working on.
My PurpleBug program only takes up 317 KB. However, it also requires the .NET Framework (172 MB), and will only run on Windows. So the advantage of bundling Chrome/Node etc. in the application, is that it reduces the need for (platform-specific) external dependencies, and facilitates cross-platform development.
Looking into VS Code some more is still on my todo list. I'm not yet convinced it would be any better as an "IDE" than Atom, and there are already quite a number of Roku developers using Atom, judging from the number of downloads of my roku-develop Atom package. I could probably make an Atom plugin-in out of my VioletBug code, so you can stay inside the editor while accessing the Roku debugger. I'm not familiar with the VS Code "console API" (yet), so I don't know how easily or effectively it could be used to interface with the Roku Debugger. If it works the same as most other console-based clients then it wouldn't be much use if it used character-based, rather than line-based, input. I'd need to do further research.