> > This is something worth thinking about. I noticed the fonts weren't the > right size, implying that the port on iOS isn't picking up the best font > size, and all the UI controls are sized based on the font, so in theory > this might be sufficient. But it is true a spin-off with bigger insets > might be necessary (but it isn't clear to me at least that this will be > needed).
I don't think basing the controls size on the font used is the best solution, at least for embeded/mobile. The design guidelines for each platform mention a min size a control should have so that your finger is able to touch it and there is no way 2 controls side by side can be mistakenly touched. This differs from platform to platform as each as its own studies on the size a control should have for you to easily touch it with a finger. So this is based on studies which are in turn based on peoples finger sizes. Yes, we already show the native keyboard. One mechanism we've discussed for > input methods is to have some attributes you can add to a > TextInputControl's properties map, which can then be used to show the right > keyboard UI. Cool!! That's kind of the way you do it in HTML5: you add an attribute saying which type of text is going to be entered on the input field. Thanks, best regards, On Wed, Oct 23, 2013 at 12:35 AM, Richard Bair <richard.b...@oracle.com>wrote: > > On Oct 22, 2013, at 9:38 AM, Pedro Duque Vieira < > pedro.duquevie...@gmail.com> wrote: > > These have are just styled CheckBoxes (or Toggle buttons, or Radio >> Buttons). We've done this for example for DukePad. > > Yes that's right but I think that as it is used so much on Android, ios > and windows 8 it should have a control representation. For instance the > same can be said of checkbox, you can make one out of a styled toggle > button but as it is used so much it merits being a control. > > > This is true. From a class count perspective (and embedded) it probably > would have been better for us not to do CheckBox and RadioButton, but just > do ToggleButton with some static final ints for doing the styling. But then > again, maybe not. > > > and in having controls that have the necessary properties so that they > can > > be "touchable". > I'm talking about having the appropriate size for instance for you to > touch it. You can't use Modena straight out for a mobile app. Perhaps > having a Modena spinoff that has touch in mind. > > > This is something worth thinking about. I noticed the fonts weren't the > right size, implying that the port on iOS isn't picking up the best font > size, and all the UI controls are sized based on the font, so in theory > this might be sufficient. But it is true a spin-off with bigger insets > might be necessary (but it isn't clear to me at least that this will be > needed). > > What about input controls that popup the ios keyboard for entering text. > Is this already available? If not how can these be achieved. Also we should > keep in mind that the keyboard has to change in accordance to what the user > has to enter: address, number, email, etc.. > > > Yes, we already show the native keyboard. One mechanism we've discussed > for input methods is to have some attributes you can add to a > TextInputControl's properties map, which can then be used to show the right > keyboard UI. > > Richard > -- Pedro Duque Vieira
