Edit: 1-28-2008 / Phil

--------------------------------------------------------------------------

(1) String Chaos / UNICODE 

We have been using Qt3 QString for a lot of our development.  Not so much 
in the data model libraries (where we're using RWCString).  We sort of 
assumed that we would adopt QString as our replacement for RWCString.
That's not so clear any more.

We're already bogged down in string processing, and the expense of 
handling UNICODE strings (especially with ASCII conversions which will
always be necessary) doesn't make sense.  It doesn't get us anything 
we really need.  Of course, we need to use QStrings for our Qt4 client
code -- but not necessarily everywhere.

What are Qt4 developers with similar development doing for strings?
Standard String?  Any other options which are ASCII-based?

--------------------------------------------------------------------------

(2) Qt4 Model-View's use of QVariant for model data access ...

QVariant encoding and decoding of model data (real RiverWare model 
data) in the Qt4 Model-View Architecture interface may be a mistake for us.

We will be implementing custom rendering and editing in a "Delegate".
It would be clearer to code directly to our data model APIs (Sim, 
Accounting, Rpl, etc.) using well-named static types.  The QVariant 
encoding doesn't provide a useful role, I think.  Am I right?

Maybe I'm missing something?

For inter-process interfaces, a QVariant class could be good.  But if
we stay primarily single-threaded, QVariant encoding adds complexity, 
is harder to debug, and isn't compilation-time type safe.

--------------------------------------------------------------------------

(3) What to do for a Table widget?

Is the Qt4 QTable any more flexible than the Qt3 QTable?  Does Qt4 QTable
allow you to provide your own subclass of QHeader?  (No in Qt3).

ICS's QicsTable?  
And, why no protected interface? (Is that right?) Then, is it very extensible?

Probably, we should get some experience with Qt4 QTable before we consider
alternatives.

--------------------------------------------------------------------------