[Coco] serial port problem

[Aaron Wolfe]

On Fri, Nov 1, 2013 at 2:29 PM, Mathieu Bouchard <matju at artengine.ca> wrote:
> Le 2013-10-31 à 12:46:00, Aaron Wolfe a écrit :
>
>
>> For instance, we use the CD pin on the coco as part of the read data
>> operation to achieve speeds over 115k.
>
>
> How does that work ?
>
>

The inventor/author of the technique is Darren Atkinson.  He has a
very nicely done explanation of how it works, but last time I asked
still wanted to refine it before making this document public.  That
was a couple years back... Darren if you are listening, is it OK to
"release" the info you sent me now?

The code is open source in any case, so you can look at that if it is helpful.

>> It is difficult to size some gui components to display correctly on the
>> huge range of platforms we try to support. I can make it bigger in the next
>> version.  Can you send me a screen shot of what it looks like?
>
>
> Generally, I'd rather recommend that dialogue-boxes be sized according to
> what their contents are. The GUI toolkit typically knows that size on its
> own, because it computes the size and position of every component within
> that window. Thus the best way to ensure that it always work on every OS is
> not to measure the size of the window on every OS, but rather on none of the
> OSes, and just let the software figure it out. (I don't know how to do that
> in Swing in particular, but I remember that in Tk, it's the default
> behaviour).
>
> Anyway, doesn't every OS have font-scalers that can change the required size
> of the window depending on what the user told the system ?
>

DriveWire uses SWT, not Swing.  SWT calls use native UI controls on
each supported target rather than Swing's generic implementations of
things like scroll bars, lists, combos, etc.  This allows DW to look
and feel a lot more like a native application, but it also means the
API is a bit of the lowest common denominator and there are some
limitations to what can be done.  For instance, while I can discover
the "size" of a window, I cannot know precisely how much of that size
is taken up by operating system window decorations such as scroll
bars, window borders, title bars, etc.  I implement several common
strategies to help make the best of this situation, and these of
course dynamically adjust components where possible to scale nicely.
Generally I can find a happy medium that looks fine on all modern
platforms.  When there is an exception, it is very helpful to see what
it looks like via a screenshot from the system seeing the problem.
There are a multitude of potential factors that can be difficult to
recreate accurately in a test environment.

>
>
>> You can also use the configuration editor or any text editor on config.xml
>> to manually set the port.
>
>
> BTW, it seems that exiting the app normally is « saving settings » to
> config.xml, but when I change the bps rate from the app, the bps rate does
> not appear to change at all in config.xml. Also, the wizard offers running
> the port at 19200 bps, and then the other config panel doesn't offer that
> choice. This is just FYI, because I don't need those features.

I am not sure if I understand this.  Are you changing the bps rate via
the wizard or via the config editor?  (Also...perhaps unrelated but
why would you change the bps rate?)  Changes are typically committed
to the .xml file fairly soon after they are submitted to the server,
not at exit.

I will remove the option for 19200, thats not valid on any DW
supported device afaik.