Re: [lmi] May 2018 wx upgrade

[Greg Chicares]

On 2018-04-30 16:44, Vadim Zeitlin wrote:
> On Mon, 30 Apr 2018 15:11:26 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Thanks. Our [2018-05-01, 2018-05-31] release has just been announced.
> GC> It would be ideal to upgrade wx for the [2018-06-01, 2018-06-30]
> GC> release, where no significant user-visible change in lmi code is
> GC> planned: that way, we can spend plenty of time testing the wx upgrade
> GC> in advance, and if it unexpectedly causes any problems for end users,
> GC> we can revert it without losing any big new feature they care about.
> 
>  I see, thanks. Just to check that I am not forgetting anything: were there
> any other wxWidgets enhancements potentially useful for lmi? So far this
> upgrade will have 2 of those: liblzma support and the changes discussed
> here, am I forgetting anything else?

No, I don't think so.

As for liblzma support, wasn't some small bit of remaining work needed,
in lmi itself, to bring all the pieces together so that xz-compressed
MST files would be decompressed automatically? (That doesn't need to be
done just yet; I'm just asking so that we don't forget.) Oh, and will
the wx-xmlwrapp-libxml2 chain of tools recognize xz compression without
any identifying extension? We anticipate that lzma is rare enough in the
msw world that compression can serve as well as encryption, the goal
being to discourage end users from modifying MST templates...but if we
add '.xz' then even a mildly curious end user might figure it out easily.

>  Looking at my lmi TODO, I only see various Wine bugs (black and white
> icons, corrupted wxSpinCtrl etc) and, also, in a rather chronologically
> remote part of it, mention of "textlength" XRC attribute that was supposed
> to be added to allow specifying text controls/comboboxes/other similar
> controls withs in terms of their contents, rather than dialog units. Would
> anything of this (or, again, of the possibly but not certainly empty set of
> things I'm forgetting) be useful enough to try to include it in this
> upgrade?

I can't think of anything. As for "textlength"...

Today we assume that the widest letter is 'M' or 'W':

    <object class="wxComboBox" name="StateOfJurisdiction">
        <style>wxCB_DROPDOWN|wxCB_READONLY</style>
        <content><item>MM</item><item>WW</item></content>

and, a couple weeks before Christmas 2015, when we discussed alternatives:

GC> Is there a reasonable way for a "longesttext" attribute to accommodate
GC> the true widest letter, which may be either "M" or "W"? Perhaps we could
GC> specify it more than once and take the greater:
GC>   <object class="wxComboBox" name="StateOfJurisdiction" longesttext="MM" 
longesttext="WW">
GC> but no, that's not well-formed xml. Another idea:
GC>   <object class="wxComboBox" name="StateOfJurisdiction" longesttext="MM|WW">
GC> but that requires reserving '|', which isn't good. What about writing:
GC>   <object class="wxComboBox" name="StateOfJurisdiction" 
longesttext="&mdash;&mdash;">
GC> and treating "&mdash;" (and perhaps literal em dashes:
GC>   <object class="wxComboBox" name="StateOfJurisdiction" longesttext="——">
GC> for terseness and convenience) specially in this case, attributing to it
GC> the actual (calculated for the font) maximum character width rather than
GC> the actual width of an em dash?

you thought that something like <textlength>2</textlength> might be better
than <longesttext>WW</longesttext>.

Yet my lame "MM","WW" workaround did seem to resolve any practical problem
with native MSW, while with wine it's the kind of thing I train myself to
overlook. We could do this someday when you're really bored, I guess, but
nobody is clamoring for it.