Wt 3 end of life

  • Posted by Roel
  • Monday, December 16, 2019 @ 14:00

Over two years ago, we released Wt 4.0.0, embracing the C++11 standard.

We’ve already been limiting Wt 3 to mostly bug fixes for a while now, but some new features kept being included mostly because we wanted them in JWt too.

Now that we’ve just announced JWt 4, which is based on Wt 4, the time has come to announce the discontinuation of Wt 3.

We’ll be maintaining Wt 3 for another year, so expect no more Wt 3.x releases starting from 2021.

Tags:
8 comments
  • Posted by anonymous
  • 5 years ago
Adopt the Wt 3
  • Posted by anonymous
  • 5 years ago
Maybe its about time to investigate in clang-based code to code transformation ;-)
has anybody done this to migrate wt3 -> wt4 projects already?
  • Posted by anonymous
  • 4 years ago
Ohhhh.... I had not considered a clang rewriter... the problem I think would be dealing with all the cheesy unique pointers....
  • Posted by Roel
  • 4 years ago
I've thought about that too, but it would take some time, and I'm not very familiar with clang. It would probably only be able to refactor certain common patterns:
If the old passing the container in the constructor idiom is used (I think most of our examples did that) I can see how that can be rewritten to an addNew call.
  • Posted by anonymous
  • 4 years ago
from the wt4 docs tree example we find things like... 
  auto expandIcon =
      cpp14::make_unique<IconPair>(imagePlus_[Last], imageMin_[Last]);
  expandIcon_ = expandIcon.get();
  expandIcon_->hide();
which is infuriating to work with
  • Posted by Roel
  • 4 years ago
I agree that some of the examples are a bit awkward. Many of them were ported over before we had a good feel for Wt 4 ourselves. I should go through them and see if they can be done a bit nicer. In many cases (this case too, I think), it's just a bit of shuffling around.
  • Posted by anonymous
  • 4 years ago
I mean really.... If I as a developer agree that WT takes ownership of a widget when I connect it to a widget hierarchy... THEN why the hell do I have to create a std::unique_ptr at all? Why litter my code with std::move when it is *agreed* the UI is going to manage that widget's lifetime.... and don't say "because you might try to access it after it is free'd" because half of the existing examples hold a raw pointer to widgets in-addition to making the worthless std::unique_ptrs.... Sorry - Didn't realize how angry Wt4 makes me
  • Posted by koen
  • 4 years ago
The reason to use std::unique_ptr<> is to make the transfer of ownership explicit in the code. With Wt3 one had to look up the ownership handling in the documentation, while in Wt4 it is evident from the code, using a standard C++ concept. The "agreement" is now represented in code. The goal of unique_ptr is not to protect against illegal dereferences (this apparently was something that the standards committee didn't think to be that important compared to expressing ownership semantics clearly in the code).
We have debated the change at length and your point of view was also part of the discussion. And yes, we also loathe that things get more verbose in many situations, but we didn't see another solution while adopting C++ guidelines for pointer usage.

Contact us for more information
or a personalised quotation

Contact Us