On Saturday 20 September 2008, Emanuel Rumpf wrote:
> I'm not pointing on anyone. If I sounded offending, I'm sorry for that.
I'm sorry I couldn't avoid getting angry. I know this is all a communications
problem, but it is very frustrating to deal with.
Our communications are terrible, and our communications with you in particular
seem to be the worst of all, because you came late to the game, and we have
done a poor job of putting all our previous discussion together so it is easy
for new people to read through.
> > I didn't realize someone was switching things back on purpose.
> Yes, with purpose, but what means "back" here?
> The conversions are a step forward to qt4 support,
> that's how I see it.
Someone started using QTableWidget, and when I saw QTableWidget errors, I
switched some things to use Q3Table and related classes, as we discussed in
early August, to make the errors go away and get code building. I thought
this was from the mechanized port going wrong until I noticed that some of
the QTableWidget used to be KListBox, and that's when I posted the start of
We've been working in conflicting directions for some time, apparently, and
it's because I did a poor job of communicating all the past discussion, and
you did a poor job of communicating what you were doing and why.
> I can't find any good reason to keep the Q3 classes, but
> I'd like to here a third person here.
If you can make changes to Qt4 classes you are VERY sure will work without
introducing strange new problems, then go ahead. I didn't see a way to do
that with QTableWidget, but you are a better (or at least far more patient
and dedicated) programmer than I am.
What sets Q3Table and Q3Canvas and some others apart from the other Q3 classes
is that they are whole, self-contained Qt3 classes whose methods work only on
other Q3 relatives, rather than convenience classes that merely call the new
API of classes similar to their Qt3 ancestors. This code has to be rewritten
from top to bottom using new classes and new methods, new ways of solving old
problems with brand new tools, and this can involve a lot of blind guesswork
that might lead to mysterious problems.
We already have to do a lot of blind guesswork that absolutely can't be
avoided, but we wanted to keep the guesswork to a minimum at first, and get
something to run so that we would have a working framework in which to
experiment with the more difficult rewriting efforts. That's why we're using
Q3Canvas (the absolute worst case) and that's why we decided to use Q3Table
and a small handful of other Q3 classes.
Now you know why. What do you think about QTableWidget now that you've been
looking at it? Are you REALLY sure you can do this rewrite without
introducing mysterious problems?
If so, go ahead. You're right that pure Qt4 is the final goal, and using Q3
classes only moves work to the future. I'm not opposed to this rewrite if it
can be done with a high degree of certainty.
It *did* irritate me that you yelled at me over this when my reasoning was
quite sound and conservative. It's better to put off some jobs for a time
when we can actually see this thing work than to introduce a lot of strange
new problems to have to debug. It is a gray area and it is hard to make
decisions on anything but a case by case basis. Q3Table is where we came
down on that particular case, but that decision is not chiseled in stone.
D. Michael McIntyre