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

From Qt Wiki
Revision as of 17:40, 12 March 2015 by AutoSpider (talk | contribs) (Decode HTML entity names)
Jump to navigation Jump to search
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.io/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=13524"