Hi Bill,
Thanks for the thorough reply. GUI changes are quite hard since we get used
to the layout and people have different use patterns. But I think there are
some improvements we could do on wsjtx UI.
My comments follows inline below.
On Thu, Mar 9, 2017 at 3:37 PM, Bill Somerville <[email protected]>
wrote:
> HI Edson,
>
> some comments in line below.
>
> On 09/03/2017 16:54, Edson W. R. Pereira wrote:
>
>
> 1. The band selector can go up to the menu before the mode menu.
>
> This will be difficult, on Mac and some Linux Desktops the menu is not
> rendered by Qt and cannot contain non-traditional UI components like line
> edits and combo boxes. What is the reasoning for moving this control onto
> the menu?
>
Good point. Being a Linux XFCE user, I often forget about some of the
nuances on different OS'es. My suggestion was not to move the selector, but
use a menu to "select" the desired band. My reasoning is that if the mode
is a menu, perhaps the band should also be. I have nothing against the
selector itself. Although currently the information displayed when the
selector is clicked is truncated due to the width of the selector.
>
>
> 1. The rig status light can be turned into a QLabel and should go to
> the status bar with the text "Rig" in it. Colors should be the same as the
> current light indicator. Plus grey if no rig is currently selected.
>
> This is a good idea. The current button, yes it is click-able, takes up
> more UI space than is necessary. If it were changed to a simple indicator
> in the status bar then I would suggest adding a menu action to reset the
> rig control.
>
Ok. The menu action is a good idea.
>
> The input level slider can be eliminated
>
> This has had some recent discussion. Keeping it does have some merit but
> perhaps not with the current functionality which is a master level control
> for the waterfalls. It could be come an adjuster for the o/s audio device
> level although adjusting that level away from 0dB FS has no advantage.
> Maybe remove it and add the o/s audio device fader level in dB to the
> status bar -- this is not totally straightforward as there is no
> notification of changes available.
>
The audio device fader could be a problem as some sound devices do not have
a fader or if they do have, they have no effect. Case in point, I use an
audio loopback device on Linux to route the audio from a SDR app to wsjtx.
Pulseaudio shows a fader for the device, but it has not action since the
native ALSA loopback device has no mixer.
>
> The level meter can be flipped horizontally with the same width as the
> frequency indicator, replacing where the DX Call and DX Grid labels and
> text inputs are currently located.
>
> Due to the decodes windows requiring as much vertical space as possible we
> must be careful not to add extra height to the bottom sections. Are you
> proposing to drop the Call and grid labels from the UI?
>
One of my intentions is actually see if the vertical space for the lower
part of the main window can be reduced slightly. The flipping of the meter
level would be just to have a clearer and consistent layout. But I need to
implement and "look" at it to feel if it is ok. I am considering dropping
the call and grid labels and format the call, grid, azimuth and distance in
a group box. But again, I need to implement it and see if it looks ok.
>
> The DX info widgets and log buttons should be moved to the bottom of the
> center area in dedicated widget group (next to the QSO area).
>
> What are the "log buttons"? It should be noted that the lower centre area
> is very full, this does not become apparent until a a mode like fast JT9 is
> selected. This change would probably reduce the space available for decodes.
>
By log buttons I mean the "lookup" and "add" buttons. I thing they should
remain close to the dx information (call, grid, etc). With the
reorganization of the widgets there should be more space in the central
part of the layout for the mode-specific controls. One future change we may
consider is having separate controls for each mode using a StackedWidget.
This may simplify implementing controls for new modes, ease the switching
between modes and have the UI layout adjusted for each mode instead of
hiding unused control widgets.
Do we need the "Report" SpinBox? If so, in what circumstances should it be
used? I ask because I've used it (and I hope it was not used by none of the
stations that have replied to my cq).
>
> The frequency label, horizontal level meter, and time label should be
> moved to the right border of the main window.
>
> This would be reasonably intuitive if the band selector/frequency input
> was there too but I believe this will increase the horizontal width with no
> obvious advantage.
>
If the level meter is flipped and moved below the frequency label, the
space left behind should be used. Let me see what I can come up with.
>
> The QSO TabWidget should be replaced by a StackedWidget. The selection of
> which QSO interface to use will be in the general settings window. This
> will free up the space currently being occupied by the TabWidget "ears".
>
> I would suggest that if this were done then a pair of checked actions in
> the "View" menu should be used to select rather than burying the option in
> the settings. I would also suggest that the tab one "Generate Std Msgs"
> button does not really earn its place on the UI and I have wondered several
> times if it could be dropped in favour of automatically regenerating the
> messages when the "DX Call" line edit changes.
>
Ok. The menu action is a better idea than my suggestion for making the
selection via the configuration window. I agree getting rid of the
"Generate Std Messages". I have never used the button myself. Whenever I
need to regenerate the messages, I double click on the callsign of the dx
station. Let's see Joe's opinion on getting rid of the button.
>
> The time bar graph in the status bar seems redundant and should be removed
> as it looks strange to have a bar graph in the status bar. Or it can be
> replaced by a QLabel indicating that audio is being recorded.
>
> Progress bars in the status bar are not that uncommon, in fact the Mac OS
> X native progress bar is particularly narrow making this usage compatible
> with their UI guidelines. It is a stretchable element so does not take up
> much space.
>
True. May be the present bargraph could be made a little narrower.
> A label indicating that audio is being recorded is almost to implement due
> to the way WSJT-X deals with saving .WAV files, they are always recorded
> but are discarded later if there is no reason to keep them. This decision
> is made around 3/4 through the next T/R period.
>
Point taken.
> Not trying to shoot down you suggestions, just adding some implementation
> constraints that would effect them.
>
All points are well put and make a lot of sense. I will start implementing
the changes one group at a time and will present some snapshots to the team.
73, Edson PY2SDR
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
