Re: Stop making unneeded improvements

[paul]

Prompted to write by Glen Langston's post, I'm an old man resurrecting 
an old moan, and in a minority that (I believe) is just not catered for:

* Windows user
* Non-programmer (of any great consequence)

A couple of years ago I became hooked on GRC after watching Balint 
Seeber's YouTube videos that convinced me this was a great 
non-programming solution to a long-standing problem of mine.
True, after 6 months I managed to fumble my way to a flowgraph that 
sort-of got the job done. But there were serious limitations, such as WX 
widget deficiencies including only mono audio stream for some 
sources/sinks (just how out-of-date can you be in the 21st century?).
So I tried to migrate to QT, and what happens? Every one of the 
replacement widgets looks and behaves differently from its predecessor 
and, in several cases, has significantly reduced functionality.
Add in inexplicable control gaps like decade "thumb-wheels" (for tuning) 
or command buttons (e.g. to increment a variable by a preset amount) and 
it's clear that Gnu Radio Companion fails to replicate anything like a 
basic RADIO front panel.
I won't even start moaning about changes to Python versions and 
libraries.
What kind of a development strategy is that? It's no excuse that you 
rely on a team of volunteers. If you want quality you need leadership, 
direction and team players - every programmer following his own whim to 
produce "cool stuff" on his own agenda is a recipe for disaster. I've 
been a "volunteer" myself for 15 years, trying to put something back 
into the radio community I love, with never a cent in return, and don't 
do "cool stuff".
BTW under "cool stuff", I include the disgraceful self-promotion and 
waste of valuable time in the YouTube video 
https://www.youtube.com/watch?v=bHjITd2HR-g&ab_channel=GNURadio.
The golden rules for development include doing the basics well, 
backwards compatibility, not breaking what already works, incremental 
improvement, giving priority to fixing bugs/defects, and testing, 
testing, testing. GRC has broken all of these big time over the years.
If during my working life I had been so cavalier in my attitude, I would 
have lost my job many times over.
I suppose the real problem (for me) is that GRC is written by DSP 
experts for DSP students who get by with a little help from their 
friends, adding a bit of Python here and C++ there. In other words, GRC 
is *not* the general purpose learner's tool that comes across in the 
Balint intro.
As for the lack of support for Windows, how can you possibly ignore 
(more-or-less) the No. 1 operating system with its large pool of users 
hungry for GRC-type tools? If your fundamentalist fixation on *nix 
prohibits contact with the unclean, please have the honesty to label 
your product accordingly.

I repeat my acceptance of being in a minority, apologise too for the 
rant, and realise it will not make any difference. But best wishes for 
the future.

Paul White