[SOLVED] The apps need some Qt love, especially on MacOS

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] The apps need some Qt love, especially on MacOS

    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.

    Source Code

    1. #Invert display so we can see if the chip has locked up.
    2. w4 60000000 21
    3. # Show our starting state
    4. mem32 61000000 10mem32 60000000 4
    5. mem32 60000000 4mem16 63fffffe 1
    6. mem16 63fffffe 1
    7. mem32 a0000000 10
    8. # Issue an ID request through the EXMC to the video chip
    9. w4 60000000 db
    10. w4 60000004 db
    11. # Is it where seeed documents it?
    12. mem32 61000000 10
    13. # Is it readable where we wrote it?
    14. mem32 60000000 4
    15. mem32 60000000 4
    16. # Is it where EXMC.cpp documents it?
    17. mem16 63fffffe 1
    18. mem16 63fffffe 1
    19. mem32 a0000000 10
    20. # Restore display
    21. w4 60000000 20
    22. ~
    Display All



    3. Combine the two above and it becomes about trivial to also support comments starting at the end of a line.

    Source Code

    1. w4 600000 20 # restore display

    Source Code

    1. comment_start = lbuf.indexOf('#');
    2. if (comment_start != -1) {
    3. lbuf.truncate(comment_start);
    4. }
    5. if(lbuf.trimmed().isEmpty()) {
    6. return;
    7. }
    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.)
  • Hi,


    Thanks for your inquiry.

    Dialog buttons:
    I understand your concern and we are already aware of this.
    Please understand that the button position (and other GUI layout) is the way it is due to historical reasons.
    In the past, the J-Link software package was only available for Windows, which is why the "Cancel" button is to the right of the "OK" button.
    We try to keep the GUI of the J-Link software as similar as possible, regardless of platform.
    That way our customers can switch between Windows, macOS and Linux without having to readjust to a different layout or similar.
    Due to that, it is possible (and sometimes intended) that some J-Link software GUI layout may not match cosmetic guidelines of the platform it runs on.

    Application icon:
    Thank you for bringing this to our attention.
    I will mention this in our upcoming team meeting.

    Misaligned text in buttons and dropdown menus:
    Thank you for bringing this to our attention.
    We will check how we can improve this behavior.

    Menu ordering:
    Thank you for bringing this to our attention.
    We will check how we can improve this behavior.

    Qt warnings:
    Thank you for bringing this to our attention.
    We will check how we can improve this behavior.

    J-Link commander comments:
    Thank you for bringing this to our attention.
    I will mention this in our upcoming team meeting.

    Please understand that I cannot assign a high priority to the requests that you made,
    as they are "cosmetic" and do not restrict the usability of the J-Link software.
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.