Re: [lmi] [lmi-commits] master 3b168ba 2/3: Use warning() + alarum() for schema validation failure

[Vadim Zeitlin]

On Fri, 20 Jul 2018 13:50:26 +0000 Greg Chicares <address@hidden> wrote:

[...]
GC> > I really don't think it's
GC> > acceptable for wxMessageBox() to segfault, for any input length (it might
GC> > truncate the string, in the worst case, but still not segfault), so, 
again,
GC> > I'd like to know if we have any way to reproduce this problem (which would
GC> > help to fix it)?
GC> 
GC> I'd accept that no error is reproducible if we demonstrate that
GC> calling code like this:
GC>   std::string s = {some initializer of size at least one megabyte);
GC>   throw std::runtime_error(s);
GC>   warning() << s << LMI_FLUSH;
GC>   alarum() << s << LMI_FLUSH;
GC> at each of the "WX !!" points above, and at both the earliest and
GC> the latest possible moment in startup and termination, always
GC> behaves as desired.

 OK, I've added a note to my TODO file to test this later.


GC> >  I think showing 2 message boxes in a row like this is a usability bug and
GC> > would very much prefer to avoid it. If the problem with wxMessageBox() can
GC> > be reproduced, then it can probably be fixed as well. If it can't, I think
GC> > the best would be to use wxRichMessageDialog for warning() and should just
GC> > a short excerpt of the message (until the separating blank line?) in the
GC> > main part of the dialog and the long text in the part that can be expanded
GC> > by the user to see the details.
GC> 
GC> http://docs.wxwidgets.org/3.1/classwx_rich_message_dialog.html
GC> | Notice that currently the native dialog is used only under MSW when using
GC> | Vista or later Windows version. Elsewhere, or for older versions of 
Windows,
GC> | a generic implementation which is less familiar to the users is used. 
Because
GC> | of this it's recommended to use this class only if you do need its extra
GC> | functionality and use wxMessageDialog which does have native 
implementation
GC> | under all platforms otherwise.
GC> 
GC> Apparently msw is favored, and a program that uses wxRichMessageDialog
GC> would work less well on a free operating system: that doesn't seem
GC> appropriate for free software hosted by the FSF.

 I really can't agree with this logic. wxWidgets has plenty examples of
classes implemented natively for one of the platforms, but not [all] the
others and most of them are actually widgets implemented natively under
MSW, but not under GTK, such as e.g. wxListCtrl that used to be used by lmi
(and was replaced by wxDataViewCtrl which is a rare example of a control
that is native when using GTK but not when using MSW) and wxDatePickerCtrl
which is still used in many places, but only uses native implementation
under MSW and Mac, but not under GTK. And I'm sure there are plenty of
other examples, so it would be strange to single out wxRichMessageDialog
for some reason.

 Moreover, MSW is not "favoured" in any way here, the functionality is
available under all platforms and just uses the most appropriate
implementation under each of them which is the basic tenet of wxWidgets
design philosophy. If you absolutely wanted to have exactly the same UI
under all platforms, we could use wxGenericRichMessageDialog but what would
be the point to punish MSW users with less familiar and less native looking
interface?

 Perhaps you're reading too much in the documentation quote above but I can
assuredly (being the person who wrote it...) tell you that it just says
that you shouldn't blindly use wxRichMessageDialog for all your message
dialogs, because this would look less native under non-MSW platforms, and
was absolutely never meant to imply that you should avoid it if you do need
its extra functionality.


GC> >  Please let me know if I can help with really fixing the problem, instead
GC> > of using this (IMNSHO pretty ugly) workaround with 2 dialogs.
GC> 
GC> Not this month.

 Yes, of course. I just wanted to react to this commit message before I
forgot everything about it, but right now I'm working on pagination
problems and I understand perfectly well that they're the priority.

 Regards,
VZ