Roku Developer Program

[belltown]

Thanks for the feedback, EnTerr. I'll take a look at your points over the coming days and attempt to make improvements.

[EnTerr]

The good news is, it is useful as-is. There was nothing that made me bail out immediately.

I also learned how used i am to couple of things in Terminal - namely keyboard copy&paste and being able to text search. Things i wouldn't have thought i'll miss till i tried. Also i learned how annoying is using the local menu with Apple's Magic Mouse - its "touchy" back may go into zoom or side-sliding with minor slips of my finger.

[belltown]

"EnTerr" wrote:
- it does not let me enter a host name - it should,

VioletBug is intended to be a Roku-specific debugger interface, not a general-purpose telnet client. As such, it is designed to discover all the Rokus on your network and display them in a list. If you click on a list item, it will populate the IP address field with the address of the selected device. Double-clicking on a list item will also connect to that device. 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?

"EnTerr" wrote:
- it does not let me paste IP - it should

Yes, it should. See the cut/paste comments below.

"EnTerr" wrote:

- also i should be able to enter port# that's unlisted

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.

"EnTerr" wrote:

- cmd-C / cmd-V (copy and paste) shortcuts don't work - contrary to what right-click hints say

It appears that for a macOS build, the cut/copy/paste menu item shortcut keys won't work unless they are implemented as application-menu items rather than in a context (right-click menu). If that's true, it should be an easy enough fix. I'll plan on a new release soon. 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!

"EnTerr" wrote:

- 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)

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).

"EnTerr" wrote:

- cmd-F should do search in the console text (as is in Terminal)

That's a good suggestion for a future enhancement.

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.

"EnTerr" wrote:

It's rather massive at 100 MB for a telnet client, no?

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.

"EnTerr" wrote:

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 🙂

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.


Thanks again for all the useful feedback.

[EnTerr]

"belltown" wrote:
... 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?

Yes - auto-discovery is a great thing, when it works. I wouldn't be asking the question i asked if it had worked. Nor would i have added manual entry in my iOS remote app five years ago. And, when i have to enter Roku manually, i'd rather use a humane name (from DNS or /etc/hosts). Let be honest here - you checking that field for something like \d+.\d+.\d+.\d+ is uncalled for - let sockets do their magic, with resolver or not.

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.

Your list of ports might easily be incomplete. FWIW, possible workaround to that is to manually edit `.../Resources/app/index.html`

... 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!

IMO the Co should just send you a Mac for the common good of the Roku platform. 8-)

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).

Yeah... no. You misunderstand, it's not that i want to be easier to click on the entry field or to have a shortcut for that - rather i don't want to have to do that at all. Think how terminal/putty/etc works - even as i had just scrolled the pane or marked text in it, i can directly type on the keyboard - don't have to manually "re-focus" on an element. There shouldn't be extra step - how that is done behind the scenes (i.e. whether keyboard events get re-directed) matters not to me.

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.

I use cmd-F to quick&dirty pinpoint some text in the console... repeatedly so. Opening the log file in separate app would be just snapshot in time, right? I need it current all the time.

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.

That's like saying "does being overweight really matter" and is a "slippery slope" kind of fallacy. While a pound or two of body weight don't matter, reaching "morbidly obese" status substantially decreases the life expectancy. Indeed, it is Electron that is morbidly obese - and as result so are Atom and VSC - but we can kind of tolerate them because they deliver lot of functionality bundled.

Bringing the size of .Net into the conversation is "false equivalency", since it is a shared framework, like Java JRE. VioletBug OTOH is standing on it's own as a "Stay Puft Marshmallow Man". But yes, you are right that if it proves to be very usable, developers would tolerate its obesity just fine.

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.

VSC has proper syntax highlighting for B/S right off the bat, w/o any plugins. Around our prior discussion (around Thanksgiving time?) i did some performance tests between the two and VSC handled better than Atom as memory and speed - most notably with big files, where Atom took forever to do highlighting right - or dropped it altogether - or scrolling was incredibly chunky. I have to admit i also discovered VSC had grown overweight substantially overweight over the previous year (likely part of maturation and feature-creep that have had infected Atom prior) - and Atom had improved in speed (if not in RAM use).

VSC has a neat API to write a multi-thread debugger (yes, real UI debugger!) and console, all of that nicely integrated in the IDE already. I did a quick, focused eval over a year ago and concluded i could do it if i sit and do the time learning node.js. Does Atom have that?