The story behind the Logic 1 to Logic 2 software transition

I have been looking around for an article/newsletter/blog post explaining the reason behind the decision to make the “revolutionary” framework change when developing Logic 2 (using the Electron framework) rather than continue enhancing/improvi on the Logic 1 (QT? based) codebase.

Was it due to Logic 1 becoming unmaintainable (spaghetti, structuring etc), developer productivity, missing features in the old framework, platform support or a combination of these or other reasons.

It was a courageous, expensive, time consuming and risky decision to make, but it seems to have paid off in the end.

It would also be interesting to hear about the main challenges that you have run into during the Logic 2 design and development process (other than the obvious binary distribution size and resource requirements of Electron).

I know you guys are busy doing core development tasks, but I think it would make a realy interesting article for many software (tool) developers and have wide appeal beyond Saleae users, regardless of whether the article/post takes the form of a newsletter, blog post, Youtube video discussion, forum post (here) or an article in a more widely distributed developer forum/media.

I considered proposing this on, but thought it wasn’t really a “feature request” so decided to post here under the “Logic 2 Software” category.

Am I the only one who is curious about the background, challenges and surprises during the Logic 1 → 2 transition process?

1 Like

@morten.hattesen This is a fantastic idea, and thanks for bringing this up!

I’ll let our software team chime in if needed, but your points are just about correct. Two of the big reasons were mentioned.

  1. developer productivity
  2. platform support

I can’t comment on the other two points, though I’m sure they played a role in the decision. Without completely understanding the details under the hood (I’m a support engineer on the team with expertise in hardware), Electron was frequently mentioned during internal meetings as much easier to develop features for and for maintaining cross platform compatibility. QT was apparently a nightmare to work with across all platforms, especially given that our software team has consisted of 4 or less members max during the past few years.

Glad to hear that!

You’re right. A blog post like this would sound interesting for both sw developers and hw engineers alike, in addition to anyone simply following along in our journey.

I’ll bring this up during my next meeting with the software team. Short term, I’m not sure if we’d be able to pull them away from some of the priority tasks they are currently laser focused on (Automation API improvements being one of them), however, I can’t deny the fact that a story like this would be interesting for many folks.