On 01/17/2013 04:34 AM, Shawn Rutledge wrote: > On Wed, Jan 16, 2013 at 08:37:27AM -0800, Alan Alpert wrote: >> I can't find the current docs, but the mobility APIs already exposed a >> wealth of system information in the SystemInfo plugin: >> http://doc.qt.digia.com/qtmobility/qml-systeminfo.html . The right >> place for all this more device general stuff is there, we can just >> bring that back in Qt 5 (if it isn't already). I really think that >> SystemInfo is a much better place for this than Screen, which is >> supposed to encapsulate the screen you're currently running on (not >> the whole device!). It also has a lot of other useful device >> information. > I didn't mean the Screen object would have irrelevant stuff; my point > is that there should be a specific import for the system-level stuff, and > Screen and Window could probably be part of that same module because > they aren't 100% portable (although they are mostly portable). As > it is, Screen is in the Window module. But if you can get Screen > you already can have enough information to optimize the UI for > tablet/phone/desktop use cases (provided that the Screen object becomes > complete enough, which it currently isn't); e.g. if the screen is over > 5 inches then maybe it should have a tablet-optimized layout rather than > phone-optimized, and if it doesn't have touch then you know there will > probably be a mouse instead. Unless you are trying to make a pixel-perfect > replica that looks like it was made with native widgets, you shouldn't > need the OS, windowing system, device name etc.
But that is what J-P is trying to do: Create a pixel perfect replica for the OS. > > It's kindof like the question how do you identify the type of an object > in QML or JS? One common answer is don't try, because the question you should > probably be asking instead is, does the object have the properties I need? > The fewer assumptions the code makes, the easier it is to port to different > component sets and QtQuick versions. It's the same with trying to tailor > a UI specifically for some specific device that's only going to be sold for > one year and used for two; you can bet that code will have a short life, > and waste your time later if the app is worth porting to the next device. > Personally I don't like rewriting things over and over again. > > The SystemInfo plugin has a bit more than "everyone" needs, but > I agree the minority-use-case stuff could go in there. But then it > needs to be a Qt essential module so that app developers can depend on it. > Some features will never work on every platform (brightness and contrast > etc.), only on some. Others just need attention to make them work everywhere > that they can. It seems like a mixed bag, and the docs don't make clear > what you can depend on and what you can't. "Mobility" is also a misnomer > on a desktop machine. If you want to write a QML app or component set > that still runs everywhere Qt runs in 5 years, I doubt you want to be using > that module in its current form. > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
