> -----Original Message----- > From: Shawn Rutledge [mailto:[email protected]] > Sent: Thursday, October 04, 2012 11:09 AM > To: Tony Van Eerd > Cc: [email protected] > Subject: Re: [Development] resolution independence (was Re: Retina > display support) > > On 4 October 2012 16:27, Tony Van Eerd <[email protected]> wrote: > > I think proper resolution dependence and independence requires, at > times at least, 2 separate measurements for each widget: > > > > visual measure: > > touch measure: > > The problem, of course, is that both these measurements need to be > rendered onto the same surface. > > If you declare > > Rectangle { > width: 20mm > height: 10mm > scale: 1.5 > }
If scaled, why pretend it is mm? > > then you'd expect it to be 30mm wide, right? And if you want to make > it global, it can be bound to a zoom value for the whole app. > Sure. The question is, is that want the designer wants? What was the intent, and why? Do they want it 20mm because it looks good? Where? On a hand-held device? On a desktop? On a projector? Is 20mm because they want to guarantee an easy touch target? Or easy to see from a particular distance? Why did the designer select 20? What are they really trying to convey? Maybe what they really want is 5% of screen, and they *think* the screen is 40cm wide? (My ideas don't address that case...) A global scale factor will handle most cases, but it doesn't completely capture designer intent. I posit that intent is typically either "to see" or "to touch", and that we have a fairly new problem at hand: that these intents no longer align as well as they use to. In the past, you didn't touch displays, and in the past, you could see individual pixels. So we could get away with loose approximations where seeing sizes and touch sizes overlapped. Maybe now we can't. (Typically we still can, and typically a scale factor works, but I like to understand the details before going back to approximations.) --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
