Firstly, thank. you for a great set of tools. This was my first exposure to JTAG-class tools and it's been amazing to reload code in a second from within GDB and immediately single step the first opcode or right through an exception handle. Amazing! I appreciate the way everything can be scripted OR accessed via a tool when needed.

Fifteen years ago, I didn't think I'd be one of those annoying MacOS snobs that scoffed at the fade of a shadow, yet here I am. I still don't really consider myself a MacOS dev, but I've learned to look for those idioms. As qualifications, for many years I was the Qt Dude for one of the world's most recognizable apps, so while I don't know MacOS itself well, I know Qt.

You really need to have a MacOS developer, or at least a MacOS user, review your tools. Without being unkind, they're ugly.

In a dialogue, action buttons are always on the far right (e.g. "Ok" or "Save") with the dismissive option to the left of that ("Cancel") and anything else ("Reset") to the left of that. If you assign the correct actions to the button roles in QDialogButtonBox, Qt will even do this for you. For example, this dialogue will go against a Mac user's reflexes:





Your Application.icons have a 72dpi resolution. Any computer that a developer should be using these days has a resolution of >200dpi. In the doc and in the switcher, your icons are blurry. Doesn't this "K" make you sad? Please provide modern assets in Resources/Application.icns




Most of the vertical centering in everything from buttons to drop-downs is just wrong. This makes all the buttons unsightly (See "OK" and "Cancel" above) and makes some of the text chopped off. I actually recognize this as a bug in QT itself from around 4.6 or so, but that was fixed a long, long time ago. Maybe you have an old version hanging around.





Also, your menu ordering gets some of the Qt conventions right, but settings are often squirrelly:





Instead of having another menu entry for "Options", this should be the second entry here, under the label "Preferences" and with a shortcut of a cmd+, Again, Qt should largely handle this for you if you mark the items up correctly. See doc.qt.io/qt-5/qmenubar.html#qmenubar-as-a-global-menu-bar.

Watch for warnings:
2021-04-10 20:39:37.249 JMemExe[9091:256650] modalSession has been exited prematurely - check for a reentrant call to endModalSession:
I don't have more in my scroll back, but I know I've seen other admonishments like null pixmaps (did you display while still fetching from storage or the web?) and state violations. Turn these on in the beta builds and have them sent back to you if you really don's see them in house. Hint: qDebug and internal issues like this are way easier to spot if you're running them from command line instead of from launcher.


There have been some others that I've noticed. JMem was just the one that inspired this break tonight. It's pervasive (mis)use of Qt itself as the issues are persistent in all your apps, from Flasher to JMem to RTTViewer.


I'm pretty sure that an update of Qt version (Qt4 -> 5 isn't bad; it's nothing like the bloodbath from Qt3 to 4) and some relatively minor changes in your .cc or even the .ui files would make your apps look much more professional. Most of this should stand out like sore thumbs to experienced MacOS users, so you should encourage more feedback from that crowd or start handing out MacBook Pros to your own developers.


I could conceivably be convinced to help with this. Buzz me privately if interested.


Thanx!

Outside of the Qt stuff, inside JLink, there are a couple of easy tweaks that would make it easier to use when trying to reverse engineer hardware or to twiddle bits on hardware outside the edit/compile/upload/reboot cycle.

Inside JLink, there's probably one function that reads a line and tokenizes it, perhaps via something like QStringSplit.

1) If there are no tokens, skip the error case and just to a continue or a return or whatever fits with that style. This would eliminate the error if you just bang on the enter key.
Unknown command. '?' for help.
J-Link>
Unknown command. '?' for help.
J-Link>
Unknown command. '?' for help.
J-Link>

It's not an unknown command - there isn't a command. Just swallow it and carry on, just like command.com or the unix shells would.


2) If the first token is a '#', skip the rest of the body and return or break much like in case #1. I don't think that # conflicts with anything else inside JLink and it's familiar from many languages. This would allow editing a big dumb block of commands in another window with comments in it and then just pasting that into the JLink window.

I'm not asking for JLink to become a scripting language, but it would be nice for my notes to contain something like this and have JLink not show such disdain.




3. Combine the two above and it becomes about trivial to also support comments starting at the end of a line.
I think I have almost exactly that same code in some of my CSV and command file readers inside my biggest open source project. (It's possible the truncate needs a -1. It'd be obvious when testing the implementation.)

Add a test case and call it a day. No icky UI or translations or such needed.


Again, I'd be willing to help if that's what it took. (And didn't bury us all in NDAs and VPNs and esoteric build environments, etc.)