tag:blogger.com,1999:blog-356816902024-03-07T08:54:36.664ZwxBlogAbout wxWidgets current development, its future directions and anything else potentially interesting to developers using wxWidgets.
Ryan Nortonhttp://www.blogger.com/profile/14772407581163137459noreply@blogger.comBlogger116125tag:blogger.com,1999:blog-35681690.post-78341764029797426792018-06-17T21:29:00.000Z2018-06-17T21:29:27.644ZwxBlog Moved to wxWidgets WebsiteI'd like to encourage readers of this blog to update your bookmarks and RSS subscriptions to use the new home of the official wxWidgets developer blog:<div>
<br /></div>
<div>
New wxBlog home: <a href="https://www.wxwidgets.org/blog/">https://www.wxwidgets.org/blog/</a></div>
<div>
New RSS feed: <a href="https://www.wxwidgets.org/blog/atom.xml">https://www.wxwidgets.org/blog/atom.xml</a></div>
<div>
<br /></div>
<div>
For a while now, our official wxWidgets news feed has been managed through our <a href="https://github.com/wxWidgets/website">"website" git repository on GitHub</a>. This allows anyone to contribute news posts (whether you consider yourself a major contributor to wxWidgets, or just want to publish a guest post) through a typical pull request on GitHub, and we want to encourage developers in the community the same freedom to contribute new posts on our developer blog as well. If you would like to contribute a new blog post, please check out the <a href="https://github.com/wxWidgets/website/blob/master/README.md">new website guide</a>.</div>
<div>
<br /></div>
<div>
We have imported in all existing blog posts to the new location, however, we are unable to import existing comments from the wxBlog. We still plan to keep this old blog up for the foreseeable future though. We hope you enjoy the new home of the blog.</div>
Anonymoushttp://www.blogger.com/profile/10357130799990398201noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-70370081260651315522018-03-08T16:38:00.000Z2018-03-08T16:38:27.274Z3.0.4 ReleasedWe have finally, after a long delay, released 3.0.4, please see the <a href="https://groups.google.com/forum/#!topic/wx-announce/DbVPyQyJy4w" target="_blank">announcement</a> or go directly to the <a href="https://github.com/wxWidgets/wxWidgets/releases/tag/v3.0.4" target="_blank">release page</a>.
As with the previous 3.0.x releases, there are no important new
features in this release, but there are quite a few bug fixes as well as
support for the relatively recent compiler, platforms and third-party
libraries versions which were not yet (widely) available at the time of
3.0.3, so upgrading to it is <i>strongly<b> </b></i>recommended for all
3.0 users, especially because it is so simple: the new release is 100%
compatible with 3.0.3 and doesn't require any changes to your
applications code or, if you are using shared libraries, not even
recompiling it.<br />
<br />
As always, thanks to everyone who has contributed to this release and helped with preparing it, by building the binaries,
documentation and testing it!
Anonymoushttp://www.blogger.com/profile/00704215324980423190noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-52342679068932707462018-02-19T22:53:00.002Z2018-02-19T22:53:29.421ZwxWidgets 3.1.1 released<p>
After fixing a few more bugs since the <a href="http://wxwidgets.blogspot.com/2018/02/release-candidate-for-wxwidgets-311.html">release candidate</a>, we've just released the final version of wxWidgets 3.1.1. I won't repeat the <a href="https://groups.google.com/d/msg/wx-announce/qKmf_umCAzU/kCKbbRcdAwAJ">announcement email</a> or the release announcement on the <a href="http://www.wxwidgets.org/news/2018/02/wxwidgets-3.1.1-released/">web site</a>, but would just like to say a few words about the focus of this release and the future plans.
</p>
<p>
First of all, even though there are quite a few new features in 3.1.1, most of the changes in this release are bug fixes and improvements. wxWidgets is still by no way bugs free, but a lot of long-standing problems were fixes, especially in GTK+ 3 and macOS ports, as well as <tt>wxDataViewCtrl</tt> bugs (although, again, not all of them, by a long shot). This is, of course, hardly as exciting as shiny new features, but is arguably at least as useful. It's also in line with our goal to release the new stable 3.2.0 relatively soon.
</p>
<p>
We do hope to have at least one important new feature in the next release: support for per-monitor DPI, with all that this entails, i.e. taking care of as much as possible in the library itself and letting the application handle the rest. My -- probably, as usual, too ambitious -- personal plan is to implement this soon and release 3.1.2 in June, and then 3.2.0 in the autumn. Of course, release planning is mostly made to be broken, at least in our case, but one of the changes in this release is that it's now much simpler to make new releases and the process is much more streamlined, so maybe this plan is not as unrealistic as it might seem.
</p>
<p>
In the meanwhile, I'd still like to repeat one thing from the release announcement: please consider updating to 3.1.1 a.s.a.p. There are almost no incompatible changes in this release since 3.1.0 and only a few compared to 3.0, so it shouldn't take much time (or, sometimes, any time at all) to upgrade and you do get all the bug fixes mentioned above, which are very worth the upgrade, even if you don't plan to use any new features immediately.
</p>VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-69091056831214688982018-02-05T15:12:00.000Z2018-02-05T15:12:15.181ZRelease candidate for wxWidgets 3.1.1 availableThe release candidate for the next wxWidgets release is <a href="https://github.com/wxWidgets/wxWidgets/releases/v3.1.1-rc" target="_blank">available here</a> and any help with testing it would be appreciated. Please consider rebuilding your applications using it, it shouldn't be difficult if you're already using wx 3.0 or later, as this release has few backwards incompatible changes compared to 3.0 and practically none compared to 3.1.0, and if you encounter any problems with either building or running them with the new release, please let us know so that we could still have a chance to fix them before the final 3.1.1 planned in two weeks time.<br />
<br />
Here is a more detailed <a href="https://raw.githubusercontent.com/wxWidgets/wxWidgets/v3.1.1-rc/docs/readme.txt" target="_blank">description of the new release</a> if you'd just like to see what is new in it (but there will probably be another post about it here after 3.1.1 itself).<br />
<br />
Thanks in advance!VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-56402354916394593192017-12-02T20:51:00.001Z2017-12-02T20:51:40.419ZGSoC 2017 summaryAs <a href="http://wxwidgets.blogspot.com/2017/05/our-gsoc-2017-students-and-projects.html">previously mentioned</a>,
wxWidgets has participated in Google Summer of Code again in 2017, after a 2
year hiatus. We had only 2 projects this time, but the good news is that both
of them were successful and, as of 15 minutes ago, been merged into Git master
and will be available in the upcoming 3.1.1 release.
<br />
<br />
The first project, by Jose Lorenzo, enhanced <tt>wxWebView::RunScript()</tt>
to allow returning values from JavaScript code executed by this function back
to C++. This wasn't a particularly big change, but it is an important one as
it makes it possible to write mixed C++/JavaScript applications using
wxWidgets for the standard UI parts and <tt>wxWebView</tt> for richer or more
dynamic parts.
<br />
<br />
The second project, by Prashant Kumar, had a much greater scope and added
support for handling gesture events, such as pinch-zoom or
double-finger-rotate. This required adding new API covering the quite
different native APIs provided by MSW, GTK+ and macOS and implementing it for
all these platforms, congratulations to Prashant for getting it all done! The
only snag is that we don't really have any multi-touch-capable devices to test
this work with, so it's possible that the new code still has some issues --
but, in the best open source tradition, we count on our uses to let us know
about them.
<br />
<br />
Finally, while it doesn't affect wxWidgets users directly, GSoC is also nice because it provides a rare
opportunity for different wxWidgets developers to meet together at the mentor
summit after its end. And this year this allowed me to finally see Mariano
Reingart, who was himself a GSoC student a few years ago and was a mentor this
year, in person for the first time ever:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhVwmcX29VgLJSq_011jlXKrZn8krOtnoJotHE1Sz3G29lLnkjoTbHpR52OppWHAzCw-u7lT65Pzi1Z9689y7914xUWGueQxXFisdQQMFj7aobV6MWa4PTX9-PbUK3-9U7eTL2C/s1600/mariano_vadim.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1490" data-original-width="999" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhVwmcX29VgLJSq_011jlXKrZn8krOtnoJotHE1Sz3G29lLnkjoTbHpR52OppWHAzCw-u7lT65Pzi1Z9689y7914xUWGueQxXFisdQQMFj7aobV6MWa4PTX9-PbUK3-9U7eTL2C/s320/mariano_vadim.jpg" width="214" /></a></div>
<span id="goog_1145775959"></span><br />
<br />
Thanks again to our students and, of course, huge thanks to our mentors:
Cătălin Răceanu, Mariano Reingart and Steven Lamerton, as well as to Bryan
Petty who took care of all the organisational chores. Finally, we are obviously very grateful to Google itself and the GSoC team there, for making all this possible. We hope to be able to
take part in GSoC 2018, which will already start soon, so please help us by
spreading the word about this programme among any students you know and let us know if you have any interesting ideas for the student projects.
VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-64826950311732228772017-11-12T16:53:00.000Z2017-11-12T16:53:13.692ZSurreptitious Submodule Switch<p>
During the last couple of days, we've transitioned all the third party
libraries used by wxWidgets, such as libpng, libjpeg and so on, to use
<a href="https://git-scm.com/book/en/v2/Git-Tools-Submodules">Git submodules</a>
instead of just subdirectories in the main repository. If you don't use Git to
get the latest and greatest<sup>for the appropriate definition of
"great"</sup> wxWidgets, you don't need need to read further as it shouldn't
affect you in any way except for resulting in faster and more frequent updates
to these libraries (but still consider starting to use sources from Git to
help us with testing!).
</p>
<p>
If you do use Git, you will notice that your next update, i.e. <tt>git
pull</tt> or <tt>git fetch && git merge --ff-only origin/master</tt>,
will delete all files in <tt>src/{expat, jpeg, png, tiff, zlib}</tt>
directories. Do not be alarmed by this but do
run <pre><code>git submodule update --init</code></pre> to initialize and get the latest contents of all
the submodules. This will, unfortunately, take quite some time, and if you use
a not too ancient version of Git (2.8 or later), you should be able to speed
the process up significantly by
doing <pre><code>git fetch --recurse-submodules -j2</code></pre> instead, where "2" could be replaced by
any number up to 5 (higher would be useless with only 5 submodules).
</p>
<p>
During subsequent updates, if you notice any change to one of the submodules,
you need to only rerun <tt>git submodule update</tt> (without the
<tt>--init</tt> option) and it will be much faster. Other than that, your use
of wxWidgets Git repository shouldn't have to change in any way, the only
difference is now most of Git commands won't recurse into submodules, at least
by default, so <tt>git grep</tt>, for example, won't find any matches in the
subdirectories mentioned above by default. However mostly the new behaviour is
more useful, and you can use the same <tt>--recurse-submodules</tt> option
with a few Git commands to change it if really needed.
</p>
<p>
Of course, if you do find any problems due to the switch to submodules or
third party libraries upgrades that have taken place together with it (we now
use the latest versions of all of them, notably jumping from libjpeg 6b
released in 1998 to 9b, released in 2016), please let us know on the mailing
lists, as usual.
</p>
VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-24719159597575182592017-05-28T14:44:00.001Z2017-05-28T14:44:34.686ZConfigure is now less forgivingJust a word of warning: it was previously possibly to write <tt>../configure --enable-bloordyblop </tt>and configure would happily run and just ignore the unknown option. This could be seen as being nicely lenient but, in fact, was much more often aggravating as it allowed typos in configure options to slip through, resulting in many "WTF are my library binaries still not optimised even though I did use <tt>--enable-optimize?". </tt>The answer is, of course, <a href="http://wxwidgets.blogspot.com/2016/04/improving-inherently-important.html">as previously mentioned</a>, wxWidgets British roots: you were supposed to use <tt>--enable-optimi<b>s</b>e </tt>instead. But while sticking to the right spelling might be commendable, not giving any errors for the <strike>wrong</strike>alternative one is definitely not. Moreover, this was never intentional and happened only as an unfortunate side effect of how Autoconf <tt>AC_CONFIG_SUBDIRS()</tt>macro worked<br />
<br />
And this has finally changed: since this <a href="https://github.com/wxWidgets/wxWidgets/commit/aa7e10bb0919982bfdc510bd9cdc8b84d621d80b" target="_blank">recent commit</a>, which will be part of upcoming 3.1.1 release, unrecognised configure options will result in an immediate error. And while the new behaviour is better, it does risk breaking a few of the existing build scripts, e.g. if you use obsolete options (such as <tt>--enable-compat24</tt>) or, indeed, if you made a typo in one of them. In this case, please just remove the options that don't exist any more (they were previously ignored anyhow) or fix the typos. And in the unlikely case when you really need to pass an unsupported option to wx configure script (why would you do this?), you can always explicitly use <tt>--disable-option-checking</tt> on the command line to continue doing so -- and you will even get an error if you make a typo in this one!VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-90055776629967186092017-05-05T12:24:00.002Z2017-05-05T12:24:57.902ZOur GSoC 2017 students and projectsAfter an average of one post every 6 months or so on this blog, good news just can't stop coming now, with a second post in just 3 days. This one is to announce that wxWidgets has been allocated two slots in this year Google <a href="https://developers.google.com/open-source/gsoc/" target="_blank">Summer of Code</a> program and Prashant Kumar and Jose Lorenzo will be working on adding support for multi-touch gestures and providing better integration with JavaScript in <span style="font-family: "Courier New",Courier,monospace;">wxWebView </span>this summer.<br />
<br />
Congratulations to Prashant and Jose and thanks to everybody else who applied (but, unfortunately, couldn't be accepted) to work on wxWidgets and also to our mentors: Cătălin Răceanu, Mariano Reingart and Steven Lamerton. And good luck to all involved!VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-22720850623248247792017-05-02T12:39:00.000Z2017-05-02T12:39:08.125Z3.0.3 ReleasedWe have finally, after a long delay, released 3.0.3, please see the <a href="https://groups.google.com/d/msg/wx-announce/-EZAx0KNnBc/2aGmCTfWAwAJ" target="_blank">announcement</a> or go directly to the <a href="https://github.com/wxWidgets/wxWidgets/releases/tag/v3.0.3" target="_blank">release page</a>.
As with the previous 3.0.x releases, there are no important new
features in this release, but there are quite a few bug fixes as well as
support for the relatively recent compiler, platforms and third-party
libraries versions which were not yet (widely) available at the time of
3.0.2, so upgrading to it is <i>strongly<b> </b></i>recommended for all 3.0 users, especially because it is so simple: the new release is 100% compatible with 3.0.2 and doesn't require any changes to your applications code or, if you are using shared libraries, not even recompiling it.<br />
<br />
As always, thanks to everyone who has contributed to this release (at least 66 people according to git commit information, but certainly more in practice) and helped with preparing it, by building the binaries, documentation and testing it!VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-85295524279159831172017-03-27T11:36:00.000Z2017-03-27T11:36:30.040ZLast call for proposals for GSoC 2017<p>
This is just a reminder that wxWidgets is one of the mentoring organizations
in this year <a href="https://developers.google.com/open-source/gsoc/">Google Summer of Code</a>
program and we are looking for proposals from motivated students with
knowledge of C++ and interest for cross-platform development.
</p>
<p>
There is less than a week remaining before the deadline for submitting GSoC
applications, so, if you are a student, or know of a student, interested in
participating, please hurry up!
</p>
VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-29211290216615799432017-02-19T17:30:00.001Z2017-02-19T17:30:57.316ZSafer S...<p>
I want, of course, to talk about "Safer Strings" today.
</p>
<hr>
<p>
<b>TL;DR:</b> Add <tt>/DwxNO_UNSAFE_WXSTRING_CONV=1</tt> to your compiler
options today.
</p>
<hr>
<p>
wxWidgets has had implicit conversion of <tt>wxString</tt> to <tt>const
char*</tt> since the dawn of time (or about 1992, at any rate). This was
always dangerous, as it allowed someone to accidentally write:
<pre><code>void show_and_free(const char* p) { ...; free(p); }
wxString s("...");
show_and_free(s);
</code></pre>
with catastrophic consequences, but such situations were relatively rare and
it was thought that the convenience of having this implicit conversion
overweighted the dangers. This is also why when we added Unicode support
later, we also added implicit conversion to <tt>const wchar_t*</tt> and, when
we added "STL" build mode, in which interoperability with the standard library
is increased further even at the price of backwards compatibility, we added
implicit conversions to <tt>std::string</tt> and <tt>std::wstring</tt> as
well.
</p>
<p>
Unfortunately, with the merge of ANSI and Unicode build modes in wxWidgets 3,
another, much more dangerous, problem has appeared because in the new combined
mode we can now have a string containing Unicode characters not representable
in the current locale encoding. And converting such strings to either
<tt>char*</tt> or <tt>std::string</tt> inevitably results in a loss of data in
this case, e.g.
<pre><code>double convert_temperature_to_celsius(const char* p) {
const char* end;
double t = strtod(p, &end);
return 5.*(t - 32)/9.;
}
wxString s = wxGetTextFromUser("Enter temperature");
convert_temperature_to_celsius(s);
</code></pre>
could, confusingly, result in always returning <tt>-17.77777</tt>,
corresponding to 0°F, if the user decided to terminate the temperature entry
with <tt>"°F"</tt> to explicitly indicate the scale used and the current
encoding couldn't represent the
<a href="https://en.wikipedia.org/wiki/Degree_symbol">degree symbol</a> (which
is the case of e.g. CP1250 under Microsoft Windows). In this case, conversion
of wxString to <tt>char*</tt> would fail and <tt>p</tt> would be just empty.
</p>
<p>
Of course, this wouldn't happen if the code just used
<tt>wxString::ToDouble()</tt> directly, or used <tt>wxChar</tt> and
<tt>wxStrtod()</tt>, or used UTF-8, capable of representing any Unicode
character, as encoding (which is practically always the case under Unix
systems nowadays). So there are a lot of ways to write this code correctly,
but, unfortunately, it was still too simple to write it wrongly accidentally
lose the data entered by the user in this case. Clearly, implicit conversions
potentially losing data are a bad idea, but we couldn't just turn them off in
wxWidgets 3, as it would have broken almost all the existing programs which,
empirically, all used these conversions in many places.
</p>
<p>
For the same reason, we still won't be able to turn this conversion off by
default, even in wxWidgets 3.2. However now we at least
<a href="https://github.com/wxWidgets/wxWidgets/commit/e125c3b6573972ccfc06d228a7d5abd5306f73be">provide a way</a>
to opt-in into safer behaviour. The arguably less interesting part of the
changes is that you can now change the value of the compile-time
<tt>wxUSE_UNSAFE_WXSTRING_CONV</tt> option when building the library. It is
set to 1 by default, for compatibility, but if you build wxWidgets for the use
in your own project, you are strongly advised to set it to 0 to permanently
disable the unsafe, in the sense described above, implicit conversions.
</p>
<p>
Many people, however, don't build their own library, but use the one provided
by their package manager under Unix/macOS or download our MSW binaries. These
official binaries will continue to provide the unsafe conversions for
compatibility, but you can define <tt>wxNO_UNSAFE_WXSTRING_CONV</tt> when
building your own project to disable their use in your code <em>without
rebuilding</em> the library. This symbol can
be just <tt>#define</tt>'d before including any wxWidgets headers, but it is
better to define it globally, in the compiler options in your make- or project
file: just add <tt>/DwxNO_UNSAFE_WXSTRING_CONV=1</tt> to it. And the main
point of this long post is to convince you that you <b>NEED TO DO</b> just
that: please define <tt>wxNO_UNSAFE_WXSTRING_CONV</tt> for your code and fix
the resulting compilation errors to ensure that you don't lose any data
entered by the user.
</p>
<p>
Fixing the compilation errors will, generally speaking, involve doing one of
two things:
<ul>
<li>
Either stop using <tt>char*</tt> (or <tt>std::string</tt> in the
STL build) entirely and use <tt>wxString</tt> directly.
</li>
<li>
Or convert it to <tt>wchar_t*</tt> (or <tt>std::<b>w</b>string</tt>) or
convert wxString to UTF-8 encoding which will never lose data, using methods
such as <tt>utf8_str()</tt>, which is a convenient synonym for
<tt>mb_str(wxConvUTF8)</tt>, or <tt>ToStdString(wxConvUTF8)</tt>.
</li>
</ul>
Of course, if you really need to use the current locale encoding, e.g. because
you call a C standard library function using it, you will still need to
perform the conversion to it, using just plain <tt>mb_str()</tt> and there
will still be a possibility of the conversion to it failing, but at least now
it won't happen implicitly.
</p>
<p>
Thanks for reading all this and, if you jumped to the end, hoping to quickly
find the conclusion instead of reading this wall of text, please see the
conclusion in the very beginning!
</p>
VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-13316488340854087302016-06-13T02:03:00.000Z2016-06-13T02:03:10.050ZHow to Keep a Secret<p>
If your program needs to ask the user for a password, e.g. to connect to a web
site or a database, chances are that it proposes a way to remember this
password and not have to enter it the next time. This is convenient for the
users, but is quite difficult to implement in any more or less secure way and
a lot of programs end up storing the passwords in plain text, or something
almost indistinguishable from it, e.g. base64-encoded string, in <a
href="http://docs.wxwidgets.org/trunk/classwx_config_base.html">wxConfig</a>.
</p>
<p>
But now wxWidgets provides a better way to do it with the new <a
href="http://docs.wxwidgets.org/trunk/classwx_secret_store.html">wxSecretStore</a>
class. It is still as simple to use as <tt>wxConfig</tt> but uses the
OS-provided password storage facility such as Microsoft Windows credentials
vault or OS X keychain, for storing the secrets you confide to it. Here is how
you would normally use it:
<script src="https://gist.github.com/vadz/4660956649e9ae6e9cd18ee07c9e7d35.js"></script>
</p>
<p>
Currently there is not much more that can be done with this class, the only
functionality not illustrated by this example is deleting a previously stored
secret, but in the future we could extend it, notably to provide a way to also
ask the user to enter the password using the OS-provided dialog. Let us know
if you use <tt>wxSecretStore</tt> and if you see possible improvements, please
don't keep them secret!
</p>
VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-74069668800852572522016-04-01T06:00:00.000Z2016-04-01T06:00:22.758ZImproving Inherently Important Internationalisation Issues<p>
One of the lesser-known advantages of wxWidgets compared to many other
libraries is that, using its API, you can
<a href="http://docs.wxwidgets.org/3.1.0/classwx_window.html#a4a1819eeee3f2143cdde4f329ffde787">centre</a>
a window on the screen and set its
<a href="http://docs.wxwidgets.org/3.1.0/classwx_colour.html">colour</a> to
<a href="http://docs.wxwidgets.org/3.1.0/brush_8h.html#a9fd61bfd0445d71e17e56d836098096f">grey</a>
without having to Americanise your programme. But, as natural as this
behaviour is, and in spite of agreeing to wxWidgets licence (the very
spelling of which should have been a sufficient hint), some users still
expressed their surprise in their dialogue with us and refused our advice to
accept using this flavour of the API. And so, to accommodate them, wxWidgets
has traditionally provided alternatives such as <tt>Center()</tt> method,
<tt>wxColor</tt> class and <tt>wxGRAY</tt> constant.
</p>
<p>
Admittedly, in practice this has been sufficient to avoid any problems for a
long time while still remaining true to wxWidgets historically British roots.
However, in addition to being British, wxWidgets was always mostly a European
effort and, besides, knowing that it was actually born in Edinburgh, it might
well end being
<a href="https://en.wikipedia.org/wiki/United_Kingdom_withdrawal_from_the_European_Union">exclusively</a>
European and <a href="https://en.wikipedia.org/wiki/Scottish_independence_referendum,_2014">not British</a>
at all in the near future (but don't worry, even if the worst happens, we plan
to continue supporting British spelling for at least two more release cycles,
in accordance with the general backwards compatibility policy). Considering
this, it seems especially strange to have alternative American versions of the
spelling, but no attention being paid to the other European languages.
</p>
<p>
And now, after
<a href="http://wxwidgets.blogspot.com/2016/02/an-unexpectedly-expected-release-310-is.html">releasing 3.1.0</a>,
it's finally time to do something about it as, clearly, there are few
unresolved issues of comparable importance left. To begin with, I obviously
had to add <tt>wxCouleur</tt> class which should undoubtedly help with
wxWidgets adoption in francophone countries. But adding just the French variant
would certainly be undiplomatic, so another pull request adds, in the grand
European tradition of Franco-German alliance, <tt>wxFarbe</tt>, and both of
them will be merged together to avoid any questions of precedence. Further,
France and Germany notwithstanding, I certainly don't plan to discriminate
against other countries but, in the usual spirit of Open Source, additions of
<tt>wxColore</tt>, <tt>wxFarve</tt>, <tt>wxKleur</tt> etc will have to wait
until the appropriate patches are submitted (luckily for them, Spanish users
can, in the meanwhile, already reuse the American variant, just as they
already do with many other words, e.g. burrito, for the classic American
food).
</p>
<p>
Of course, nothing is ever as simple as planned and, while working on this, I
quickly realized that Greek might present some practical difficulties as UTF-8
support is still, even in 2016, not perfect on some of the legacy platforms
supported by wxWidgets, but it would be difficult to use <tt>wxΧρώμα</tt>
without it. A compromise solution that we're currently discussing would
be to introduce a <tt>wxChroma</tt> class right now and deprecate it by the
time 3.2 is released as Unicode support should really be widely available
everywhere by then (3.2 release is currently planned for the early 2030-ies).
</p>
<p>
I do hope you will enjoy these changes, but, let's be honest, this is just the
beginning and we clearly still have a lot of work to do in this area. Fully
supporting colour internationalization is important, but it's just the first
step and we plan to go much further. Just imagine to be able to open a
<tt>wxFenêtre</tt> and choose a <tt>wxStylo</tt> for drawing on it and then,
perhaps if you live in Switzerland, create a <tt>wxKnopf</tt> as its child.
The possibilities are endless! Unfortunately, the same can't be said about our
resources, so we count on your help to make wxWidgets the best
internationalized library of all time -- and we're looking forward to your
<a href="https://en.wikipedia.org/wiki/April_Fools'_Day">contributions</a>!
</p>
VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-1240652531785262232016-02-29T19:42:00.002Z2016-02-29T19:42:55.256ZAn unexpectedly expected release: 3.1.0 is available<p>
Surprisingly, at least to me, we managed to make <a href="https://github.com/wxWidgets/wxWidgets/releases/tag/v3.1.0">3.1.0 release</a> exactly <a href="http://wxwidgets.blogspot.com/2016/02/310-is-coming.html">as planned</a>, i.e. today, without any delays. The price for this is that there are a couple of known problems in this release (see the errata on the release page), but we decided that it was not worth delaying the release for them.
</p>
<p>
This is not the most exciting release in wxWidgets project history, but it's still very much worth upgrading to as there has been a huge number of bug fixes in it, especially in wxGTK3 and wxOSX ports. Of course, as usual, there are a few new features as well, see the <a href="http://www.wxwidgets.org/news/2016/02/wxwidgets-3.1.0-released/">web site</a> for a brief list and the <a href="https://raw.githubusercontent.com/wxWidgets/wxWidgets/v3.1.0/docs/changes.txt">change log</a> for a fuller one and I'll try to find some time to write in more details about one of them, <a href="http://docs.wxwidgets.org/3.1.0/classwx_native_window.html">wxNativeWindow</a> here in the near future.
</p>
<p>
The next goal is to release 3.0.3 to make at least some of the bug fixes, if not the new features, from 3.1.0 available to people using the system packages under Linux or just too cautious to start using the "development" releases (even although in my opinion this is not really justified as, on average, 3.1 branch has fewer, not more, bugs than 3.0.x one). As for 3.1.1, this will depend on how quickly the changes accumulate in the master, we'll see how it goes. In the meanwhile, we hope that you'll enjoy the new release!
</p>VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-76694974466759419782016-02-04T17:41:00.000Z2016-02-04T17:41:10.474ZWhat g++ binaries for 3.1.0 release?<p>We plan to provide g++ binaries for the upcoming release, but we're not sure what are the versions and the build options that people would be interested in, so here is a quick poll to gather some information about this:</p>
<script type="text/javascript" src="http://www.easypolls.net/ext/scripts/emPoll.js?p=56b3897be4b0b80aa9d153f2"></script><a class="OPP-powered-by" href="https://www.murvey.com" style="text-decoration:none;"><div style="font: 9px arial; color: gray;">polls</div></a>
<p>Please select 1-3 options corresponding to the binaries that would be useful to you to allow us to make the best choice. Thanks in advance!</p>VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-36787687733335427722016-02-01T02:31:00.000Z2016-02-01T02:31:14.768Z3.1.0 Is Coming<p>
Although we've been talking about it since quite some time, this time we're <em>really</em> going to make a new release soon. To be even more precise, I firmly expect to make it this month. Of course, I did wait until January was over to announce it. On the other hand, I did not wait for the February to be over neither even though it's the shortest month of the year. On still another hand, we did wait an extra year for this release, presumably just to have one extra day to make it in February of this year, as opposed to the last one... In any case, barring something really catastrophic happening, we should have a pre-release on February 15 and the release some time after that.
</p>
<p>
Of course, deciding to make the release is not quite enough, there are other things to do too, such as applying at least the most urgent and long standing patches and fixing selected bugs. So this week-end I spent some time doing this and, as the result, instead of 49 3.1.0-critical bugs we now have only <a href="http://trac.wxwidgets.org/query?status=accepted&status=confirmed&status=new&status=reopened&milestone=3.1.0&group=component&col=id&col=summary&col=milestone&col=status&col=type&col=priority&col=component&col=patch&order=priority">20 of them</a> which is not as good as I hoped, but better than I expected. Of course, some of these bugs were just postponed, while others turned out to be not bugs at all after all or to have been already fixed. Still, quite a few real bugs and, notably, a few regressions which really couldn't remain before the release, were fixed as well, so there is that. I hope to deal with the remaining bugs during the next week and maybe even apply some non 3.1.0-targetted patches too, but in the worst case we could just postpone all the remaining 3.1.0 tickets as there is nothing absolutely critical there (and only a couple I'd characterise as being moderately critical).
</p>
<p>
So things look cautiously good for 3.1.0 and if we make it according to the plan, thus proving that our new release scripts, updated after the switch to git, work, hopefully 3.0.3 will follow soon afterwards.
</p>VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-38478903115390066282016-01-21T22:10:00.001Z2016-01-21T22:10:31.896ZDropping Carbon support under OS X<p>We would like to remove the old Mac OS X port using Carbon in the upcoming 3.1.0 release because we think nobody should be using it any longer (and we definitely know that nobody building 64 bit applications does because Carbon just doesn't exist in 64 bits) and it would make things simpler for us. But "should" and "is" are different things and if there are more than a handful of people who are still using Carbon and can't migrate to wxOSX/Cocoa port (I'd like to know why!), but, at the same time, still plan to update to 3.2 in the observable future, we could reconsider this. So if you'd like Carbon to continue to be supported, please let us know, in the comments here or on the mailing list. Thanks!
</p>VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-19704924723859510992015-06-14T18:45:00.000Z2015-06-14T23:27:03.150ZBuild fixes for different gcc distributions under Windows<p>
I've spent most of the day today fixing various compilation issues for the
three most often used distributions of gcc under Windows:
<a href="http://tdm-gcc.tdragon.net/">TDM-GCC</a>,
<a href="http://mingw-w64.org/doku.php">mingw-w64</a> and the "classic"
<a href="http://www.mingw.org/">MinGW</a> trying to ensure that the upcoming
3.0.3 release (as well as the current master) builds out of the box with all
of them using all the common build scenarios. TDM-GCC and mingw-w64 required
just one minor fix for g++ 4.9.2 which started providing clang-like
<tt>__has_include()</tt> except with different (and IMHO completely useless)
semantics, so we just have to ensure that we don't use it with gcc even if it
is available which was easy to do and actually had been already done on
master.
</p>
<p>
However things were much more interesting with MinGW. The main problem with it
was that it couldn't be used to build wxWidgets with <tt>-std=c++11</tt>
option (nor <tt>-std=c++98</tt> one, but almost nobody ever used this one
anyhow) nor, even worse, even use this option when compiling applications
using wxWidgets as it broke compilation of wxWidgets headers. There always was
a simple workaround of using <tt>-std=gnu++11</tt> option instead, but it only
was simple once you knew about it, which wasn't the case for most of
first-time wxWidgets users who ran into it. So I finally decided to make
<tt>-std=c++11</tt> work as well and now it does, even though this wasn't
simple nor pretty.
</p>
<p>
The summary is that now building with all 3 compilers with and without
<tt>-std=c++11</tt> works. And, as a side effect of this, I also fixed some
(mostly harmless) warnings so that building with MinGW and mingw-w64 now
doesn't give any -- at least in the configurations I tested. TDM-GCC is
pickier (which is probably a good thing) and still gives quite a few warnings,
so using <tt>-Wno-unused-value</tt> in <tt>CXXFLAGS</tt> with it is
recommended: with this option only a couple of warnings in 3rd party code
remain.
</p>
<p>
Of course, there are too many combinations for me to have tested all of them:
2 branches (3.0 and master), C++11 and C++98, static and shared, Unicode and
ANSI, STL and not-STL already give 96 builds to test and there are other
options too. So, before I spend too much time congratulating myself, it would
be great if people could actually test the build configurations they use and
are interested in and report if there are any (and especially any new)
problems with them as I'm sure I must have also broken something with so many
changes. I'm just not sure what, yet -- please let me know!
</p>
VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-86319709379354560312015-04-07T19:41:00.000Z2015-04-08T14:54:57.200ZValidating XRC<h2>
Overview</h2>
If you write your
<a href="http://docs.wxwidgets.org/trunk/overview_xrcformat.html"></a>XRC files<br />
by hand (which is probably relatively rare as most people prefer to edit them
visually, but it does happen), and if you are human (which is probably not so
rare), you are bound to make mistakes in them. Some of these mistakes result
in invalid XML which give errors when loading the XRC file, some of them are
not a big deal and are just ignored by the XRC parser, but some others can
result in the layout mysteriously not working as expected, which can be
annoying. Validating XRC files, i.e. verifying that they conform to the scheme
describing all the valid XRC elements, allows to avoid all these problems at
once, so it is strongly recommended to do it -- and this post will explain
how, in details.
<br />
<h2>
Setup</h2>
To validate them you need two things: a schema and a tool using it. The schema
exists in
<a href="https://github.com/wxWidgets/wxWidgets/tree/master/misc/schema">our repository</a>
since October 2013 and is also available at the public URL
<tt><a href="http://www.wxwidgets.org/wxxrc">http://www.wxwidgets.org/wxxrc</a></tt>.
As for the <a href="http://relaxng.org/#validators">tools</a>, anything
supporting compact RELAX NG schema syntax can work, but in practice this seems
to limit the choices either to the online validator at
<a href="http://validator.nu/">validator.nu</a> (<i>Edit</i>: this validator
can't be used for validating XRC currently as RELAX NG support <a href="https://github.com/validator/validator/issues/89">seems to be broken</a>) or the original command-line
validator, written by James Clark, one of the persons behind RELAX NG, called
<a href="http://www.thaiopensource.com/relaxng/jing.html">Jing</a>, and the
offline version is, unsurprisingly, much more useful as it can be integrated
into the build process or used as part of pre-commit hook checks easily, so
this is the one we are going to look at.
<br />
The latest Jing release is available from
<a href="http://jing-trang.googlecode.com/files/jing-20091111.zip">Google Code</a>,
but as the entire site will be
<a href="http://google-opensource.blogspot.fr/2015/03/farewell-to-google-code.html">closing soon</a>,
it might not work any longer by the time you are reading this, so
<a href="http://www.tt-solutions.com/downloads/jing-20150407.jar">here</a> is
the smaller and more up-to-date version. It is completely standalone and
requires just a working Java installation, you can put the JAR file anywhere
you want and simply run <br />
<pre><code>$ java -jar /full/path/to/jing/jar</code></pre>
(in spite of the dollar sign indicating the Unix prompt, this works under
Windows, too). The basic Jing command line syntax is just the schema file
followed by any number of files to validate, however XRC schema uses the
compact syntax which has to be explicitly selected by its <tt>-c</tt> option,
so in the simplest case the full command line would look like
<pre><code>$ java -jar jing.jar -c $WXWIN/misc/schema/xrc_schema.rnc myfile.xrc</code></pre>
where <tt>WXWIN</tt> environment variable is supposed to contain the full path
of your wxWidgets installation.
<br />
As an aside, it is also possible to avoid hard coding the path to the XRC
schema, which may be important to make the validation step work on different
machines. The natural way to do it would be to just use the canonical URI
instead of the path to the schema, i.e. <tt>http://www.wxwidgets.org/wxxrc</tt>
but currently this doesn't work, seemingly because of a bug in Jing handling
HTTP-to-HTTPS redirections. The following command does work:
<br />
<pre><code>$ java -jar jing.jar -c https://www.wxwidgets.org/wxxrc myfile.xrc</code></pre>
but still has two problems: first, the URI is, formally speaking, wrong as it
should be using "http" schema. Second, and probably more importantly in
practice, it can be slow as the file needs to be downloaded from network every
time. To fix this problem, an
<a href="https://en.wikipedia.org/wiki/XML_Catalog">XML catalog</a> mapping
the canonical URI to a local file can be used. I won't pretend to know much
about XML catalogs (because I don't), but here is a minimal one that can be
used to set up the correct redirection:
<script src="https://gist.github.com/vadz/8581aa5745fd07b6b810.js"></script>
<br />
If you save the above file as <tt>catalog.xml</tt> and adjust the value of the
<tt>uri</tt> attribute to contain the correct path to <tt>xrc_schema.rnc</tt>
on your machine (notice that triple slashes <i>are</i> needed), you should
be able to use
<br />
<pre><code>$ java -jar jing.jar -C catalog.xml -c http://www.wxwidgets.org/wxxrc myfile.xrc</code></pre>
<br />
<h2>
Using (or not) Custom XRC Elements</h2>
After the setup describe above you can use the standard schema
<tt>xrc_schema.rnc</tt> to validate the contents of all the standard XRC
elements, such as <tt><sizeritem></tt> or <tt><object
class="wxButton"></tt>. However any custom elements are simply ignored by
default because the standard schema has no knowledge of them. Of course, you
might not have any custom XRC elements at all. In this case, you should use
<tt>xrc_schema_builtin_only.rnc</tt>, located in the same
<tt>$WXWIN/misc/schema</tt> directory of your wxWidgets installation, to
forbid any of them from appearing. There is no canonical URI for it, so you
should simply pass full path to it on Jing command line.
<br />
The more interesting case is when you do define some custom XRC handlers. In
this case using <tt>xrc_schema_builtin_only.rnc</tt> would result in errors
about invalid value of attribute "class" for all your custom elements, so you
need to define a custom schema describing just them. An example of doing it is
shown in
<a href="https://github.com/wxWidgets/wxWidgets/blob/WX_3_0_2/misc/schema/README#L54">misc/schema/README</a>,
but here is an even simpler custom schema:
<script src="https://gist.github.com/vadz/add18ade601e85192d84.js"></script>
<br />
This schema allows appearance of a custom <tt>Frobnicator</tt> window-like
(because of <tt>stdWindowProperties</tt> inclusion) element which can have one
specific (but optional, because of the trailing <tt>*</tt>) <tt>num_times</tt>
attribute, i.e. would validate the following XRC fragment:
<script src="https://gist.github.com/vadz/1d587b5b8a417d806a73.js"></script>
if you issue
<br />
<pre><code>$ java -jar jing.jar -C catalog.xml -c frob.rnc frob.xrc</code></pre>
command. Of course, the same fragment would also be accepted by the standard
schema, the real benefit of using a custom one is that typos in either
"Frobnicator" or "num_times" would be detected only by the latter.
<br />
<h2>
TL;DR Summary</h2>
Your easy guide to XRC validation:
<br />
<ol>
<li>Download <a href="http://www.tt-solutions.com/downloads/jing-20150407.jar">jing.jar</a></li>
<li>For one-time validation of only standard XRC elements just run
<pre><code>$ java -jar jing.jar -c https://www.wxwidgets.org/wxxrc myfile.xrc</code></pre>
</li>
<li>For repeated use, download
<a href="https://gist.githubusercontent.com/vadz/8581aa5745fd07b6b810/raw/wxxrc_catalog.xml">XML catalog</a>,
edit the file path in it and run
<pre><code>$ java -jar jing.jar -C catalog.xml -c http://www.wxwidgets.org/wxxrc myfile.xrc</code></pre>
</li>
<li>If you use custom XRC elements, consider defining a schema for them too,
it is simple to do.</li>
</ol>
VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-78637655921794764932015-03-12T13:00:00.001Z2015-03-12T13:00:26.451ZAttributing the contributions<p>
One of the lesser, but still appreciable, benefits of <a href="http://www.wxwidgets.org/news/2015/03/official-switch-to-git">switching to Git</a> is that now we can properly record the author of the commit (e.g. the author of a patch), in addition to the (less important) person who committed it (e.g. me). While we tried to do this manually in the <a href="https://github.com/wxWidgets/wxWidgets/blob/master/docs/changes.txt">change log</a> before, this couldn't be done for all the changes as the change log only mentions the most important ones and, sometimes, could be forgotten even for those changes for which it should have been done.
</p>
<p>
With Git, things are much more straightforward and you just need to provide your identity with your patch. The simplest way to do it is to use <a href="http://git-scm.com/docs/git-format-patch"><tt>git format-patch</tt></a> command -- after ensuring that your name and email are correctly configured locally, of course. But you could also just mention them in your Trac ticket or wx-dev email and we'll use them when committing your changes (note for committers: you can always set <tt>GIT_AUTHOR_{NAME,EMAIL}</tt> for a particular commit to set the authorship information by hand).
</p>
<p>
Looking forward to your patches -- which will be now properly attributed to you instead of boosting my own commit stats!
</p>VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-52860737720971550932014-12-31T02:22:00.000Z2014-12-31T02:22:27.893ZA year in wx2014 hasn't been the most exciting year for wxWidgets -- among the recent years this honour certainly belongs to 2013, which finally saw the release of the long, long awaited 3.0 release. However quite a few things still happened during it.<br />
<br />
First of all, thanks to Bryan Petty, we now have a new shiny web site which not only looks much better, but is also simpler to update and to <a href="https://github.com/wxWidgets/website/pulls">contribute to</a>. And it was duly updated more often, in particular to announce two new releases (3.0.1 and 3.0.2) last year, which is two more than we typically make per year.<br />
<br />
Second, after a two year hiatus, wxWidgets was part of Google Summer of Code again this year and we had 6 students working on several interesting projects, admittedly with various degrees of success. But work done by Alexandru Pana on Direct2D support, by Chaobin Zhang on new Windows Vista/7 taskbar features, Sun Boxiang on wxUniv/X11 and Mariano Reingart on wxQt port was already merged into the trunk and we hope to merge Haojian Wu's work on Chromium backend for wxWebView before the next release.<br />
<br />
Third, in 2014 we welcomed a new member to wxTeam: Artur Wieczorek has started by submitting many important improvements to wxMSW and then also volunteered to become the maintainer of <a href="http://docs.wxwidgets.org/trunk/overview_propgrid.html">wxPropertyGrid</a> control and has since improved it as well. Thank you Artur!<br />
<br />
Other than that, life continued as normal in 2014 with 1678 commits in master and 375 bugs fixed (compared to 1471 and 332 in the previous year).<br />
<br />
What are we looking towards in 2015? Definitely a 3.1.0 release and almost certainly a 3.0.3 one. With luck, 3.1.0 will include a new and reworked AUI version. On infrastructure level, after upgrading the web site, the next long-awaited change is officially migrating to git from svn. Finally, we hope for as many contributions from the community in the next year as in the last one, thanks to all (too numerous to list here, sorry!) who submitted patches or sent us bug reports and please continue to do it!<br />
<br />
Thank you and happy New Year!<br />
<br />
<br />VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-41183872285493705362014-10-25T15:03:00.000Z2014-10-29T22:00:29.308ZBeing busy without being ugly<a href="http://docs.wxwidgets.org/trunk/classwx_busy_info.html">wxBusyInfo</a> is one of the classes that it is actually best not to use at all, because it blocks the program UI without allowing to dismiss it, so it is hardly user-friendly and usually performing the long-running operation in a separate thread and providing some way to display its progress and cancelling it in the main GUI thread is strongly advised.<br />
<br />
However sometimes doing it is too difficult or maybe even impossible if you are using third-party libraries and in this case <span style="font-family: "Courier New", Courier, monospace;">wxBusyInfo </span><span style="font-family: inherit;">provides a very simple </span>way to at least indicate that the program is busy, using it is as easy as creating an object on the stack:<br />
<br />
<pre><code>
wxBusyInfo wait("Working, please wait...", parent);
</code></pre>
<br />
Unfortunately, traditionally, it was not just very simple, but very ugly as well, as can be seen on this screenshot: <br />
<div style="text-align: right;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDyLtF9bqGrMDx8e3Jlve9lXE5c7pgIXks-ul5WCcmff49KL0elsWTEnKC_Gh3JTOLWCMOhrbqBwO-HCJeeFBa-ML_SBlUTv1ms8cA3zhqGH1k4aAnWb2oG2YKDVfe__VTgMjr/s1600/busy-old.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDyLtF9bqGrMDx8e3Jlve9lXE5c7pgIXks-ul5WCcmff49KL0elsWTEnKC_Gh3JTOLWCMOhrbqBwO-HCJeeFBa-ML_SBlUTv1ms8cA3zhqGH1k4aAnWb2oG2YKDVfe__VTgMjr/s1600/busy-old.png" height="177" width="320" /></a></div>
After the recent changes, you can show to the user something more presentable (especially if you use a decent icon): <br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgoykVuw1su7BzWjE2LqCI612s807TKcT9wTC1xE1YmIGqtw7oP_PU3pYNXuP-qRqmWpipPaGplLlyCVdV7q8xLYOyOfnbVGfFKgphJbaWjs3zlUrPmFVhqsmrC9L6XA9iXFiLj/s1600/busy-printing2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgoykVuw1su7BzWjE2LqCI612s807TKcT9wTC1xE1YmIGqtw7oP_PU3pYNXuP-qRqmWpipPaGplLlyCVdV7q8xLYOyOfnbVGfFKgphJbaWjs3zlUrPmFVhqsmrC9L6XA9iXFiLj/s1600/busy-printing2.png" height="157" width="320" /></a></div>
and with only slightly more effort:
<br />
<pre><code>
wxBusyInfo info
(
wxBusyInfoFlags()
.Parent(parent)
.Icon(wxArtProvider::GetIcon(wxART_PRINT))
.Title("<b>Printing your document</b>")
.Text("Please wait...")
.Foreground(*wxWHITE)
.Background(*wxBLACK)
.Transparency(4*wxALPHA_OPAQUE/5)
);
</code></pre>
<br />
As you can see, now it's possible to specify quite a few more attributes than just the unadorned message:<br />
<ul>
<li>There can be an optional icon in the top part of the window.</li>
<li>Message is now split in the "text" and "title" parts, with the latter shown in bigger font by default.</li>
<li>Both text and title can contain <a href="http://docs.wxwidgets.org/trunk/classwx_control.html#afeb308dc3b54d8d735b33cb250395503">markup</a>.</li>
<li>Background and foreground colours can be specified.</li>
<li>Finally, the window can be made partly transparent.</li>
</ul>
To avoid passing all these parameters directly to <span style="font-family: "Courier New", Courier, monospace;">wxBusyInfo</span> <span style="font-family: inherit;">constructor <span style="font-family: inherit;">as o</span>ne unintelligible jumble<span style="font-family: inherit;">, a new helper class </span></span><span style="font-family: "Courier New", Courier, monospace;">wxBusyInfoFlags </span><span style="font-family: inherit;"><span style="font-family: inherit;">was added to allow specifying them all <span style="font-family: inherit;">by names<span style="font-family: inherit;"> and to make it simple to add more attributes later than needed.</span></span></span></span><br />
<span style="font-family: inherit;"><span style="font-family: inherit;"><br /></span></span>
<span style="font-family: inherit;"><span style="font-family: inherit;">So while the initial advice <span style="font-family: inherit;">to avoid the use of<span style="font-family: inherit;"> </span></span></span></span><span style="font-family: "Courier New", Courier, monospace;">wxBusyInfo </span><span style="font-family: inherit;"><span style="font-family: inherit;"><span style="font-family: inherit;">in the first place remains valid, <span style="font-family: inherit;">you can at least make it less ugly now if you do have to <span style="font-family: inherit;">use it.</span></span></span></span></span>VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-76007960696646925772014-10-06T17:25:00.000Z2014-10-06T17:25:55.444ZOutdated configure in original 3.0.2<p>
Due to my mistake, 3.0.2 source archives contained an out of date version of <tt>configure</tt> from 3.0.1. The new archives have with the fixed version have been uploaded now, please redownload if you are using Unix (or configure with MSYS or Cygwin under Windows) and had already downloaded one of <tt>wxWidgets-3.0.2.{7z,tar.bz2,zip}</tt> files.
</p>
<p>
Sorry for the inconvenience!
</p>VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-86327943776542087302014-10-06T12:24:00.000Z2014-10-06T12:24:18.625Z3.0.2 Released<p>
We have just released wxWidgets 3.0.2, please see the <a href="https://groups.google.com/forum/#!topic/wx-announce/tRxkeGNkkdA">announcement</a> for the download links. There is nothing particularly exciting about this maintenance release, but it does fix quite a few bugs and so upgrading to it is recommended to all 3.0 users -- there are no drawbacks to it, as the new release remains both API- and ABI-compatible with 3.0.0.
</p>
<p>
To give slightly more details, the fixes were mostly in wxMSW, quoting from the change log:
<ul>
<li> Fix background of <tt>wxRadioBox</tt> buttons and <tt>wxSlider</tt>.</li>
<li> Fix appearance of <tt>wxToggleButtons</tt> with non default colours.</li>
<li> Fix drawing on <tt>wxDC</tt> when using right-to-left layout.</li>
<li> Fix <tt>wxGrid</tt> appearance and behaviour in RTL.</li>
<li> Fix creating <tt>wxBitmap</tt> from monochrome <tt>wxIcon</tt> or <tt>wxCursor</tt>.</li>
<li> Fix handling of bitmaps with alpha in <tt>wxImageList</tt>.</li>
<li> Add paragraph spacing attributes support to <tt>wxTextCtrl</tt>.</li>
<li> Show new style directory selector even for non existent paths.</li>
<li> Fix order of radial gradient stops.</li>
<li> Fix font created using <tt>wxFont(wxFontInfo())</tt> ctor.</li>
<li> Fix <tt>wxFileName::GetShortcutTarget()</tt> in console applications.</li>
<li> Fix <tt>wxFileName::MakeRelativeTo()</tt> for shortcut files.</li>
<li> Fix height of initially empty <tt>wxBitmapComboBox</tt>.</li>
<li> Fix setting label of submenu items.</li>
<li> Fix using Esc as accelerator in the menus.</li>
<li> Fix wrong initial status bar height in some cases.</li>
</ul>
</p>
And there are also build fixes for Cygwin 1.7, for MinGW 4.8 (we now work around the bugs in its headers) as well as improvements for MSVS projects: the ones for 2005 and 2008 now also include x64 configurations, while the ones for the later versions now reliably build when using parallel build.
<p>
In wxGTK, <tt>wxSearchCtrl</tt> was fixed and doesn't truncate the text and icons inside it any more. There were a few changes in wxOSX as well, including a fix for the use of <tt>wxPreferencesEditor</tt>.
</p>
<p>
Finally, in spite of the focus on the bug fixes, there are also a couple of new features in this release:
<ul>
<li> <tt>wxDateTime::Format()</tt> now support POSIX <tt>%V</tt>,
<tt>%G</tt> and <tt>%g</tt> format specifiers for week-number formatting.</li>
<li> XRC handler for <tt>wxSimplebook</tt> was added.</li>
<li> It is also now possible to specify the window variant (normal, small,
large, ...) in XRC.</li>
<li> <tt>wxGenericListCtrl::EndEditLabel()</tt> was implemented, for
consistency with the native wxMSW version.</li>
</ul>
</p>
<p>
As always, please let us know about any problems with this release and we hope you will find it useful!
</p>
VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0tag:blogger.com,1999:blog-35681690.post-50646672329208948442014-09-23T17:56:00.000Z2014-09-23T17:56:17.283ZGSoC 2014 summary: wxX11/Univ improvement project<p>
The work of Sun Boxiang on improving wxUniv and notably wxX11 port has been merged into the trunk. This was mostly a bug fixing project and as the result of, many more unit tests now pass in wxX11 test suite than before, we're down to "only" 16 failures in 539 tests compared to 80 out of 308 before the project beginning. One new feature also implemented during this project is the new implementation of <tt>wxClipboard</tt> for X11. See <a href="https://groups.google.com/forum/#!msg/wx-dev/-z-LfabvZko/_f88vzwTuLsJ">Sun's summary</a> of his work for more details.
</p>
<p>
Unfortunately there still remains quite a bit of work to be done before wxUniv can really be considered to be ready for general use, but at least know we know better what is missing or broken. In wxX11, there is some major work to be done on event loop code refactoring, to allow reusing the same logic as for the other Unix ports. We should probably also switch to using Cairo instead of the old style X11 drawing functions. And at wxUniv level, we really need a better theme with nicer appearance.
</p>
<p>
Unfortunately we, the current wxWidgets developers, just don't have any possibility to work on it, so there is no time frame for any of the above, but any contributions from people interested in using wxUniv (e.g. for writing applications with a particular appearance using a custom theme) would be very welcome!
</p>VZhttp://www.blogger.com/profile/08757498024167099515noreply@blogger.com0