Hi Alan
I've never tried building wxWidgets from source on Linux - I just installed the
dev packages on my Ubuntu machine - which is only 2.8.12 I think.
One item that might be of note. For 3.0 I believe they have essentially
depreciated the ability to switch off Unicode so that Unicode should always be
enabled. The wxString class has changed in a number of ways along with this and
I think the intention is to eventually depreciate wxString and use std::string
instead. So I think going down any route that disables Unicode is a bade move.
Regarding building on a separate tree, you might have to specify exactly what
you mean - presumably building so that the libraries and build files end up in
a different location? Again I cannot really speak for the Linux side of things,
but on Windows wxWidgets provide a visual studio .sln file to build with, which
puts all the libraries in "known" locations and it is these locations that are
then searched by CMake on Windows. I'm not really sure what is gained by
building to an external tree to warrant an uphill struggle against a system
that works.
Regarding the runtime errors, I don't see those on Windows. There are no mouse
move issues. However I think there are screen refresh issues when the screen
resizes. When you say the examples hang, are they really hanging or are the
windows just not refreshing? So for example 8, plplot flushes to screen a few
times during the rendering of each plot. Do you see the same thing on Linux? If
you wait a few seconds then move your mouse does the whole plot appear in one?
I think the screen refresh issue is specific to wxplapp, because I don't see
them in my own code which uses its own wxApp which is a lot simpler as it
doesn't have to be started from the command line interface.
Regarding anything GTK related, that cannot exist on a Windows system as
wxWidgets uses native OS APIs to give native look and feel.
Phil
On Monday, 17 March 2014, 8:53, Alan W. Irwin <[email protected]> wrote:
On 2014-03-16 23:04-0700 Alan W. Irwin wrote:
> (1) Strange dbus warning message.
>
> wine@raven> examples/c/x01c -dev wxwidgets
> PLplot library version: 5.10.0
>
> ** (x01c:5554): WARNING **: Error retrieving accessibility bus
> address: org.freedesktop.DBus.Error.ServiceUnknown: The name
> org.a11y.Bus was not provided by any .service files
>
> This WARNING message appears every time I use -dev wxwidgets
> for any of the standard examples.
>
> Note this is a Linux-only issue since dbus is a (system) dependency of
> gtk+ which in turn is a dependency of wxwidgets. But on Windows,
> gtk+ is not a dependency of wxwidgets so dbus is not a factor.
>
> Can you try to confirm this issue on Linux?
I made a bit more progress with this one. A google search for the
message showed you could generate it by removing dbus configuration files
that were similar to the following two files installed by epa_build
wine@raven> ls -l
/home/wine/newstart/build_script/install-linux/share/dbus-1/services/
total 8
-rw-r--r-- 1 wine wine 114 Mar 16 10:15 org.a11y.Bus.service
-rw-r--r-- 1 wine wine 143 Mar 16 10:15 org.a11y.atspi.Registry.service
Furthermore, here are the complete contents of those files.
wine@raven> head -20
/home/wine/newstart/build_script/install-linux/share/dbus-1/services/*
==>
/home/wine/newstart/build_script/install-linux/share/dbus-1/services/org.a11y.Bus.service
<==
[D-BUS Service]
Name=org.a11y.Bus
Exec=/home/wine/newstart/build_script/install-linux/libexec/at-spi-bus-launcher
==>
/home/wine/newstart/build_script/install-linux/share/dbus-1/services/org.a11y.atspi.Registry.service
<==
[D-BUS Service]
Name=org.a11y.atspi.Registry
Exec=/home/wine/newstart/build_script/install-linux/libexec/at-spi2-registryd
--use-gnome-session
The permissions on those "Exec" files are
wine@raven> ls -l /home/wine/newstart/build_script/install-linux/libexec/at*
-rwxr-xr-x 1 wine wine 24058 Mar 16 10:15
/home/wine/newstart/build_script/install-linux/libexec/at-spi-bus-launcher*
-rwxr-xr-x 1 wine wine 110627 Mar 16 10:15
/home/wine/newstart/build_script/install-linux/libexec/at-spi2-registryd*
I can see nothing wrong there. Furthermore, "ldd -r" on those two
files indicates that epa_build linked those corresponding applications
properly, and the run-time loader can find all the associated
libraries.
So I have no clue what could be wrong with this part of the epa_build
installation. A further google search said all this dbus stuff
could be ignored by using
export NO_AT_BRIDGE=1
I tried that, and it got rid of the warning message. But that is just
a rather awkward workaround we should not have to force on our users
so it would be much better to figure out what was wrong with the
epa_build installation of the four files investigated above.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
