Your opinion for Plugin approach in SSDR GUI

  • 2
  • Question
  • Updated 3 years ago
I would like Flex Software designers would consider the opportunity to open some of the SSDR GUI APIs.
I would like to have the opportunity to develop pieces of software that are entirely integrated in SSDR GUI but are not part of the official release product.
I come from Java world and this is the great approach adopted initially in the Eclipse Community project. The same approach was then adopted from all other leading software vendors starting from Microsoft.
As SSDR is developed in .Net platform people could use its preferred programming language to enanche standard SSDR features and this would allow SSDR to grow up much faster.
I would like to know the opinion of other community developers.

73' Enzo
iw7dmh
Photo of IW7DMH, Enzo

IW7DMH, Enzo

  • 350 Posts
  • 83 Reply Likes

Posted 3 years ago

  • 2
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 642 Reply Likes
Let me see if I understand this, you are saying .NET is 'the preferred programming language'. Sir, I must respectfully disagree. Having said that, this is the wrong forum to debate a decision FRS made many years ago.

I am actually rewriting the core of SSDR in a portable fashion and will have a VERY spiffy GUI on Linux, Mac, Raspberry Pi, (oh, and Windows) as well as an incredibly unique GUI on Android taking full advantage of Android platform features.  I have not done any RCP (Eclipse SWT environment) programming since 2006 but your reference to that does bring up interesting possibilities as SWT has some very nice GUI constructs. There are some things I will be doing however that I don't see a vehicle for doing in RCP.

I will say this however, there is nothing I am doing that would preclude someone building an RCP with the Eclipse Framework.  Have you actually written Eclipse plugins? If not you may want to brush up on doing so. Interesting idea but I think, and I don't like speaking for others, anything done in this area would need to be done by Flex owners rather than FRS. The model is vastly different and requires Java.

Starting about a year ago I've had public and private conversations on many of these and other, more tertiary, issues. I believe the best approach is to assume we (customer base) will have to do it.

Walt - kz1f
Photo of IW7DMH, Enzo

IW7DMH, Enzo

  • 350 Posts
  • 83 Reply Likes
Please, not misunderstanding me.
I don't want an Eclipse version of SSDR, nor a Java version of it.
I am simply wondering if SSDR could host some "external" piece of software written in .Net platform. Thats all.
I think SSDR API are a great piece of software. One really interested in computer programming could learn a lot simply opening that classes and wondering how they can work togheter.
(Edited)
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 642 Reply Likes
But you are asking for them to write a container. What would be their motivation? IBM did Eclipse to solve a completely different problem. All of what your examples were and what Peter mentioned below is completely doable on top of FlexLib.
What I believe you are both asking is will FRS open source the GUI. That is a business model question, not a software architecture question. SSDR is a revenue stream, FlexLib is not. I would guess they might not want to open source a revenue stream. But that is a question for FRS. You or Peter could write that on top of Flexlib. You don't need a container.
(Edited)
Photo of Peter K1PGV

Peter K1PGV, Elmer

  • 541 Posts
  • 315 Reply Likes
What I believe you are both asking is will FRS open source the GUI.

Sigh. Nobody's asking Flex to open source the GUI. In fact, it is my fervent hope that they never do this.

Stop being so hung-up on Eclipse as a specific item.  Enzo simply used this as an example. There are zillions of programs that provide the capability for plug-ins.  Some of these were shipped far before Eclipse was conceived.  Think of how various programs can be "skinned"; Think of every Microsoft application from Outlook to Visual Studio.  These are all examples of different approaches to PlugIn architectures.

All Enzo is suggesting, and I agree it would be a nice addition, is a mechanism that would allow devs to "value add" SSDR with modules of their own design by using an architected interface provided by SSDR to do so.  I get, and I'm sure he does as well, the fact that one can write, today, these as standalone apps.  The ask here is for a way to add these features directly into SSDR.

The reason I asked Enzo what he had in mind as things he'd like to see as add-ins, is I was trying to get an idea from him precisely the level of control that he'd need for that interface.



Photo of IW7DMH, Enzo

IW7DMH, Enzo

  • 350 Posts
  • 83 Reply Likes
But you are asking for them to write a container.
I tought it was helpful, before, to know opinions from other developers but it seems this kind of poll is not a great success. :)
Flex API are a great software but the idea to start each project from scratch, and ouside of SSDR, isn't so exciting for me.
I try to imagine a pluggable gui with DAX Control, SSDR Cat and SSDR itself. Why having three standalone programs for these features? Ok I can choose which part of the software I need when I am on different pc, but I could have the same flexibility using just a pluggable gui.
What I am finding really exciting are the network protocols and I am trying to implement an API for Arduino boards, outside any OS. Wow, it seems it works very well, and my Flex now can work without any computer.
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 642 Reply Likes
@Peter "I would like Flex Software designers would consider the opportunity to open some of the SSDR GUI APIs."

Just because I think you are mixing metaphors and the idea is flawed that doesn't mean you shouldn't pursue it. I simply weighed in on it which is what this thread was about. With this I am leaving this thread.

Best of luck.
Photo of Peter K1PGV

Peter K1PGV, Elmer

  • 541 Posts
  • 315 Reply Likes

Excellent idea, Enzo.  A plug-in architecture for SSDR would be an excellent addition to what is already a pretty good piece of software.

The question rapidly becomes precisely what you envision this plug-in being able to do.  Most "plug-ins" can add additional functions (by way of additional dialog boxes or widgets or whatever), but can't fundamentally alter what the host program does.

From my own, personal, standpoint, here are a few examples of what I'd like to be able to create a "plug-in" to do:

  • Change the way the VFO works to provide all the tuning features of PSDR.
  • Make the filter buttons programmable
  • Add a widget to the SSDR palette that simplifies tx and rx filter interactions (settings for high and low filter frequency for each, and making the bandwidth range more explicit)
  • Add a widget to change how the SWR and output power are displayed.

The first two items above would require the ability to "subclass" the individual controls (that is, intercept any input destined for these controls and process it before it reached the control itself);  The second two items would require the ability to add an additional widget to the SSDR screen.

What types of things do you envision enabling, Enzo?

Peter
K1PGV

Photo of IW7DMH, Enzo

IW7DMH, Enzo

  • 350 Posts
  • 83 Reply Likes
Oh really I don't know which first choose:

1- a keyer widget connected to my preferred contest logger program;
2- a 90° rotated version of waterfall, with related callsigns;
3- an analogic SMeter
4- a panel with rig's vital parameters (all the one that can be read using metering protocol)
5- a cw decoder
6- an rtty decoder

and so on ...

For example I could surely pay for 1, 2 and 5 plugins.
  
Photo of Larry da Ponte

Larry da Ponte

  • 159 Posts
  • 15 Reply Likes
SDR# is closed source but offers a plugin architecture for developers. http://sdrsharp.com/#plugins
Photo of Peter K1PGV

Peter K1PGV, Elmer

  • 541 Posts
  • 315 Reply Likes

Ah!  THANK you Larry... I had entirely forgotten about SharpSDR. 

Exactly.  Look at how these plugins have added value to SSDR.