Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries. Thanks for all your past and future contributions.

Talk:Prepare your application for Nokia E6

From Wiki
Jump to: navigation, search

Featured article, May 1st 2011 (week 10)

This is very Symbian C++ centric in the native section. I've subedited and attempted to make it more balanced on Qt, but there is stuff I don't know where to link to (or I figure you can find faster). It has virtually nothing on Qt Quick, and I believe this needs to be covered. AFAIK at the moment there is a school of thought that says you provide a screen specific layout for the main resolutions and dynamically select the one that matches the device as this is easy enough to do in Qt Quick that it doesn't cost you too much.

Some specific questions below

"When developing Qt application, use the built-in layout manager to position, align and resize the UI elements, or ensure that code driven positioning is not hardcoded"

What about with QML, where usually everything is hardcoded

The recommended way is to use the logical fonts provided through the UI Framework Utilities API (AknLayoutUtils ...)

What about on Qt?

In particular for Nokia E6, the device does not have a dedicated camera key. Applications should therefore be ready to handle EKeyOk as a camera trigger button.

What does this mean? Any app, or any camera app? Are you saying that any app that doesn't use EKeyOK should prepare to launch the camera?

how to implement the split view input, see Split view input in Symbian C++ applications.
  • what about Qt. Does the rectangle shrink for the split screen and attempt to resize (sounds ghastly) or is this an overlay?
  • what about QML

Basically this is Symbian C++ specific, and it needs to explain how you can turn off split view if it makes no sense in a device.

Applications should therefore be ready to handle EKeyOk as a camera trigger button.

Not sure that makes sense. Do you mean "camera applications should be ready ..."?

Regardless, at any given time application developers may query the client rectangle size and determine the correct location of application’s resources within it.

Really? I don't think so on Qt. Qt oversimplifies and just resizes and re-lays out all the widgets when it detects the size of the available rectangle changes. This works provided the layout positioning still makes sense in the changed alignment. Often i won't so we really should guide users on what they do in the case where they need a separate layout.

The best approach is for the application to use both solutions, and have a high resolution image that can be used at native resolution or can be scaled-up when needed.

What do you mean here by "native resolution". I think perhaps this whole section is a little unclear - Do you mean resolution used by your preferred device and scale for everything else?. Or perhaps you mean use the maximum size image you'll ever need and scale down, since this is almost always more effective than scaling up. Thoughts?

 The components can then be allowed to scale up from the given minimal value for each device, but not below it.

Any advice here for Qt? Do the standard components do this for you?

The recommended way is to use the logical fonts provided through the UI Framework Utilities API (AknLayoutUtils ...)

Very Symbian C++ centric. What is the story for Qt and logical fonts? This is a simple approach, but we should also point to code for scaling on device independent font metrics - twips.

VGA layout: the Qt Homescreen (using the threerows template) 

Broken link for "Qt Homescreen"

Perhaps we should also link to some common glossary terms like "navikey"