Re: [lmi] Really long string in messagebox [Was: Running external programs like 'fop' from lmi]

[Vadim Zeitlin]

On Tue, 19 Jun 2007 13:58:00 +0000 Greg Chicares <address@hidden> wrote:

GC> > OTOH it could be useful to add a separate function showing a possibly long
GC> > message comfortably to the user. Maybe even simply modify the default
GC> > wxLogDialog to use something other than wxMessageBox in this case: as it
GC> > already doesn't use the native message box when there is more than one log
GC> > message and already has "Save" button, I actually think this would be the
GC> > best thing.
GC> 
GC> "Save" writes a file, IIRC.

 Yes, my point was just that it's already a non-standard button so it
wouldn't be a problem at all to add a "Copy" one as well.

GC> I just added this task:
GC>   https://savannah.nongnu.org/task/index.php?7018

 Thanks!

GC> Anyway, I had actually experimented with
GC> 
GC>         wxLogError(oss.str().c_str());
GC>         wxLog::FlushActive();
GC> 
GC> instead of calling wxMessageBox() to show the ostringstream's
GC> contents, but the behavior seemed indistinguishable. I guess
GC> a single string of '\n'-delimited lines needs to be separated
GC> into "more than one log message" as you note above.

 Exactly, currently wxLogGui uses wxMessageBox if there is a single message
to show.

GC> BTW, do you really mean "wxLogDialog"?

 It's the (private) dialog class used by wxLogGui.

GC> (b) Messages written to a wxLog appear asynchronously, in idle
GC> time, provided that no higher-priority message is queued--so an
GC> "error" displaces a "warning". Or so I think: see
GC>   https://savannah.nongnu.org/bugs/?20207

 Yes, you're right (both in what you think and concerning the documentation
problems).

GC> Well, anyway, lmi often needs to display a message while a
GC> lengthy operation is running; and I think we have informational
GC> messages that should be displayed even if higher-priority errors
GC> arise; so that's why I always use wxLog::FlushActive(). It's not
GC> that I dislike wxLog--it's just that I regularly use it with
GC> explicit flushing.

<OT rant>

 In fact the main point of wxLog is this postponement of the error messages
until the idle time. The initial motivation for writing it was that I hated
with passion the common habit of Windows programs to show half a dozen
message boxes whenever anything went wrong. This became less of a problem
later but I suspect that the main reason is that errors happen less often
now (you hardly ever see "Disk is full" or "Out of memory" errors any more)
and not that the programs are that much better written -- many of them
still display several message boxes when network connection goes down for
example.

</rant>

 So I think the idea of deferring the errors display until the next event
loop iteration is a sound one. It encourages logging more errors (which can
contain valuable information) without overwhelming the user with message
boxes.


GC> Here's one further idea that I chose to separate from
GC> the rest of that task because it may be much bigger and
GC> ought to be discussed first:
GC> 
GC> (3) As an additional alternative to (2)(a), let's discuss
GC> a "mail this message to the maintainer" button that would
GC> open a new email and insert the message contents into it,
GC> provided that can be done in a way that doesn't favor any
GC> proprietary platform over GNU/Linux. It may be that the
GC> other facilities would belong partly or entirely in wx
GC> but this one wouldn't. We might also attach an archived
GC> copy of the applicable input file if that can be readily
GC> determined.

 This is indeed a rather complicated subject. We discussed recently
integrating facilities for sending email into wx and decided against it
simply because it is too difficult, especially nowadays when you often
can't just use SMTP directly because the SMTP traffic can be filtered by
the ISP as anti-spam measure. So instead we'd have to detect the best way
to send email from each platform, meaning MAPI under Windows, different
things under KDE and Gnome under Linux and at least 3 or 4 popular MUAs
under Mac OS X. And even using SMTP directly is not that easy anyhow if you
want to support attachments (and almost everyone interested in sending
email from a program does). So after thinking about all this, the
conclusion was that we didn't have the resources to do it.

 A possible alternative to using email is to upload the bug reports to a
web server via HTTP. All users usually have access to the Web so there
shouldn't be any problems with firewalls. We still have to implement HTTP
upload and this can be non-trivial especially if security is important and
HTTPS (not currently supported by wx) is to be used. Also, while setting up
a web server for receiving these uploads is technically easy I'm not sure
if it doesn't create any administrative problems in your case.

 So the only thing which we can *easily* do -- and which should be done --
is to allow to the program to add custom buttons to this generic message
box to customize or augment the default behaviour. BTW, this is what we did
for wxDebugReport which had exactly the same problem: a debug report (a
crash report, really) is a huge binary file so you have to send it by email
or upload it via HTTP, but wx currently doesn't have direct support for
either. To cater for this, the debug report classes allow to override a
virtual function to implement whichever action is the most appropriate for
each particular program. So while by default the file is simply left on the
users system, my own program, being a MUA and so knowing something about
sending email, can send its own crash reports by email without any problem.

 To summarize, we should in any case allow customizing the message box.
And, if you think it is worth it, we can also add support for HTTP
uploading to wx itself. But if you need email capabilities I think it would
be better to implement this in a separate, add-on, library rather in core
wx itself (we'd still be glad to do it, of course).

 Regards,
VZ