Qt-contributors-summit-2012-Qt-Quick-Components: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
Line 1: Line 1:
=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<br /> Jens, Nokia – main developer of the desktop components<br /> Frederik, Nokia – accessibility in <span class="caps">QML</span> and qt-components<br /> Shawn, Nokia<br /> Florian, Tim, Loïc, Gerry, Ubuntu/Canonical – working on components for Ubuntu<br /> Daker, INdT – working on theming for components and plasma components<br /> Arvid, <span class="caps">RIM</span> – solving the components problem in a quite different way; session tomorrow on Cascades<br /> Gabriel, Nokia – Meego components<br /> Thiago Lacerda, INdT<br /> Anselmo, INdT<br /> 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? <span class="caps">API</span>s seem to be a common denominator
* we cannot contrain everybody to a single <span class="caps">API</span> that covers everything. we need to let people have additional platform/OS specific components
* should we have components exposed to C++? – <span class="caps">RIM</span> does it – to hide implementation details or for security – for official/recommended Qt5 we would like to only expose <span class="caps">QML</span> <span class="caps">API</span>s – some things are not possible to do without C++ because of some <span class="caps">API</span>s being private
* ‘simple’ components (buttons, tabs, etc.) are easy to have common <span class="caps">API</span>s accross OSes and platforms; more complicated/custom components will be simply platform specific <span class="caps">API</span>s
* need a tool to verify conformance/compliance of various implementations against common <span class="caps">API</span>s
* desktop components solve 2 issues: – looking native – designing desktop oriented components <span class="caps">API</span>s
* how do we do treeviews? lack of model
* the delegate approach to styling is interesting
* INdT’s target: desktop windows, mac, linux (<span class="caps">KDE</span>, <span class="caps">GNOME</span>)
* 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 <span class="caps">API</span> development; need for designers to design something at least basic; INdT could contribute designer time
* styling approaches? – delegate approach: every widget has a fixed <span class="caps">API</span> and logic but then the rendering is done via custom <span class="caps">QML</span> delegates; shortcomings: ? – INdT’s approach: description? – desktop components: description? reusing QStyle? supporting QStyle is painful; writing QStyles properly is difficult
* <span class="caps">RIM</span> does not have a styling problem: they just implement their own thing
* <span class="caps">QML</span> is a style language; no need for <span class="caps">CSS</span>? people think it would be nice to have <span class="caps">CSS</span> 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 <span class="caps">API</span> conformance testing – <span class="caps">API</span> review sessions negotiating between platform stakeholders (symbian, meego)
* minimalistic <span class="caps">API</span> in philosophy (<span class="caps">QML</span> is easy to extend)
* multi selection list views would be useful
==Actions==
Main action for all:<br /> 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 <span class="caps">API</span> development
* Schedule styling discussion [DONE]
* check copyright and licensing of components: <span class="caps">BSD</span>, for meego and desktop components copyright is Nokia [DONE]
* Write summary of styling discussion &amp; 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 <span class="caps">API</span> 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 [[Qt Quick Components|http://wiki.qt.io/Qt_Quick_Components]] and see if and how to merge with [[QtDesktopComponents|http://wiki.qt.io/QtDesktopComponents]] → http://sketchpad.cc/B8MntLJEzp current state (unformatted) [GERRY &amp; <span class="caps">DAKER</span> – IN <span class="caps">PROGRESS</span>]
* 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, <span class="caps">TIM</span>, <span class="caps">FLORIAN</span>, IN <span class="caps">PROGRESS</span> <span class="caps">BELOW</span>]
* Define and document publically <span class="caps">API</span> development process [DONE]
* Create a table showing the correspondence between QWidgets and <span class="caps">QML</span> components – we will not replicate every single QWidget. [?]
==List of common components==
Platforms looked at:<br /> touch: jQuery Mobile, Cascades, Meego components, iOS (<span class="caps">UIK</span>it), Android<br /> desktop: Qt Desktop components, Plasma<br />https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Ajl6r4psredKdERGSUl1WGR1WVBhTWlSUXVsbXEtWkE<br /> Please request write permissions if you like.
===desktop and touch===
Button: jquerym, cascades, qt desktop, Meego, iOS, Plasma, Android<br /> Label: iOS, Meego, Plasma, cascades, jquerym (via html), qt desktop, Android<br /> Toolbar: iOS (UINavigationBar), Meego, jquerym, Plasma, cascades, qt desktop, Android (ActionBar)<br /> TabBar: iOS, Meego, Plasma, cascades (TabbedPane), Android (TabHost), qt desktop, jquerym (navbar)<br /> Checkbox/Switch: Meego, Plasma, Android, Cascades, qt desktop, jquerym (via html), iOS<br /> RadioButton: Meego, iOS (classname?), Plasma, Android, jquerym, qt desktop, cascades (RadioGroup)<br /> TextInput: qt desktop, jquerym, Plasma, Android, Meego, iOS, Cascades (TextField)<br /> Slider: qt desktop, Cascades, jquerym, Meego, Plasma, iOS, Android<br /> ProgressBar: qt desktop, Cascades (ProgressIndicator), Meego, Plasma, iOS, Android<br /> ScrollBar/ScrollArea: qt desktop, Plasma, iOS (ScrollView), Meego (<span class="caps">QML</span> Flickable, no scrollbar), Android<br /> Split buttons: Meego (ButtonRow/ButtonColumn), jquerym, Cascades (SegmentedControl?)<br /> Dialog: Meego, Plasma, Android, iOS (popover/AlertView), qt desktop, jquerym<br /> ComboBox: qt desktop, jquerym (select menu), Cascades (DropDown), Android (NumberPicker)<br /> List/ListItems/ListHeaders/Dividers [various types, requires deeper investigation]<br /> Grid/GridItems<br /> Layouts/Row/Columns<br /> SpinBox: qt desktop, Android<br /> ContextualMenu: qt desktop, Plasma, Android<br /> Systray/Indicators<br /> Date/TimePicker: jquerym, Cascades, Android, iOS
===desktop specific===
TableView: qt desktop, Android<br /> TextArea: qt desktop, jquerym, Plasma, iOS<br /> Frame: qt desktop, Android<br /> MenuBar: qt desktop, <br /> TreeView:
===touch specific===
PageStack: Meego, jquerym, Plasma, iOS<br /> Spinner: Cascades (ActivityIndicator), Meego, Android, Plasma (BusyIndicator), iOS
==<span class="caps">API</span> Development Process Ideas==
* process to happen on mailing list
* when making <span class="caps">API</span> proposal/change always include: <span class="caps">API</span> definition and real world example (from a developer standpoint)
* once decided upon an <span class="caps">API</span> proposal/change documentation has to be written right away
* enforcing a timeline around <span class="caps">API</span> discussion: from start of <span class="caps">API</span> definition to decision on it: 1 week
* making sure that at least one representant of each interested platform validates the <span class="caps">API</span> (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

Revision as of 13:56, 24 February 2015

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