Merge lp:~zsombi/ubuntu-ui-toolkit/configurableColumns into lp:ubuntu-ui-toolkit/staging
| Status: | Merged |
|---|---|
| Approved by: | Tim Peeters on 2015-08-14 |
| Approved revision: | 1612 |
| Merged at revision: | 1608 |
| Proposed branch: | lp:~zsombi/ubuntu-ui-toolkit/configurableColumns |
| Merge into: | lp:ubuntu-ui-toolkit/staging |
| Diff against target: |
742 lines (+507/-33) 9 files modified
components.api (+10/-0) examples/ubuntu-ui-toolkit-gallery/ubuntu-ui-toolkit-gallery.qml (+20/-0) src/Ubuntu/Components/1.3/AdaptivePageLayout.qml (+129/-19) src/Ubuntu/Components/1.3/PageColumn.qml (+16/-11) src/Ubuntu/Components/1.3/PageColumnsLayout.qml (+115/-0) src/Ubuntu/Components/ComponentModule.pro (+3/-2) src/Ubuntu/Components/qmldir (+2/-1) tests/unit_x11/tst_components/tst_adaptivepagelayout.qml (+2/-0) tests/unit_x11/tst_components/tst_adaptivepagelayout_configuration.qml (+210/-0) |
| To merge this branch: | bzr merge lp:~zsombi/ubuntu-ui-toolkit/configurableColumns |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Tim Peeters | 2015-08-10 | Approve on 2015-08-14 | |
| PS Jenkins bot | continuous-integration | Approve on 2015-08-14 | |
|
Review via email:
|
|||
Commit Message
Introducing column configuration into AdaptivePageLayout.
| Tim Peeters (tpeeters) wrote : | # |
37 + PageColumnsLayout {
38 + when: layout.width > units.gu(80)
39 + PageColumn {
40 + maximumWidth: units.gu(60)
41 + minimumWidth: units.gu(20)
42 + preferredWidth: units.gu(40)
43 + }
44 + PageColumn {
45 + fillWidth: true
46 + }
Why do you set the minimumWidth and maximumWidth here? Do they do anything when preferredWidth, and fillWidth for the other column are set? As I see it that column will always be 40 gu wide.
| Tim Peeters (tpeeters) wrote : | # |
48 + // configure single column mode so we can only size it to minimum 20 GU
49 + PageColumnsLayout {
50 + when: true
51 + PageColumn {
52 + minimumWidth: units.gu(20)
53 + fillWidth: true
54 + }
55
I can resize the window to less than 20 GU. I don't know if we can do anything about that in this MR.
| Tim Peeters (tpeeters) wrote : | # |
73 + These defaults can be overridden throug the \l layouts property by defining the
throug +h
| Tim Peeters (tpeeters) wrote : | # |
75 + be activated. PageColumn configurations must appear in the same order as the
76 + columns appear in the layout, and each column must have a configuration object
77 + assigned.
Perhaps make this "..in the same order (from left to right) as the columns appear..."
"each column must have a configuration object assigned" is not clear to me and should be removed, except if you want to say something important there.
| Tim Peeters (tpeeters) wrote : | # |
At the end of the description that I quoted in the previous comment, can you add that the default is one column when none of the specified conditions is fulfilled?
| Tim Peeters (tpeeters) wrote : | # |
143 + /*!
144 + The property holds the different layout configurations overriding the default
145 + configurations. Defaults to an empty list.
146 + \sa PageColumnsLayout
147 + */
148 + property list<PageColumn
Let's mention the standard layouts that the APL will use when layouts is an empty list.
| Tim Peeters (tpeeters) wrote : | # |
254 + property PageColumn metrics: setDefaultMetrics()
getDefaultMetrics() would be a better name for the function.
| Tim Peeters (tpeeters) wrote : | # |
308 /*!
309 1-based value identifying the column the metrics to be applied to.
310 + \internal
311 */
312 - property int column
313 + property int __column
"protected" properties are always a bit messy in qml, and this one I think is not needed.
As I can see, the only place where it is used, is here:
// default metrics
Component {
id: defaultMetrics
PageColumn {
}
}
in AdaptivePageLayout.
The default metrics is only used when there is no layout with a valid 'when'. So it defaults to defaultMetrics with one column, so fillWidth can always be true.
| Tim Peeters (tpeeters) wrote : | # |
Do we want the developer to always to have to explicitly set the preferredWidth for each column?
If not, we could use a usable default like 40gu instead of 0?
338 +
339 + /*!
340 + Specifies the preferred width of the column when the layout is initialized.
341 + Defaults to 0. Unless \l fillWidth is set, the value must be set. AdaptivePageLayout
342 + clamps the given value between \l minimumWidth and \l maximumWidth.
343 + */
344 + property real preferredWidth: 0
| Tim Peeters (tpeeters) wrote : | # |
407 + PageColumnsLayout {
408 + when: true
409 + PageColumn {
410 + fillWidth: true
411 + minimumWidth: units.gu(10)
412 + }
413 + }
the example in AdaptivePageLayout docs and PageColumnsLayout are *almost* the same, except in PageColumnsLayout you added the 1-column layout:
}
}
Is this intentional? Maybe we need to show the same example only once? If the default PageColumnLayout does not need to be specified, in the example where you leave it out you could add: // When the condition for the above layout does not match, the default fallback with a single column is used.
| Tim Peeters (tpeeters) wrote : | # |
In PageColumnsLayout docs, we should add that when none of the when properties evaluate to true, there is a fallback of a single column.
| Tim Peeters (tpeeters) wrote : | # |
461 + default property alias data: layout.__data
462 + property list<PageColumn> __data//: [PageColumn{}]
can we avoid to expose __data by wrapping it in another QtObject?
| Tim Peeters (tpeeters) wrote : | # |
542 +import QtQuick 2.4
543 +import QtTest 1.0
isn't QtTest included by Ubuntu.Test?
544 +import Ubuntu.Test 1.0
545 +import Ubuntu.Components 1.3
546 +import QtQuick.Layouts 1.1
Are you using QtQuick.Layouts in the test?
| Tim Peeters (tpeeters) wrote : | # |
338 +
339 + /*!
340 + Specifies the preferred width of the column when the layout is initialized.
341 + Defaults to 0. Unless \l fillWidth is set, the value must be set. AdaptivePageLayout
342 + clamps the given value between \l minimumWidth and \l maximumWidth.
343 + */
344 + property real preferredWidth: 0
It seems that it is not true that the value must be set, since in tst_adaptivepag
626 + layouts: PageColumnsLayout {
627 + id: defaultLayout
628 + when: layout.width >= units.gu(60)
629 + PageColumn {
630 + minimumWidth: units.gu(40)
631 + maximumWidth: units.gu(40)
632 + }
| Tim Peeters (tpeeters) wrote : | # |
I am not totally convinced by the names PageColumnsLayout and PageColumn yet, but I haven't been able to come up with something better..
| Zsombor Egri (zsombi) wrote : | # |
> 37 + PageColumnsLayout {
> 38 + when: layout.width > units.gu(80)
> 39 + PageColumn {
> 40 + maximumWidth: units.gu(60)
> 41 + minimumWidth: units.gu(20)
> 42 + preferredWidth: units.gu(40)
> 43 + }
> 44 + PageColumn {
> 45 + fillWidth: true
> 46 + }
>
> Why do you set the minimumWidth and maximumWidth here? Do they do anything
> when preferredWidth, and fillWidth for the other column are set? As I see it
> that column will always be 40 gu wide.
Will be mostly usable when we have the column sizing...I will remove from there for now.
| Zsombor Egri (zsombi) wrote : | # |
> 48 + // configure single column mode so we can only size it to
> minimum 20 GU
> 49 + PageColumnsLayout {
> 50 + when: true
> 51 + PageColumn {
> 52 + minimumWidth: units.gu(20)
> 53 + fillWidth: true
> 54 + }
> 55
>
> I can resize the window to less than 20 GU. I don't know if we can do anything
> about that in this MR.
Yes, but if you check the content won't be sized less than 20GU. Btw, in the original, the window content does';t size less than 40GU... So this actually does something in this MR already!
| Zsombor Egri (zsombi) wrote : | # |
> 143 + /*!
> 144 + The property holds the different layout configurations
> overriding the default
> 145 + configurations. Defaults to an empty list.
> 146 + \sa PageColumnsLayout
> 147 + */
> 148 + property list<PageColumn
>
> Let's mention the standard layouts that the APL will use when layouts is an
> empty list.
It si mentioned in the component description.
| Zsombor Egri (zsombi) wrote : | # |
> 254 + property PageColumn metrics: setDefaultMetrics()
>
> getDefaultMetrics() would be a better name for the function.
I didn't wanted to change everything... but yes, I can do that.
| Zsombor Egri (zsombi) wrote : | # |
> 308 /*!
> 309 1-based value identifying the column the metrics to be applied
> to.
> 310 + \internal
> 311 */
> 312 - property int column
> 313 + property int __column
>
> "protected" properties are always a bit messy in qml, and this one I think is
> not needed.
Actually it is needed in the code below.
>
> As I can see, the only place where it is used, is here:
>
> // default metrics
> Component {
> id: defaultMetrics
> PageColumn {
> fillWidth: __column == d.columns
> minimumWidth: d.defaultColumn
> }
> }
>
> in AdaptivePageLayout.
>
> The default metrics is only used when there is no layout with a valid 'when'.
> So it defaults to defaultMetrics with one column, so fillWidth can always be
> true.
No, this is also used when there's no layout there, so then both columns are using this. If both columns would fillWidth, they would proportionally resize when you resize the window. So it is needed.
| Tim Peeters (tpeeters) wrote : | # |
> > 48 + // configure single column mode so we can only size it
> to
> > minimum 20 GU
> > 49 + PageColumnsLayout {
> > 50 + when: true
> > 51 + PageColumn {
> > 52 + minimumWidth: units.gu(20)
> > 53 + fillWidth: true
> > 54 + }
> > 55
> >
> > I can resize the window to less than 20 GU. I don't know if we can do
> anything
> > about that in this MR.
>
> Yes, but if you check the content won't be sized less than 20GU. Btw, in the
> original, the window content does';t size less than 40GU... So this actually
> does something in this MR already!
Right. And Christian has a fix for it already :) https:/
| Zsombor Egri (zsombi) wrote : | # |
> Do we want the developer to always to have to explicitly set the
> preferredWidth for each column?
> If not, we could use a usable default like 40gu instead of 0?
If you read further, if you set minimumWidth, the preferredWidth will be clamped between mn and max automatically. So if it's 0, the minimum will be taken. This will be needed when resizable column comes anyway. So dev must then set min and max in order to avoid resizing.
But perhaps we can have 40GU, I don't have any specific requirement, if the min & max < preferred, the preferred will be clamped, but then you never know to which, min or max. If it is 0, then it will always take the min.
>
> 338 +
> 339 + /*!
> 340 + Specifies the preferred width of the column when the layout is
> initialized.
> 341 + Defaults to 0. Unless \l fillWidth is set, the value must be
> set. AdaptivePageLayout
> 342 + clamps the given value between \l minimumWidth and \l
> maximumWidth.
> 343 + */
> 344 + property real preferredWidth: 0
| Zsombor Egri (zsombi) wrote : | # |
> 407 + PageColumnsLayout {
> 408 + when: true
> 409 + PageColumn {
> 410 + fillWidth: true
> 411 + minimumWidth: units.gu(10)
> 412 + }
> 413 + }
>
> the example in AdaptivePageLayout docs and PageColumnsLayout are *almost* the
> same, except in PageColumnsLayout you added the 1-column layout:
>
> PageColumnsLayout {
> when: true
> PageColumn {
> fillWidth: true
> minimumWidth: units.gu(10)
> }
> }
>
> Is this intentional? Maybe we need to show the same example only once? If the
> default PageColumnLayout does not need to be specified, in the example where
> you leave it out you could add: // When the condition for the above layout
> does not match, the default fallback with a single column is used.
Yes, it is. It explains after the example.
| Zsombor Egri (zsombi) wrote : | # |
> 461 + default property alias data: layout.__data
> 462 + property list<PageColumn> __data//: [PageColumn{}]
>
> can we avoid to expose __data by wrapping it in another QtObject?
And we loose performance? Doesn't make any sense. Perhaps we move all these to c++, it's lot easier/nicer.
| Zsombor Egri (zsombi) wrote : | # |
> 542 +import QtQuick 2.4
> 543 +import QtTest 1.0
>
> isn't QtTest included by Ubuntu.Test?
QtQuick 2.4 is also included in Ubuntu.Components, buut that doesn't mean it exposes all QtQuick APIs... same applies here... haven't you noticed so far?
>
> 544 +import Ubuntu.Test 1.0
> 545 +import Ubuntu.Components 1.3
> 546 +import QtQuick.Layouts 1.1
>
> Are you using QtQuick.Layouts in the test?
Yes, you should read further...
| Zsombor Egri (zsombi) wrote : | # |
> 338 +
> 339 + /*!
> 340 + Specifies the preferred width of the column when the layout is
> initialized.
> 341 + Defaults to 0. Unless \l fillWidth is set, the value must be
> set. AdaptivePageLayout
> 342 + clamps the given value between \l minimumWidth and \l
> maximumWidth.
> 343 + */
> 344 + property real preferredWidth: 0
>
> It seems that it is not true that the value must be set, since in
> tst_adaptivepag
>
> 626 + layouts: PageColumnsLayout {
> 627 + id: defaultLayout
> 628 + when: layout.width >= units.gu(60)
> 629 + PageColumn {
> 630 + minimumWidth: units.gu(40)
> 631 + maximumWidth: units.gu(40)
> 632 + }
Right, reformulated.
| Zsombor Egri (zsombi) wrote : | # |
> > > 48 + // configure single column mode so we can only size
> it
> > to
> > > minimum 20 GU
> > > 49 + PageColumnsLayout {
> > > 50 + when: true
> > > 51 + PageColumn {
> > > 52 + minimumWidth: units.gu(20)
> > > 53 + fillWidth: true
> > > 54 + }
> > > 55
> > >
> > > I can resize the window to less than 20 GU. I don't know if we can do
> > anything
> > > about that in this MR.
> >
> > Yes, but if you check the content won't be sized less than 20GU. Btw, in the
> > original, the window content does';t size less than 40GU... So this actually
> > does something in this MR already!
>
> Right. And Christian has a fix for it already :) https:/
> /~ubuntu-
That's not enough! That one really fixes the app size to be less than 40GU. Which is not good.
- 1604. By Zsombor Egri on 2015-08-12
-
remove minimum and maximum constraints of the column
- 1605. By Zsombor Egri on 2015-08-12
-
typo
- 1606. By Zsombor Egri on 2015-08-12
-
specify column ordering
- 1607. By Zsombor Egri on 2015-08-12
-
specifying default
- 1608. By Zsombor Egri on 2015-08-12
-
specify unmet layout condition
- 1609. By Zsombor Egri on 2015-08-12
-
reformulate preferredWidth
- 1610. By Zsombor Egri on 2015-08-12
-
staging merge
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:1610
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Tim Peeters (tpeeters) wrote : | # |
/tmp/buildd/
Makefile:282: recipe for target 'generate_docs' failed
make[4]: *** [generate_docs] Error 1
make[4]: Leaving directory '/tmp/buildd/
Makefile:260: recipe for target 'html_docs' failed
make[3]: *** [html_docs] Error 2
- 1611. By Zsombor Egri on 2015-08-14
-
documentation failure fix
- 1612. By Zsombor Egri on 2015-08-14
-
staging sync
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:1612
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://

PASSED: Continuous integration, rev:1603 jenkins. qa.ubuntu. com/job/ ubuntu- sdk-team- ubuntu- ui-toolkit- staging- ci/2111/ jenkins. qa.ubuntu. com/job/ ubuntu- sdk-team- ubuntu- ui-toolkit- staging- vivid-amd64- ci/839 jenkins. qa.ubuntu. com/job/ ubuntu- sdk-team- ubuntu- ui-toolkit- staging- vivid-armhf- ci/841 jenkins. qa.ubuntu. com/job/ ubuntu- sdk-team- ubuntu- ui-toolkit- staging- vivid-armhf- ci/841/ artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ ubuntu- sdk-team- ubuntu- ui-toolkit- staging- vivid-i386- ci/838
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/ubuntu- sdk-team- ubuntu- ui-toolkit- staging- ci/2111/ rebuild
http://