I think I've stated before that I'd like to use Wt as a companion to Qt. I've
been able to accomplish this, but it isn't pretty. I was wondering for 3.3 if
the goal could be more Qt compatibility?
The modifications to the Qt UIC work well enough. But after that there is much
pain. A lot of it seems trivial ("Why didn't they stick with the Qt API?" i.e
WString::empty() vs QString::isEmpty()) but I have to admit that there is
enough compatible meat on the bones that it is encouraging. I've moved onto the
model-view stuff. And some drawing of widgets.
Ideally I'd like to see Wt be used as an alternate visualization of widgets
using the real Qt classes. This makes me wonder if I should just start my own
project or of Witty is willing to carry the torch. Witty has many awesome
features implemented already, but the best way I see to use the two would
require Witty be slave to Qt. Let me elaborate on what I've done so far...
First the goal: use one source and header file and one UI file, but have
separate ui_*.h files to create 2 applications - one Qt and one Wt. The desire
is to write Q* class code with a minimum of #ifdefs. (I chose Q over W, since Q
API is larger (GCF)). I work the magic with a graduated response of typedefs W*
to Q*, and if that doesn't work well, actual Q* classes that inherit from the
W* classes, or new classes entirely that proxy the W* classes. This would
result in source that should work with a minimum of non-shared code. Ideally
the code would work 100% with this compatibility layer. I generate two binaries
which are the Qt and web versions, controlled with a simple #define. With that,
I put things in motion...
I modified UIC to use Wt includes and classes when passed a Q* header or class.
This allows you to use Designer and setupUI() with WWidgets. However
immediately there are issues. WString is not as full featured as QString, and
the constructors differ. Wt has various base widgets (WContainerWidget,
WPaintedWidget) while Qt just has QWidget. This can be made allowanced for bt
tyedefing QWidget to various WWidget bases, and WWidget bases being typedefd to
those altered bases (typedef QWidget CWidget; typedef WConainerWidget CWidget
according to the #define)
I then create a dialog and code it for Qt, then I flip the #define and compile
for Wt. Then I work on the huge list of errors. It's just a lot of little
gotchas. Like:
#ifndef WT
void SignalQualityWidget::paintEvent(QPaintEvent *event)
{
QPainter painter(this);
painter.setRenderHint(QPainter::Antialiasing, true);
drawOnDevice(&painter, QBrush(Qt::black));
QWidget::paintEvent(event);
}
#else
void SignalQualityWidget::paintEvent(Wt::WPaintDevice* paintDevice)
{
QPainter painter(paintDevice);
drawOnDevice(&painter, QBrush(Wt::black));
}
#endif
(here I wrap the common dirty work drawOnDevice())
The end result has more #ifdefs and less shared code than I'd like but it's
tempting to grin and bare it.
So my question is, how much of a formal challenge would it be to get things
more aligned with Qt?------------------------------------------------------------------------------
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and
improve service delivery. Take 5 minutes to use this Systems Optimization
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
