SmartSDR v3.8.19 and the SmartSDR v3.8.19 Release Notes | SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
SmartSDR v1.12.1 and the SmartSDR v1.12.1 Release Notes
Power Genius XL Utility v3.8.8 and the Power Genius XL Release Notes v3.8.8
Tuner Genius XL Utility v1.2.11 and the Tuner Genius XL Release Notes v1.2.11
Antenna Genius Utility v4.1.8
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
Possibility of Hover-Over Indication if a Slider is Active?
Taken from another thread:
COMMENT - Flex user Jim:
I feel so absolutely ****. All of this time I have been sliding the sliders back and forth on WNB, NB, NR, ANF and nothing happened. Surprise! I actually clicked on the respective buttons and a whole new world opened before my eyes. I'm not even blond...DUH...So now I'll go play for a while.
Don't judge me guys, I'm old.
Jim
REPLY: Tim - W4TME - Customer Experience Manager
Everyone deserves a Mulligan once and awhile ;-)and My thoughts:
Thinking on this, [here at work] we use an industry specific software package that if I were to adjust the settings without that feature being enabled the software in a hover-over type balloon reminds me that that in order to have my setting change affect anything that I need to activate the feature.
I recollect that if the feature is active the hover-over reflects the setting's available range and what the present setting is.
If the indication that an operator is adjusting a feature not turned on could be provided in SmartSDR it would be a nice touch?
73
Steve
K9ZW
Comments
-
You know... a dot-release of SSDR with a lot of little UI tweaks might be very popular.
Steve K9ZW's idea of providing feedback that a user is adjusting a control for a feature that is not turned-on seems to me to be sheer genius -- The user still can do the adjustment, of course, but is kept from "shooting himself in the foot."
Adding support for the OnMouseWheel event to each of the scroll bars would also be a good thing.
And, of course, there's my personal most-wanted addition: A frequency/tuning display that lets you tune like you could in PSDR (by hovering over a given digit and using the mouse wheel to increase or decrease the frequency by that digit's steps). Man, I loved that tuning method.
I'm sure the community could very easily come-up with a similar UI tweaks that would delight them.
What say, Flex folks? While it's not exactly the most interesting stuff to code-up, such tweaks would surely make SSDR even more pleasurable to use on a day-to-day basis.
Peter
K1PGV
2 -
I agree, these are all things that make operating the software better. there are some things in PSDR were Flex nailed it. To see some of those things come back to SSDR would be nice. I remember sometimes talking in a group and they decide to change Freq, I would simply change the digits with my mouse wheel, they always wondered why I was the first to get there,,lol1
-
@ Steve - Definitely. When I first got the rig and thought it was broken out of the box (such is just my luck with many purchases, it is a family joke) just because I had not clicked on the DAX button to make it blue. It seems that there are so many places in the IU to adjust/activate the same thing.
@ Peter - YES!
@Bill - I have never used PSDR, but so many people have good things to say about it I wonder how SSDR was released with several things that were patently worse in some way than PSDR. I will not get into how long it seems to take to get things up to par with the same feaature/UI arrangement in SSDR.
73 chaps.
1 -
What would be really nice is if FRS made the GUI source available. Or, better yet, made it a real open source project where commiters remain FRS employees but others could effect these types of changes. FRS would still have the final say on what gets into the release but ideas that haven't percolated to the top of their backlog list could be picked off by 'auxiliary' developers. Proprietary functions could be segregated to ancillary dlls The only downside I envision is managing expectation for those changes 'rejected'.1
-
While I like your idea Walt, I wonder what kind of support issues that could bring about? Even with FRS having final say so, I would think bugs and complaints about them, could easily get out of hand. I know from my own feeble efforts, that a "feature" I might implement, may well (and sometimes does) induce problems that did not exist before. Or, in several instances, expose coding errors on my part, that got by me when the previous "feature" was added. But, I'm certainly having fun learning! James WD5GWY0
-
Oh, and making the GUI source available, would ruin my learning experience. While I've slowed down on the Waterfall, I have not stopped. But, having the source code around would tempt me to use it instead of learning more about getting it right. Currently my version of a waterfall using the api, is dog slow. But, I will fix it. For now I'm working on getting all of the panadapter features working tight. Like a fully functional Slice receiver display on the panadapter. James0
-
Yeah... Open sourcing SSDR would be good for the community, perhaps, but absolutely bad for Flex. And, ultimately, bad for Flex is really the same as bad for the community.
The GUI is Flex proprietary value-added IP. By making the source of the GUI available as OSS, Flex lowers the barrier to entry for their competition and commoditizes the interface to their radio. This has already been demonstrated by the experience with PSDR. If you need an example, look at Apache Labs. Those guys could *never* put together their own GUI, and probably wouldn't even be in business if PSDR was not open source.
And as a reward for this act of charity to their competitors, Flex would get to "have the pleasure" dealing with overhead of managing upstream submissions by dilettantes and wannabes, and having support deal with users that are using numerous bastardized versions of SSDR that will be floating around the community (as pointed out by James WD5WY).
No... that might get us the kind of tuning features I want, but that would not a good move overall.
Peter
K1PGV0 -
It took several years to get PSDR to the place were Flex ended off, and were it is now on the last release. It was a slow going. SSDR is able to do much more than PSDR ever could, and it amazes me how a small company like Flex could even pull SSDR off at all. SSDR is light years ahead PSDR, but it is just the little things that was nice about it.0
-
If they did that , it would be on every Anan in a heart beat, I can't see them lose control, we saw what happened to PSDR. The ham world took advantage of the hard work Flex put into it.1
-
Please be clear my suggestion on the hover-owner is not an original idea, rather it is a suggestion based on other software I've used.
Also despite the confusion introduced by thread-diversion I am in no way advocating open-sourcing any significant aspect of FRS's products, period.
Many of us would consider such a change to be a complete breach of the commitment FRS made to Flex-6x00 buyers from the very start of the project - a commitment to not recreate the technical and economic problems of PowerSDR that ultimately orphaned PowerSDR.
No apologies about being so direct, as I would have never made the investment in FFS's best hardware if the software were open sourced.
Please remember that FRS has provided for anyone to do their own GUI, so you are free to roll-your-own through their developers program.
Personally not only am I okay in paying for SmartSDR major upgrades, I further hope that FRS becomes wealthy enough through sales and subscriptions to have a driving eager desire to keep building better and better versions of SmartSDR. That sort of desire to innovate isn't going to happen in a software model that denies FRS the economic rewards that it is due.
73
Steve K9ZW
8 -
Let's see James, just cause its there doesn't mean you have to view it. Just because a car has cruise control doesn't mean you have to engage it. Peter, what you say has merit but it is lessor of evils. It caught my eye when Bill used the term 'deal breaker'. Where, for those people the 'deal' was already struck, I agree with Howard, they bought the radio without it soooo.
The original form access to the source code took was via pre approved NDA only. If and where IP is an issue, revert to the NDA model. That solves the other fly in the ointment issue you raised.
You mentioned Apache Labs. I believe you don't give them enough credit. I would mention Apache Software Foundation as well as RedHat's Jboss products, all of which are open source projects. I originally envisioned working on Jboss projects in retirement. I still might after I get tired of not working. As auxiliary developers get vetted by project mgmt they can be promoted to commiter status as well.
Going back to the Jboss model, for every enterprise level product there is a community edition. Those ideas flowing from the open source community are supported by RedHat sustaining.
Yes, being a commiter adds some complexity as you become the keeper of product integrity. However, the lesser evil is it frees FRS to focus on the major features.
It's a model that works well for major vendors. Even CA Technologies open souced Ingres before they spun off Ingres Inc. In fact, the EVP of development became its first President.
Ingres is a major SQL database and was the forerunner to Postgres.
Bill, imitation is the highest form of flattery. Car companies do it all the time. Microsoft lifted their UI from Apple who licensed it from...
If it is considered IP, patent it and license its use...or not. Finishing my deal breaker thought. If it is a deal breaker to a prospect, the sooner it is implemented, the sooner it ceases to be a deal breaker.0 -
(You know, we're not going to "solve" whether OSS is a good or a bad thing here. In fact, the topic adds exactly zero value to this thread. My apologies to K9ZW for contributing to the thread drift.)
0 -
Peter, I beg to differ, I believe it adds tremendous value. For all we know executive mgmt at FRS has or will toss the idea around. As it relates to Steve it is a solution to getting his idea, along with others, implemented.0
-
Walt
It is so much more useful to start a separate thread rather than seguing ideas together, as a simple observation that a specific software enhancement has been hijacked and overshadowed by off topic ramblings.
Specifically ideas worthy of its own discussion are drowned out by brining other discussions that do not inherently have dependencies into focus.
And these other ideas never become properly searchable nor are properly discussed because they are buried due to a lack of discipline.
Speculating whether FRS hears your off topic suggestion accordioned into a thread on another subject is a further red herring, getting even further off topic.
What you have to say is important and would be best heard if presented on its own merit.
I may sound frustrated, as treating threaded discussions like an IRC channel where whatever comes to one's mind at any moment is gamely the next post seems to be a habit some of cadre often posting in the community have fallen into.
FRS are professionals, and they can decide if my suggestion is a) desirable, and b) if so, how to implement without having their hands held. It is actually pretty **** insulting to the brilliant FRS team how condescending some of the armchair quarterbacking here has become.
/rant off
73
Steve K9ZW
2 -
Rant on Steve
Some of us agree with you.
Both your original post, and your rant.
73, Jay - NO5J0 -
As you wish Steve. As for this pile-on bs, it's gotten old.
0 -
Be very clear Walt I do consider what you have to say important, in fact important enough to merit its own thread.
Appreciate your cooperation and consideration.
73
Steve K9ZW
1 -
Steve, I apologize for adding to the noise in your thread. I would suggest, as to your topic, that FRS might consider disabling (graying out) sliders etc. That depend on another control(button in this case) being clicked/selected, before actions by the second control can be effective. That would prevent making changes to a slider and nothing happening, and later coming back and clicking the button, only to find that the settings you had changed inadvertantly, messed up the settings you thought you had. Anyway just a thought. James WD5GWY0
-
Steve, I don't fault you. It is, after all, your thread. There seems to be a recurring theme in many similar posts, all lamenting why their requests have gone unadressed. It was that unifying thread I was addressing. Very early on in my career I received the following advice, "don't tell me what the problem is, tell me the solution". As for the pile on reference. There is nothing more I can say without attracting Tim's attention, but it involves middle school girls.1
-
Thinking further about the suggestion to "grey out" the unselected option - does the risk of a feature being overlooked in total occur if a selectable but unselected option is greyed-out?
Usually a software gray-out is not unselected, but is unselectable - rather the Grayed Out feature is dead.
In the case of these sliders being able to set them up before toggling the feature on is desirable, so locking the feature out as dead would be unhelpful.
73
Steve
K9ZW
1
Leave a Comment
Categories
- All Categories
- 290 Community Topics
- 2.1K New Ideas
- 536 The Flea Market
- 7.5K Software
- 6K SmartSDR for Windows
- 146 SmartSDR for Maestro and M models
- 360 SmartSDR for Mac
- 250 SmartSDR for iOS
- 231 SmartSDR CAT
- 172 DAX
- 354 SmartSDR API
- 8.8K Radios and Accessories
- 7K FLEX-6000 Signature Series
- 32 FLEX-8000 Signature Series
- 851 Maestro
- 44 FlexControl
- 847 FLEX Series (Legacy) Radios
- 799 Genius Products
- 417 Power Genius XL Amplifier
- 279 Tuner Genius XL
- 103 Antenna Genius
- 243 Shack Infrastructure
- 166 Networking
- 404 Remote Operation (SmartLink)
- 130 Contesting
- 633 Peripherals & Station Integration
- 125 Amateur Radio Interests
- 873 Third-Party Software