Actually, I think we should decouple the UI from the modem and services
(logging, spotting, etc) set and use a protocol between them. I've done
a couple of versions of this in the past, and believe that an HTTP based
approach is the right one now. (It's not quite what we have with
XML-RPC, but similar. I'm not going to complain about something that
works and is easy to author, and don't think we should move away from
it, but it's not a good play for the interoperable web space and across
different digimode application.) Right nowI'm working with a few other
people who've had this same idea. The main reason I propose this is
because it lets the modem and software-hard developers do their thing
best, and lets the UI designers do what they do. So, instead of a
"fork" of fldigi, if we had this type of approach, it'd be a new
front-end client to fldigi.
I realize this isn't an overnight change, and so I'm continuing to work
on it in the background. A common control protocol would mean that
front ends could work with multiple different programs, and I think it's
quite likely that with or without us (us, me, fldigi, et al) this will
come to pass anyway.
As an example of what this might enable, I believe that a PSK Reporter
like UI as for a digimode program is an enchanting idea, and might
appeal to a different set of people than the current style of digimode
UI, which range from MultiPSK's highly utilitiarian to HRD Deluxe's Mad
Scientist. There's no reason someone who wants to do a different UI
(map-based UI or a cloud-text UI, or even like KI6IMM who wants an
xboard front end so he can play chess over the air) should have to deal
with a complex modem system or C++ or Pascal (MultiPSK) or anything at
all remotely like that. In fact, I think an HTML+JS based UI, or an
Apple or Android toolkit UI should be trivially possible, and each will
appeal to a different set of people as users and as developers.
Leigh/WA5ZNU
On Fri, Jun 3, 2011 at 2:26 PM, John Witchell
<[email protected] <mailto:[email protected]>>
wrote:
As the gist of this thread appears to be a means of easily
determining if your transmission is within the band limits I
wonder if it would be easier to enter the actual band (or
sub-band) limits into a config page somewhere and have a line
appear on the waterfall as you approach the limit?
No, that is the kind of thinking I was hoping to foster with my
"rant". The problem is, there are entirely too many people telling me
how we should keep doing the same things instead of asking themselves
if the old methods are indeed the best.
Now I am making some assumptions here that I accept as standard. They are:
1. Rig control is the rule rather than the exception.
2. The radio/computer combination forms a communications system.
They are not really separate.
Once you make that leap then perhaps what I am talking about begins to
make more sense. We don't really need a VFO control in fldigi. We
already have one on the rig. You don't really need an extra one. OTOH,
we *could* have a single frequency control for our emission. That
single control would actually control two function -- VFO frequency
and audio subcarrier. The setting of that control would then be
reflected in the display of emission center frequency. Yes, all of
this already appears in one fashion or another in fldigi as it stands.
I am just pushing everyone to start thinking about a different way of
viewing things and no longer focusing on the VFO setting on the rig.
--
Brian Lloyd, WB6RQN/J79BPL
3191 Western Dr.
Cameron Park, CA 95682
[email protected] <mailto:[email protected]>
+1.767.617.1365 (Dominica)
+1.931.492.6776 (USA)
(+1.931.4.WB6RQN)
_______________________________________________
fldigi-alpha mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/fldigi-alpha
_______________________________________________
fldigi-alpha mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/fldigi-alpha
