* Images can be used but must be hardcoded for one dpi. This brings to mind an issue I see on a daily basis. I am working on pixel perfect designs. Having the pixels in my images map directly to the pixels on the screen in the simplest way to create a design. DPI support for images sounds nice on paper, but I cannot believe it will be simple in reality. Simply because to see what it means you have to run the app on several devices. Which leads me to fonts. Currently fonts default to using point size, not pixel size, so fonts are DPI aware.
So I run my designs on three platforms. The desktop, Maemo and Symbian. For productivity reasons most of my time is spent developing on the desktop. However whenever I deploy to Symbian or Maemo the fonts are now the wrong size. This kind of behaviour at first seems totally unintuitive. The rest of the UI, all the images, rectangles, whatever all look the same on all 3 platforms. But fonts don't. We need to think about this problem. I have seen articles that the web is heading towards resolution independence. However most of the web deals with the flow of text and images in a document. The system can do a pretty good job and you do not notice the odd places weird things happen. But in an app everything is pixel perfect. A good app anyway. My solution to the problem has been to start to use font.pixelSize instead of pointSize. All I care about it that I can predict what the design is like on a mobile. This goes out the window with DPI support and that is a big problem. - Nigel Hello all, I've collected those feedback : * Mouse selection needs to be implemented in each list view with a mouse area. It is necessary to implement the logic of "when an item is clicked, make it the current item", whereas keyboard selection is built in. * Can't access the data of the current item in the view from outside the delegate. Inside the implementation of a delegate, it is possible to use model.customDataRole inside the implementation of a delegate, but if in another element you want to get particular data for "the current item selected in that view", it doesn't seem possible in QML. * Event handling is problematic as there is no pass through. If an Element does not handle an event there is no way to pass the event to its parent. * Lack of widgets for basic elements such as Buttons, sliders scrollbars leads means they all have to be implemented from scratch visually and logically, perhaps badly. * Lack of a size hint is also a problem. * Should there be a hook for when new children are added to an Element? onChildrenChanged is not (currently?) working as expected. * Lack of font metrics makes working with text difficult. If the size is defined in the parent, can't figure out how big the text is to resize the parent to it. For example, rotate a Text element 32 degrees and put it into a unrotated rect of just the right size. Size hint would help here. * More drawing primitives such as rounded polygons would be useful. Trying to design as edge with a rounded flap on the side for dragging is not easy. * Images can be used but must be hardcoded for one dpi. Any comments? _______________________________________________ Qt-qml mailing list [email protected]<mailto:[email protected]> http://lists.trolltech.com/mailman/listinfo/qt-qml
_______________________________________________ Qt-qml mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-qml
