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

[Greg Chicares]

On 2007-06-18 12:47Z, Vadim Zeitlin wrote:
> On Mon, 18 Jun 2007 12:20:15 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> > 2) When the error output is too large the message box won't fit on the
> GC> > screen (vertically), as a result 'Ok' button is invisible and user
> GC> > could guess and type <Enter>, or close the dialog via small button or
> GC> > via <escape>. This could be fixed by using a custom dialog window with
> GC> > scrollbars when needed. It could also go into wx -- a change that
> GC> > would either add a flag wxSHOW_SCROLLBARS, or add scrollbars
> GC> > automatically when needed.
> GC> 
> GC> I'd be happy to see such a change in wx, if the maintainers
> GC> like the idea.
> 
>  I like the idea in principle but it's impossible to implement it with a
> native message box. So while we could have something like this, it wouldn't
> look right (on any platform) and so it doesn't seem like it would be a good
> idea to show it just because an innocently looking style was specified.

Okay.

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

"Save" writes a file, IIRC. I just added this task:
  https://savannah.nongnu.org/task/index.php?7018
which explains that our users would prefer copying the message
to the clipboard.

Anyway, I had actually experimented with

        wxLogError(oss.str().c_str());
        wxLog::FlushActive();

instead of calling wxMessageBox() to show the ostringstream's
contents, but the behavior seemed indistinguishable. I guess
a single string of '\n'-delimited lines needs to be separated
into "more than one log message" as you note above.

BTW, do you really mean "wxLogDialog"? I don't find that in
wx-2.8.3, though it's mentioned in some wx-dev messages from
knowledgeable people.

> But I don't know if you're ready to use wxLogXXX() instead of
> wxMessageBox() in LMI -- are you?

Actually, I use it all the time--hidden behind cover functions.
For example, lmi's warning() is "flushed" this way:
    wxLogWarning(the_warning_string.c_str());
    wxLog::FlushActive();

Two of the reasons why I use cover functions:

(a) They let me use the wx behavior in wx builds, without any
dependency on wx for command-line-interface builds--which are
going to become very important for business reasons.

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

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

> GC> Since we're discussing a change to wxMessageBox, let me suggest
> GC> another: add a flag like wxSHOW_COPY_BUTTON, which would
> GC> 
> GC> (a) Visually inform the user that such a facility is available.
> GC> On msw, Ctrl-C does this, but few people know that, and I have
> GC> received screen-print bitmaps in email that use hundreds of
> GC> kilobytes just to show me a brief text diagnostic.
> GC> 
> GC> (b) Improve on what Ctrl-C does on msw by filtering out the
> GC> "---------------------------" lines and buttons, e.g.
> 
>  Again, this is not something we can do with the native dialog
> unfortunately. And this is also something which we could/should add to the
> wx log dialog. Please open a bug if you want to spend some time (it
> shouldn't take very long) on improving it.

Added to the tracker:
  https://savannah.nongnu.org/task/index.php?7018

Here's one further idea that I chose to separate from
the rest of that task because it may be much bigger and
ought to be discussed first:

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