[lmi] message/log dialogs enhancements task

[Vadim Zeitlin]

 Hello,

 I spent some time during the last couple of days working on this task:

        https://savannah.nongnu.org/task/?7018

There are several problems/potential enhancements mentioned there so I did
several things (all of them in svn trunk only for now but some of them
could be backported to 2.8 branch later):

1. Under MSW the static text showing the message is replaced with an edit
   control with a vertical scrollbar if the message box doesn't fit on the
   screen (and the message box is resized to fit). This takes care of the
   point (1) and while the code is non-trivial as I tried hard to interfere
   as little as possible with the native MessageBox() implementation, the
   results seem to be good and so I consider this problem to be solved. I
   do want to test it more before back porting it to 2.8.


2. To address the point (2a) -- make it possible to easily copy the text of
   the message box -- I did two things. The first one was simple: I added
   the "Copy" button to wxLogDialog, which is the dialog used by wxWidgets
   when there are more than one messages to show. I did not implement
   Ctrl-C behaviour for this dialog because I decided that this operation
   is not that common to need an accelerator (right now you have to do
   Alt-D to expand the "Details" pane and then Alt-C to activate the copy
   button so it's still relatively easy to do from keyboard) and that 99%
   of the users would never use it anyhow as nobody would know about it.
   Please let me know if you disagree.

   The remaining task was to fix the problem also for the case of a single
   message dialog for which currently just a message box is used. In order
   to do it I enhanced wxMessageDialog to allow specifying custom labels for
   the message box buttons as my initial idea was to show a message box
   with "Copy" and "OK" buttons (instead of just "OK" one). This does work
   now but unfortunately suffers from one obvious (in retrospect) problem
   which I had somehow failed to think about: the user expects "Copy"
   button to copy the message box contents to the clipboard but it not only
   does this but closes the message box as any button in it does. As much
   as I'd like to use this approach (after all I did spend quite some time
   on this custom label stuff) I think this is unacceptable and workarounds
   like using a button named "Copy and close" don't seem too appealing
   neither. Again, please let me know if you disagree and think that this
   behaviour is acceptable from LMI point of view.

   If not, we need some other way. I could persevere with trying to hack
   the message box to prevent it from being closed when this button is
   pressed and while this should be doable I feel like I need to stop and
   ask myself whether this is still the right approach. An obvious
   alternative would be to use a custom dialog with "Copy" button -- but
   this has a not less obvious drawback of not being a standard dialog,
   unlike a message box (even with custom buttons). Another possibility
   would be to always replace the static text control with an edit one (and
   not only when we need the vertical scrollbar of the latter). This
   wouldn't solve the discoverability issue mentioned in (2a) however.
   Do you have any other/better ideas?


3. Finally concerning the second comment: to my great surprise (I thought
   better about Microsoft...) I could reproduce the problem fairly easily
   by sending a ~1MB string to the message box -- after spending an
   inordinate amount of time trying to break it into lines it failed to
   create the actual dialog for some reason and so returned 0 return code
   which wxWidgets happens to not handle and so the net effect was as if
   nothing happened at all.

   Again, I'm not sure about what should we do here. We could try to
   pro-actively truncate the string to some reasonable length (although
   it's difficult to determine what such length would be). We could do the
   same reactively, i.e. only after the message box fails to show (but this
   would still leave the user wondering what's going on while the layout is
   happening, which can take a long time for such jumbo strings). Or we
   could avoid truncating the string at all and just notify the user that
   the message couldn't be shown. I think the best would be to impose the
   maximal size (i.e. choose the first solution) even if we don't know what
   it should be as such calls should hopefully be rare. I also think we
   should choose something relatively small (32KB? 64KB?) to ensure that
   the message box is shown quickly even on slow machines. What do you
   think?


 Incidentally, I also improved wxLog documentation while working on all
this and I believe it should be more clear and informative now, please
see http://docs.wxwidgets.org/trunk/classwx_log_gui.html (and the logging
customization section linked from there). And I also made it easier to
customize the behaviour of wxLogGui (this part can't be backported to 2.8
though so LMI wouldn't profit from this in the near future) and enhanced
the dialogs sample to show how to do it, as well as adding a test for the
various message box features, including the new ones. In particular, you
can see the vertical scrollbar in it by entering more text than can fit on
the screen in the "Test Message Box" dialog there. Please let me know if
you'd like me to build a binary of the dialogs sample for you from 2.9
sources so that you could test it.

 And, once again, I'd welcome any ideas about how to deal with the problem
(2) above and also any suggestions about (3).

 Thanks in advance,
VZ