Re: [lmi] May 2018 wx upgrade

[Vadim Zeitlin]

On Mon, 30 Apr 2018 17:52:03 +0000 Greg Chicares <address@hidden> wrote:

GC> As for liblzma support, wasn't some small bit of remaining work needed,
GC> in lmi itself,

 Yes, lmi hasn't been modified at all yet. But this shouldn't require any
changes in wxWidgets (hopefully).

GC> to bring all the pieces together so that xz-compressed MST files would
GC> be decompressed automatically? (That doesn't need to be done just yet;
GC> I'm just asking so that we don't forget.)

 It's in my TODO list but maybe we should use Savannah issue tracker
instead...

GC> Oh, and will the wx-xmlwrapp-libxml2 chain of tools recognize xz
GC> compression without any identifying extension?

 I'm not sure, looking at libxml2 code it looks like it doesn't rely on the
file extension at all, but I don't quite understand what exactly does it
rely on to detect the input format. If I do read its code correctly, it
seems to apply LZMA decompression by default for all input, so we shouldn't
have any problems with this, but I should probably test it.

 In the worst case, we could always do the same thing as we plan to do for
the .mst.xz files, i.e. load and decompress them ourselves (which is simple
now using the LZMA decompression support in wx) and then use xmlwrapp and
libxml2 with plain XML data. But, again, we probably won't have to do this
and, in any case, this is not really related to wx.


GC> >  Looking at my lmi TODO, I only see various Wine bugs (black and white
GC> > icons, corrupted wxSpinCtrl etc) and, also, in a rather chronologically
GC> > remote part of it, mention of "textlength" XRC attribute that was supposed
GC> > to be added to allow specifying text controls/comboboxes/other similar
GC> > controls withs in terms of their contents, rather than dialog units. Would
GC> > anything of this (or, again, of the possibly but not certainly empty set 
of
GC> > things I'm forgetting) be useful enough to try to include it in this
GC> > upgrade?
GC> 
GC> I can't think of anything. As for "textlength"...
GC> 
GC> Today we assume that the widest letter is 'M' or 'W':
GC> 
GC>     <object class="wxComboBox" name="StateOfJurisdiction">
GC>         <style>wxCB_DROPDOWN|wxCB_READONLY</style>
GC>         <content><item>MM</item><item>WW</item></content>
GC> 
GC> and, a couple weeks before Christmas 2015, when we discussed alternatives:
GC> 
GC> GC> Is there a reasonable way for a "longesttext" attribute to accommodate
GC> GC> the true widest letter, which may be either "M" or "W"? Perhaps we could
GC> GC> specify it more than once and take the greater:
GC> GC>   <object class="wxComboBox" name="StateOfJurisdiction" 
longesttext="MM" longesttext="WW">
GC> GC> but no, that's not well-formed xml. Another idea:
GC> GC>   <object class="wxComboBox" name="StateOfJurisdiction" 
longesttext="MM|WW">
GC> GC> but that requires reserving '|', which isn't good. What about writing:
GC> GC>   <object class="wxComboBox" name="StateOfJurisdiction" 
longesttext="&mdash;&mdash;">
GC> GC> and treating "&mdash;" (and perhaps literal em dashes:
GC> GC>   <object class="wxComboBox" name="StateOfJurisdiction" 
longesttext="——">
GC> GC> for terseness and convenience) specially in this case, attributing to it
GC> GC> the actual (calculated for the font) maximum character width rather than
GC> GC> the actual width of an em dash?
GC> 
GC> you thought that something like <textlength>2</textlength> might be better
GC> than <longesttext>WW</longesttext>.

 Yes, "textlength" was an abbreviation for "something like textlength or
longesttext or something else performing the same function". I don't think
if we really decided on anything back then because while longesttext is
better for the state abbreviations or ZIP codes ("99999" could be
significantly more narrow than "WWWWW"), it doesn't work very well if you
want to limit some entry to 50 characters because typing 50 "W"s in a row
is not very fun nor readable. And while ideally nobody would ever need to
use arbitrary limits like 50 characters, it's probably going to be required
in practice.

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

 I will leave this item in its hibernation in the middle (not even the
tail...) of my TODO list, but I just wanted to mention that the main
advantage of longest-whatever was not that it allowed to use something
other than "WW", but that it didn't actually appear in the control. I.e.
the above XRC fragment works for lmi because the combobox contents is
overwritten by the model values as soon as it's created anyhow, but if this
were not the case, you'd not only have "WW"-sized combobox, but would also
actually have "WW" in it which wouldn't be very useful (unless it's all in
preparation for Western Wakanda joining the Union as a new state).

 Regards,
VZ