Qt-contributors-summit-2012-Qt-Quick-Components

From Qt Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

Qt Quick Components – Qt Contributor Summit 2012

Participants

Leonardo, Nokia – working on qt-components since the beginning focusing on meego/symbian; what would we like to do for Qt5 components wise? We have alot of xp and would like to share it
Jens, Nokia – main developer of the desktop components
Frederik, Nokia – accessibility in QML and qt-components
Shawn, Nokia
Florian, Tim, Loïc, Gerry, Ubuntu/Canonical – working on components for Ubuntu
Daker, INdT – working on theming for components and plasma components
Arvid, RIM – solving the components problem in a quite different way; session tomorrow on Cascades
Gabriel, Nokia – Meego components
Thiago Lacerda, INdT
Anselmo, INdT
Luis, INdT

Notes

  • people seek continuation from qwidgets
  • quality and completeness should meet what is in QWidget
  • should we try to have common components at all? what can be common? APIs seem to be a common denominator
  • we cannot contrain everybody to a single API that covers everything. we need to let people have additional platform/OS specific components
  • should we have components exposed to C++? – RIM does it – to hide implementation details or for security – for official/recommended Qt5 we would like to only expose QML APIs – some things are not possible to do without C++ because of some APIs being private
  • ‘simple’ components (buttons, tabs, etc.) are easy to have common APIs accross OSes and platforms; more complicated/custom components will be simply platform specific APIs
  • need a tool to verify conformance/compliance of various implementations against common APIs
  • desktop components solve 2 issues: – looking native – designing desktop oriented components APIs
  • how do we do treeviews? lack of model
  • the delegate approach to styling is interesting
  • INdT’s target: desktop windows, mac, linux (KDE, GNOME)
  • idea: creating a component set (2 maybe: a touch one and desktop) with a new/unique/not necessarily super polished that would serve as a reference for platform developers and a central point for API development; need for designers to design something at least basic; INdT could contribute designer time
  • styling approaches? – delegate approach: every widget has a fixed API and logic but then the rendering is done via custom QML delegates; shortcomings: ? – INdT’s approach: description? – desktop components: description? reusing QStyle? supporting QStyle is painful; writing QStyles properly is difficult
  • RIM does not have a styling problem: they just implement their own thing
  • QML is a style language; no need for CSS? people think it would be nice to have CSS support because people know it; it can be a later addition
  • what would the development process look like? – qt quick desktop components: more ad hoc based on Qt – qt quick components: – using a tool for API conformance testing – API review sessions negotiating between platform stakeholders (symbian, meego)
  • minimalistic API in philosophy (QML is easy to extend)
  • multi selection list views would be useful

Actions

Main action for all:
Implement a reference set of touch and desktop components that have their unique styling and serve as a single point of reference and home for common API development

  • Schedule styling discussion [DONE]
  • check copyright and licensing of components: BSD, for meego and desktop components copyright is Nokia [DONE]
  • Write summary of styling discussion & approach proposal with examples inspired from INdT’s approach and qt quick desktop components’ approach + reach out to Plasma people; Jens showed a wonderful experiment based on the desktop components that demonstrates the approach beautifully [DONE]
  • Try to make API conformance checking tool public [LEONARDO]
  • Create qt-components mailing on Qt project: http://lists.qt-project.org/mailman/listinfo/qt-components [DONE]
  • decide on a place to host the reference set of components; one repository with all the components (touch and desktop) and a smart directory structure [ALL]
  • refresh wiki page http://wiki.qt.io/Qt_Quick_Components and see if and how to merge with http://wiki.qt.io/QtDesktopComponents → http://sketchpad.cc/B8MntLJEzp current state (unformatted) [GERRY & DAKER – IN PROGRESS]
  • Check if some designer time would be available for designing very very basic visuals for reference component set [INdT]
  • List common components that would be good to develop; maybe use the cross section of the most popular toolkits [GERRY, TIM, FLORIAN, IN PROGRESS BELOW]
  • Define and document publically API development process [DONE]
  • Create a table showing the correspondence between QWidgets and QML components – we will not replicate every single QWidget. [?]

List of common components

Platforms looked at:
touch: jQuery Mobile, Cascades, Meego components, iOS (UIKit), Android
desktop: Qt Desktop components, Plasma
https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Ajl6r4psredKdERGSUl1WGR1WVBhTWlSUXVsbXEtWkE
Please request write permissions if you like.

desktop and touch

Button: jquerym, cascades, qt desktop, Meego, iOS, Plasma, Android
Label: iOS, Meego, Plasma, cascades, jquerym (via html), qt desktop, Android
Toolbar: iOS (UINavigationBar), Meego, jquerym, Plasma, cascades, qt desktop, Android (ActionBar)
TabBar: iOS, Meego, Plasma, cascades (TabbedPane), Android (TabHost), qt desktop, jquerym (navbar)
Checkbox/Switch: Meego, Plasma, Android, Cascades, qt desktop, jquerym (via html), iOS
RadioButton: Meego, iOS (classname?), Plasma, Android, jquerym, qt desktop, cascades (RadioGroup)
TextInput: qt desktop, jquerym, Plasma, Android, Meego, iOS, Cascades (TextField)
Slider: qt desktop, Cascades, jquerym, Meego, Plasma, iOS, Android
ProgressBar: qt desktop, Cascades (ProgressIndicator), Meego, Plasma, iOS, Android
ScrollBar/ScrollArea: qt desktop, Plasma, iOS (ScrollView), Meego (QML Flickable, no scrollbar), Android
Split buttons: Meego (ButtonRow/ButtonColumn), jquerym, Cascades (SegmentedControl?)
Dialog: Meego, Plasma, Android, iOS (popover/AlertView), qt desktop, jquerym
ComboBox: qt desktop, jquerym (select menu), Cascades (DropDown), Android (NumberPicker)
List/ListItems/ListHeaders/Dividers [various types, requires deeper investigation]
Grid/GridItems
Layouts/Row/Columns
SpinBox: qt desktop, Android
ContextualMenu: qt desktop, Plasma, Android
Systray/Indicators
Date/TimePicker: jquerym, Cascades, Android, iOS

desktop specific

TableView: qt desktop, Android
TextArea: qt desktop, jquerym, Plasma, iOS
Frame: qt desktop, Android
MenuBar: qt desktop,
TreeView:

touch specific

PageStack: Meego, jquerym, Plasma, iOS
Spinner: Cascades (ActivityIndicator), Meego, Android, Plasma (BusyIndicator), iOS

API Development Process Ideas

  • process to happen on mailing list
  • when making API proposal/change always include: API definition and real world example (from a developer standpoint)
  • once decided upon an API proposal/change documentation has to be written right away
  • enforcing a timeline around API discussion: from start of API definition to decision on it: 1 week
  • making sure that at least one representant of each interested platform validates the API (if possible)
  • try to follow Qt naming convention if unsure
  • in case of unresolvable conflict of opinions, an appointed maintainer will have the last word

Taken from http://sketchpad.cc/XKp1Bs7LEp

Retrieved from "https://wiki.qt.io/index.php?title=Qt-contributors-summit-2012-Qt-Quick-Components&oldid=29610"