Qt-contributors-summit-2013-QtQuickControls CS 2013: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
==Minutes from the Qt Quick Controls session==


Qt Contributors’ Summit, Tuesday July 15, 2013 @15.00
===Plans for Qt 5.2===
* Deployment: Not easy with 5.1. Hope to simplify with 5.1.1 and even more with 5.2
* Provide a C++ QQuickAction <span class="caps">API</span> – possibly support QAction with controls directly
* Cannot deploy multiple icon sizes currently – possibly introduce a new file format/descriptor for multi-resolution images
* Make the widget dependency a run time dependency. (currently only possible at compile time).
New <span class="caps">API</span>:
* Settings <span class="caps">API</span>: In review (see https://codereview.qt.io/#change,59149)
** Consider putting it in labs for now. Will ask Thiago about it.
Plans for desktop controls:
* Inter application drag&amp;drop
* Complete styling <span class="caps">API</span> for all controls
* Calendar control
* Pickers
* Editable combo boxes
* Make it easier to make dialogs
Touch Controls:
* Extend the controls with more touch specific components
* However all controls will run on all platforms
* Plan to design and implement a generic touch style
===Q&amp;A===
* What about different dpi’s?
** Solution is to have two different sets of pixmaps. By using the Styling <span class="caps">API</span> you can take care of what to use where.
Tizen about Styling:
* Tomasz from Tizen: Would like to move the controls’ logic to the Style as well (not only to look)
** instead “import qtquickcontrols.tizen”
** Will have the the same challenge for Galaxy-style, Sailfish etc.
** Will look at the use cases first
* E.g. ContextMenu (Java: DropDown menu. Tizen: pop-up)
** Can use native menu on Android
** Could make and <span class="caps">API</span> to style the style
* Suggestion: Tizen make a list of where the logic should change compared to the current set of controls. Then the controls team can evaluate whether the logic can be put into the control implementation and optionally turned on with a flag.
Mac Controls
* Wish for Mac extra like controls
** Fall back to native controls
** import qtquickcontrols.mac should be reserved for things that are purely Mac specific
** Could use styleHints. (not official yet): styleHInts: {“rounded”: true}
* Will try to fix the Unified ToolBar for 5.2
More Q&amp;A
* Menu object is a Qt Quick Item.
* For very fancy Controls (like a tree view inside a combo box): End user still has the option to develop this themselves by using <span class="caps">QML</span>.
* Why are there inconstancies between Layouts for Widgets and Controls? (e.g. radio buttons in the widgets world are made into a group box)
** Answer: This seems too be much magic. Want to be declarative. But to be considered.
* Resize “stutters” on LInux
** Answer: This is a Window manager issue that cannot really be solved within Qt. (any opengl windows display similar behavior)<br /> (There is a Window manager guy at QtCS: Gunnar should discuss with him)
* Adaptation for different form factors
** Should controls be adaptable
** Can internally depend on adaptation selectors
** Goal is not to have one set of controls that look good on all platforms

Revision as of 14:09, 25 February 2015

Minutes from the Qt Quick Controls session

Qt Contributors’ Summit, Tuesday July 15, 2013 @15.00

Plans for Qt 5.2

  • Deployment: Not easy with 5.1. Hope to simplify with 5.1.1 and even more with 5.2
  • Provide a C++ QQuickAction API – possibly support QAction with controls directly
  • Cannot deploy multiple icon sizes currently – possibly introduce a new file format/descriptor for multi-resolution images
  • Make the widget dependency a run time dependency. (currently only possible at compile time).

New API:

Plans for desktop controls:

  • Inter application drag&drop
  • Complete styling API for all controls
  • Calendar control
  • Pickers
  • Editable combo boxes
  • Make it easier to make dialogs

Touch Controls:

  • Extend the controls with more touch specific components
  • However all controls will run on all platforms
  • Plan to design and implement a generic touch style

Q&A

  • What about different dpi’s?
    • Solution is to have two different sets of pixmaps. By using the Styling API you can take care of what to use where.

Tizen about Styling:

  • Tomasz from Tizen: Would like to move the controls’ logic to the Style as well (not only to look)
    • instead “import qtquickcontrols.tizen”
    • Will have the the same challenge for Galaxy-style, Sailfish etc.
    • Will look at the use cases first
  • E.g. ContextMenu (Java: DropDown menu. Tizen: pop-up)
    • Can use native menu on Android
    • Could make and API to style the style
  • Suggestion: Tizen make a list of where the logic should change compared to the current set of controls. Then the controls team can evaluate whether the logic can be put into the control implementation and optionally turned on with a flag.

Mac Controls

  • Wish for Mac extra like controls
    • Fall back to native controls
    • import qtquickcontrols.mac should be reserved for things that are purely Mac specific
    • Could use styleHints. (not official yet): styleHInts: {“rounded”: true}
  • Will try to fix the Unified ToolBar for 5.2

More Q&A

  • Menu object is a Qt Quick Item.
  • For very fancy Controls (like a tree view inside a combo box): End user still has the option to develop this themselves by using QML.
  • Why are there inconstancies between Layouts for Widgets and Controls? (e.g. radio buttons in the widgets world are made into a group box)
    • Answer: This seems too be much magic. Want to be declarative. But to be considered.
  • Resize “stutters” on LInux
    • Answer: This is a Window manager issue that cannot really be solved within Qt. (any opengl windows display similar behavior)
      (There is a Window manager guy at QtCS: Gunnar should discuss with him)
  • Adaptation for different form factors
    • Should controls be adaptable
    • Can internally depend on adaptation selectors
    • Goal is not to have one set of controls that look good on all platforms