Den 06. sep. 2011 17:33, skrev ext [email protected]: > > Agree, the last two arguments are probably the most severe ones. A > bytecode/p-code backend in V8 would really help here. > > The other option I've been discussing a bit with a few people would be to > split libQtDeclarative into a part containing the engine (JS and QML) and > one containing the graphical items. I don't think that would be > problematic for anybody. The engine would then purely depend on QtCore > (and maybe network). > > It doesn't give us everything, but is probably better than the current > situation with the JS engine only being available with a Gui dependency. > > Kent and Jedrzej will look into this right now so we can get a clean split > between the engine and the QML items. Let's see how we move on once that's > done. > > Cheers, > Lars
If QColor were in QtCore, this split would be a breeze :D (QML has intrinsic support for it) (Yes, moving QColor to core would be a violation of all we hold holy -- but hey, there's already precedence with QPoint and friends) (And no, it can't be moved anyway because it depends on X11 (for translating strings to colors)) (But yes, we could have a runtime hook in QApplication to still support that) (Or how about just nuking the X11 color support for Qt 5 -- QColor::allowX11ColorNames(), wtf?) Kent _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
