Hi Edson
Sorry - I obviously didn't explain the issues I was trying to fix very
well. Currently the width of the font and the window size are used to
determine the maximum number of characters that can be displayed. The
text is truncated to that length. If its too long the text gets right
justified mucking up the column alignment.
That works to a degree but has two problems. The first is that QT would
not appear to be too consistent at calculating the font width. This
results in either the last character of the line missing or the broken
column alignment.
The second issue is that because the text is already truncated when
displayed there is no further text to be revealed when the user widens
the window or reduces the font size. He has no feedback about how much
to adjust either to reveal the text he wants to see.
Rendering 'plain' fixes that. No scroll bars are added if the text goes
out the right side of the window if that is disabled in the widget.
Because the widget knows what the text is it gets nicely revealed as the
window is resized.
Apart from that the windows look and behave identically to the way it
currently is. My note about having to click on the call to get the
contact into the other window (plus all the other things that happen)
was wrong - it seems to work fine.
I mostly agree about your comment that help programs should be external;
thats the Unix way; but the best one for noting DXCC is Windows only. I
think the nature of WSJT-X with its very short decision time between rx
and tx (I mainly work portable with a little netbook and sometimes only
get a second or two to decide to tx) allows us a little leeway to
include some helpful utilities such as DXCC and worked B4 for us
non-windows users.
Hope that answers your concerns.
Cheers
Murray
VK3ACF
On 30/03/14 23:45, Edson W. R. Pereira wrote:
Hello Murray,
I was the one that implemented the current rendering. It is probably
by no means the best way to do it. It was an attempt to have
pre-formatted text displayed. Some comments below.
On Sun, Mar 30, 2014 at 1:14 AM, Murray Curtis
<[email protected] <mailto:[email protected]>>
wrote:
Hi
Now that we have a proper GUI for setting the decoded text font I'm
looking at getting that to actually work. Currently the decoded
text is
rendered as an html table in the font coded in the html header.
Changing the GUI decoded text settings effects the text size and
weight
only.
Is there any reason it needs to be an html table? I have a version
working now rendering in plain text. This gives several advantages:
* the font can be changed (although it does need to be a mono (fixed
spacing) font)
In order to maintain consistency, I think it would be ok to change the
size of the font, but not the type. Changing the size of the font in
the TextBrowser should also be propagatet to the label with the header
info.
* I can now control word wrap meaning no more truncated text
I believe this woud be * very* undesirable. The TextBrowser will
automatically add a horizontal slider in case a line does not fit.
This will preserve the columns alignment, and, in my opinion, keep UI
consistent.
* which also means the window can be resized and/or the font size
changed to reveal previously hidden text
The window is currently re-sizable. Can you elaborate?
* and that also implies we could have various font sizes (and
styles) to
clearly highlight DXCC etc
I am not sure we should worry about accommodating specific end user
needs inside WSJT-X. Helper applications could be used for this. My
position is that we could get very distracted in implementing non core
functions. Not to mention the flow of requests for implementing other
type of decoders (IOTA, all states, etc, etc.)
The only problem I've noticed is you cannot double click just anywhere
in the line to copy it to the right window - you need to hit the call
but I've not looked at why that is yet but it should be fixable.
Are there any other problems with this change I may have missed?
I see problems! :-) But they are my personal opinions. Let's see what
Joe and other developers think.
73,
-- Edson PY2SDR
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
