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]
> 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

Reply via email to