lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [PATCH] Add --gui_test_path command line option to the GUI tes


From: Greg Chicares
Subject: Re: [lmi] [PATCH] Add --gui_test_path command line option to the GUI test.
Date: Tue, 03 Feb 2015 20:25:17 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0

On 2015-02-03 18:57, Vadim Zeitlin wrote:
> On Sun, 01 Feb 2015 16:32:43 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 02/01/2015 11:47 AM, Vadim Zeitlin wrote:
> GC> > On Sat, 31 Jan 2015 23:42:09 +0000 Greg Chicares <address@hidden> wrote:
> GC> > 
> GC> > GC> Having just built lmi on debian, I figured this was the perfect 
> time to
> GC> > GC> return to this old email that I had marked for followup: I haven't 
> put
> GC> > GC> any of the proprietary test files here, so...
> GC> > GC> 
> GC> > GC> I've rebuilt wx, even though it's still using gtk+-2; this works 
> fine:
> GC> > GC> 
> GC> > GC> /opt/lmi/build[0]$LD_LIBRARY_PATH=/usr/local/lib:/opt/lmi/local/lib 
> ./lmi_wx --ash_nazg
> GC> > GC> 
> GC> > GC> However, the GUI test doesn't work, presumably due to the special 
> way
> GC> > GC> it starts up (this is wx-3.1 git HEAD as of this morning, BTW):
> GC> > GC> 
> GC> > GC> /opt/lmi/build[0]$LD_LIBRARY_PATH=/usr/local/lib:/opt/lmi/local/lib 
> ./wx_test --ash_nazg
> GC> > GC> 
> GC> > GC> (process:5081): GLib-GObject-CRITICAL **: 
> /tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gtype.c:2722: You forgot 
> to call g_type_init()
> GC> > ...
> GC> > 
> GC> >  I can confirm that I see this as well and it happens because the code
> GC> > attempts to show a wxMessageBox before initializing GTK+. I clearly 
> need to
> GC> > fix this to avoid hanging/crashing in this case, but the trouble is that
> GC> > it's not that obvious as there is no simple equivalent of
> GC> > wxSafeShowMessage() in wxGTK.
> GC> 
> GC> Could we not do something like this in lmi at least?
> GC> 
> GC> #if defined wxGTK_or_whatever_the_macro_is
> GC> void wxSafeShowMessage(char* s) {std::err << s << std::endl;}
> GC> #endif // defined wxGTK_or_whatever_the_macro_is
> 
>  This is actually exactly what wxSafeShowMessage() itself does under
> non-MSW platforms currently, so to achieve this behaviour it would be
> enough to just wxSafeShowMessage() instead of warning() in
> application_test::process_command_line().

Doesn't warning() delegate to wxSafeShowMessage()? Oh--I guess
it doesn't do so any longer since this revision:
  
http://svn.savannah.nongnu.org/viewvc/lmi/trunk/alert_wx.cpp?root=lmi&r1=5853&r2=6051
discussed here:
  http://lists.nongnu.org/archive/html/lmi/2014-12/msg00028.html

Should that be reverted, at least in the GTK case? Or can wxGTK be
changed in the way that (AIUI) wxMSW was? See:
  http://lists.nongnu.org/archive/html/lmi/2014-12/msg00013.html
| there are actually several problems with using wxMessageBox before wxTheApp
| is available :-( I fixed all of them in wxWidgets and the git tree
|
|         29cd13cc8f06eab726d3b774e057b64c94570923
|
| contains all of these fixes

>  Thinking more about this, do we actually need to use any of warning(),
> wxMessageBox() or wxSafeShowMessage() here? As this function deals with the
> command line parsing, it seems reasonable to suppose that the program was
> launched from some kind of a terminal and so perhaps we should just show
> all output from it on standard output or error streams? Should I make the
> (trivial) patch implementing this?

For wxMSW at least, I think a messagebox is indispensable (and perhaps
for wxGTK if any of our end users ever switch to that). The reason is
that end users launch lmi from a shortcut, never from a terminal. If the
parameters hidden in the shortcut become invalid for any reason, then lmi
will fail silently, discomfiting the user.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]