> My concern is that QtCore is not a dumping ground for "everything non-GUI that > some library or app might need". We now have two discussions about moving > classes into QtCore. > I want to see a good argument of why it should be in QtCore, as opposed to why > it shouldn't be in QtGui. 99% of the applications link to QtGui anyway, so I'm > not convinced the move would gain anything in any way.
I do *NOT* wanna have the QtGui stack as a dependency. If you think, I should establish another module for these few classes because you do not accept this in QtCore, I will. Again, this is VERY bad to depend on the whole UI stack if you have nothing to do with UI. In general this is a bad approach IMO. I am waiting for a compelling reason why a non-ui library should depend on the UI stack. 99% of the applications link to QtGui, but the command line parser is still supposed to be in QtCore anyway, so this is not a good stance in my book. > And you also need to tell me that the classes are generally useful, even > outside of any relation to OpenGL (which was their original goal). Many classes have recently been moved from one module to another for good, no matter what their "original goal" was. So what do you propose? Not extend the scope when the need arises because that is now how something was established? Best Regards, Laszlo Papp _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
