Wt 4 preview now on GitHub!

  • Posted by Roel
  • Wednesday, December 28, 2016 @ 16:50

We know that you’ve been eagerly waiting to catch some glimpse of Wt 4 since last year’s blog post. We assure you that Wt 4 is real, it is coming, and we have the wt4 branch on GitHub to prove it!

Wt 4 is Wt’s big update to C++11 and a more modern C++ style along with it.

Notable changes are:

  1. Owning raw pointers have been replaced by smart pointers. Notably, WWidget(WContainerWidget*) and WContainerWidget::addWidget(WWidget*) have been replaced by WContainerWidget::addWidget(std::unique_ptr<WWidget>). Also, some objects that had a single owner before, like WAbstractItemModel and WValidator, are now shared.

  2. Wt 4 relies less on Boost, preferring the standard library where possible. Boost has almost been completely removed from the header files of Wt, which should significantly shorten compilation time.

  3. Boost.Signals2 has been replaced by a new implementation that should offer better performance and easier debugging due to shorter, more understandable stack traces. Also, you don’t need to std::bind away extra arguments when using lambda functions now.

  4. Boost.Date_Time has been replaced by Howard Hinnant’s std::chrono-based date implementation.

  5. Boost.Any has been replaced by Wt::cpp17::any. The implementation can be switched at compile time between std::any, std::experimental::any, or (by default) an included implementation that implements the small object optimization.

  6. The use of Wt header files without .h has been deprecated, because this often confused IDEs and yielded no real benefit.

  7. There’s a new default implementation for WBoxLayout that leverages flexbox instead of relying on JavaScript code to detect resizes.

  8. Everything that was marked as deprecated in Wt 3 has been removed.

Note that Wt 4 is not at release candidate status yet! While functionally quite mature, some things may still change depending on the feedback we receive. Also, the documentation may still be outdated in some places.

We are excited to hear your thoughts about Wt 4!

Tags:
10 comments
  • Posted by anonymous
  • 7 years ago
Thanks. May I know release date of RC version?
  • Posted by anonymous
  • 6 years ago
I would like to know that as well.
  • Posted by anonymous
  • 7 years ago
Why don't you guys accept pull requests FFS?
  • Posted by anonymous
  • 7 years ago
Thank you, Santa!
  • Posted by anonymous
  • 7 years ago
Great news !
  • Posted by anonymous
  • 7 years ago
Great job guys ! I'm looking forward to test that version as soon as possible !
  • Posted by anonymous
  • 7 years ago
Very exciting!
I wonder if the proposed smart pointer usage is wise. It is correct that Wt takes lifetime ownership of added widgets, but how should other code access those widgets? Perhaps the interface should internally store a shared_ptr and supply a weak_ptr to allow lifetime-aware access to the added widget.
I admit, I'm speculating here before actually digging into this preview code.
  • Posted by Roel
  • 7 years ago
In Wt 4, like in Wt 3, a widget is indeed normally owned by its parent container. Using a unique_ptr for that has only made that more clear. You can just use a (non-owning) raw pointer to access the widgets, just like in Wt 3. Because this is such a clear and obvious ownership relation to us, we decided not to use a shared_ptr there.
Because it may be a bit annoying to have to do this:
auto textPtr = std::make_unique<Wt::WText>("Hello!");
Wt::WText *text = textPtr.get();
container->addWidget(std::move(textPtr));
We added a return value to addWidget, so you can do this:
Wt::WText *text = container->addWidget(std::make_unique<Wt::WText>("Hello!"));
Some other methods have been revised to work like that, too, like WTemplate::bindWidget.
If you're really worried about dangling pointers, you can also (optionally) use Wt::Core::observing_ptr. This is a special kind of pointer that is automatically invalidated when the Wt::Core::observable it points to is deleted. Every WObject (and thus every widget) inherits from Wt::Core::observable, and keeps track of all of the observing_ptrs that point to it. We've used it internally in a few places and examples. Note that observing_ptr is not thread safe. We did not deem that necessary because normally only one thread is servicing a WApplication at a time.
If you really don't want your widgets to be owned by their parent container, you can also add them with WContainerWidget::addWidget, and then use WObject::removeChild to remove the ownership. The widget will then still be a child of the parent container in the widget tree, but you'll have the unique_ptr that owns it.
  • Posted by anonymous
  • 7 years ago
COOL!
  • Posted by anonymous
  • 7 years ago
Good job guys!

Contact us for more information
or a personalised quotation