[Qt5-feedback] Moving itemmodels to QtCore

[Sean Harmer]

Hi,

On Monday 04 July 2011 15:10:32 Stephen Kelly wrote:
> Thiago Macieira wrote:
> > Em Monday, 4 de July de 2011, às 10:01:52, Sean Harmer escreveu:
> >> On Monday 04 July 2011 10:52:47 Thiago Macieira wrote:
> >> > Em Monday, 4 de July de 2011, às 09:30:05, Sean Harmer escreveu:
> >> > > We have recently had a use case where we would have liked to
> >> > > have
> >> > > used QSortFilterProxyModel in a non-gui library that is aimed
> >> > > to be
> >> > > used by a desktop app and a headless app on a server. This is
> >> > > not
> >> > > possible due to the above being part of QtGUI. We ended up
> >> > > reusing
> >> > > the QSFPM subclasses in both GUI and headless versions of the
> >> > > apps
> >> > > themselves.
> >> > > 
> >> > > I would vote for moving the above into QtCore where possible.
> >> > 
> >> > You can use QtGui in a headless application. Just don't use
> >> > QApplication.
> >> 
> >> I know but only if it is on the server and that normally involves
> >> pulling all of X (even if they are not needed at runtime).
> > 
> > That's a non-issue when discussing Qt5 since QtGui won't link to the X
> > libs anyway. Only the XCB platform plugin will.
> > 
> > At most, QtGui will link to interesting libs like libpng.
> > 
> > If you don't use QApplication, no QPA platform plugin will be necessary.
> > And you could even use an ASCII-Art plugin if you wanted:
> > https://qt.gitorious.org/~nebulon/qt/nebulons-lighthouse
> 
> So along what lines should QtCore and QtGui be split?
> 
> If it's not 'stuff that is non-gui (or model)' and 'stuff that is gui', is
> it 'Make QtCore as small as possible; put useful stuff in QtGui'?
> 
> Why is the math3d stuff in QtGui? (I've never used it, but I presume it's
> for non-gui dependent math stuff)
> 
> Why is the state machine stuff in QtCore? Nothing else in QtCore depends on
> it. If the goal of QtCore is 'smallness' rather than 'usefulness' then it's
> in the wrong place.
> 
> Why not merge QtCore and QtGui? People can still use QCoreApplication or
> QApplication depending on whether they want a headless application. Does a
> split really make sense?

Or if not then could someone please define what criteria determines what 
library/class goes where please? As Steve says it is very confusing at the 
moment and there are several examples where a move/split/merge could 
potentially be justified.

Cheers,

Sean