=== _salem is now known as salem_ | ||
=== salem_ is now known as _salem | ||
zsombi_ | daker: it has been agreed that we won't provide more features to UITK 1.3, as it has been kept open for too long, and we need to move forward. That move is getting everything we can upstreamed, and move towards QQC2. Mixed checkbox status feature is there in QQC2, and it would be a new feature into UITK 1.3 which woudl require major refactoring of the component, which we don't want | 07:28 |
---|---|---|
mpt | kalikiana_, oh dear, I’d forgotten about that :-) | 08:12 |
=== JanC is now known as Guest13435 | ||
=== JanC_ is now known as JanC | ||
=== JamesTait is now known as Guest52630 | ||
=== Guest52630 is now known as JamesTait | ||
=== JamesTait is now known as Guest48538 | ||
=== Guest48538 is now known as JamesTait | ||
tsdgeos | easy one! https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/anchors_cant_be_null/+merge/318450 | 10:09 |
tsdgeos | kalikiana_: zsombi_: ↑ | 10:10 |
zsombi_ | tsdgeos: checking | 10:10 |
zsombi_ | tsdgeos: are there many things you guy sstill use from ListItems? | 10:11 |
tsdgeos | no clue | 10:12 |
tsdgeos | i guess yes | 10:12 |
tsdgeos | $ wcgrep Ubuntu.Components.ListItems | wc -l | 10:12 |
tsdgeos | 25 | 10:12 |
tsdgeos | not sure if all those imports are *really* needed | 10:12 |
zsombi_ | anyway... it'll stay in UITK1.3 as deprecated, just wanted to know how much effort would be to drop it... | 10:13 |
zsombi_ | tsdgeos: let's wait CI to finish it and then it can get into staging | 10:13 |
=== zsombi_ is now known as zsombi | ||
tsdgeos | zsombi: we can always copy the stuff over :D | 10:15 |
zsombi | LOL | 10:15 |
tsdgeos | i know we use ThinDivider "a lot" | 10:15 |
tsdgeos | not sure about the other stuff | 10:15 |
tsdgeos | zsombi: PageStack.push creates the pushed component synchronously? | 10:30 |
zsombi | tsdgeos: yes | 10:30 |
tsdgeos | k, tx | 10:32 |
tsdgeos | zsombi: how scared should i be about http://paste.ubuntu.com/24083574/ ? | 10:46 |
daker | zsombi: i see, i wasn't going to implement that, i was just wanted to add support for the label | 10:49 |
zsombi | tsdgeos: I don't think you should be scared :) | 10:51 |
zsombi | daker: label support is fine :) | 10:51 |
kalikiana_ | Hmm looking at that "new PropertyChange", it seems legit | 10:52 |
kalikiana_ | Once created, nothing keeps track of it | 10:52 |
tsdgeos | kalikiana_: i guess my question is more, is this something that happens once or is it something that happens "a lot" | 10:53 |
kalikiana_ | tsdgeos: A dozen times at startup perhaps | 10:57 |
kalikiana_ | Something like that | 10:57 |
tsdgeos | you sure? | 10:57 |
tsdgeos | wouldn't i get one per each pagestack thing? | 10:57 |
kalikiana_ | Okay, correction, two dozen | 10:58 |
kalikiana_ | Checked with the gallery | 10:58 |
kalikiana_ | No page open | 10:58 |
tsdgeos | how do you build the uitk with debug? | 10:59 |
tsdgeos | qmake CONFIG+=debug | 10:59 |
tsdgeos | doesn't seem to be working | 10:59 |
tsdgeos | and it works now | 10:59 |
tsdgeos | \o/ | 10:59 |
tsdgeos | just had to say here it didn't wokr | 11:00 |
kalikiana_ | tsdgeos: I just did it snappy style, using qDebug, and looked at the bindings created | 11:01 |
tsdgeos | ok | 11:01 |
kalikiana_ | zsombi: Would qDeleteAll be deleting the PropertyChange objects? The comment says "restore" which isn't really clear to me | 11:06 |
zsombi | kalikiana_: qDeleteAll applied delete on any container, so yes, it will | 11:07 |
zsombi | and PropertyChange does the restore | 11:07 |
zsombi | so yes :) | 11:07 |
kalikiana_ | zsombi: So restore here means if the bindings are deleting, the old values would be used? | 11:08 |
kalikiana_ | I think the wording just might be confusing me | 11:08 |
zsombi | kalikiana_: yep... pretty ambiguous :D | 11:08 |
tsdgeos | zsombi: kalikiana_: qDeleteAll is on m_propertyBackup, those PropertyChange are not stored there | 11:08 |
tsdgeos | kalikiana_: i just add that qDebug you mentioned, and i get them all the time i add a page, so basically "very important memory leak" | 11:09 |
zsombi | tsdgeos: where was this code? | 11:09 |
tsdgeos | zsombi: which code? | 11:09 |
zsombi | the one leaking | 11:09 |
zsombi | tsdgeos: in teh UCStyleHints? | 11:10 |
tsdgeos | ucstylehints.cpp:251 | 11:10 |
tsdgeos | yes | 11:10 |
* zsombi was wondering as we have two places with PropertyChanges | 11:10 | |
kalikiana_ | tsdgeos: That's what I'm trying to verify (if they are in the list). Different variables with the name "change" are used it seems | 11:10 |
zsombi | let me get an eye on it as well | 11:10 |
kalikiana_ | And the later one isn't added to the list | 11:10 |
tsdgeos | yeah the second one is not on the list | 11:10 |
tsdgeos | should it be, no idea :D | 11:11 |
kalikiana_ | I think it should | 11:11 |
kalikiana_ | tsdgeos: Although I might wonder, if they aren't added, shouldn't there be visual artifacts | 11:11 |
kalikiana_ | But it could be something very subtle as well, if it's overriden anyway | 11:11 |
kalikiana_ | You wouldn't see it unless you're actually changing the style/theme | 11:12 |
zsombi | hmm... | 11:14 |
tsdgeos | kalikiana_: my understanding is that they're "lost in space" | 11:15 |
tsdgeos | since i delete the page they applied to | 11:16 |
tsdgeos | so they don't cause errors | 11:16 |
tsdgeos | but they cause memory to grow | 11:16 |
tsdgeos | bus, bbl | 11:16 |
kalikiana_ | tsdgeos: If the page is deleted, sure. What I meant is, it could also be relevant to changing styles, but it's far less common | 11:20 |
kalikiana_ | But I think we agree we'll want to add it to the list | 11:21 |
tsdgeos | kalikiana_: zsombi: adding the "m_propertyBackup << change;" to the second branch fixes the leak, no idea if it's the correct thing to do though, want a MR? | 11:51 |
zsombi | tsdgeos: drop one, I'll check it!! | 12:29 |
kalikiana_ | +1 | 12:36 |
daker | zsombi: when you say move towards QQC2, what do you mean by that ? | 12:53 |
daker | rewrite the sdk with QQC2 as a base ? | 12:54 |
zsombi | daker: I mean we are planning to get QQC2 controls based UITK2.0 so we provide a QQC2 style module where we put all Ubuntu specific things | 12:54 |
daker | i see | 12:54 |
tsdgeos | kalikiana_: zsombi: https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/fix_ucstylehints_leak/+merge/318478 | 13:36 |
zsombi | tsdgeos: taking it | 13:36 |
zsombi | tsdgeos: dohh :D | 13:42 |
zsombi | just checked the context the change wasn;t pushed into the container... o m f g... | 13:44 |
zsombi | what a horrible mistake... | 13:45 |
zsombi | tsdgeos: thanks for fixing that!!!! | 13:45 |
Mirv | tsdgeos: fixing bits on top of Qt 5.6.2 seems better but still not there - https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2519/+packages (amd64, i386, armhf just symbol changes). qml-test:item-grabber failing on (32-bit) powerpc and s390x. staring at http://code.qt.io/cgit/qt/qtdeclarative.git/log/?h=5.6 (5.6.2 tag on the next page), can you think of anything besides the three already | 13:47 |
Mirv | added to try? | 13:47 |
Mirv | we now have the data point that 5.7.1 worked on all archs, which is nice | 13:49 |
tsdgeos | Mirv: i take 5.6.1 worked? | 13:50 |
Mirv | yes, and 5.6.2 without those patches | 13:51 |
tsdgeos | Mirv: which patches? | 13:51 |
Mirv | tsdgeos: those in the silo, to fix V4 address bit use | 13:51 |
Mirv | actually, scratch that. I now remember and see that Debian decided to make the failures non-fatal | 13:53 |
tsdgeos | i don't see why itemgrabber would fail | 13:53 |
tsdgeos | can you point me at the patches exactly? | 13:53 |
tsdgeos | i can't seem to get them from https://bileto.ubuntu.com/#/ticket/2519 | 13:53 |
Mirv | tsdgeos: so actually I think this is not a regression | 13:53 |
Mirv | just me enabling more tests than Debian now | 13:54 |
Mirv | tsdgeos: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2519/+sourcepub/7517250/+listing-archive-extra but those are not related, sorry | 13:54 |
Mirv | but as usual it's good to open one's mouth and one sees more than before | 13:54 |
tsdgeos | ok :) | 13:54 |
tsdgeos | no worries | 13:55 |
Mirv | so yes this is definitely better that it was on top of 5.6.1 | 13:55 |
=== tedg_ is now known as tedg | ||
kalikiana_ | zsombi: That was what we were discussing earlier. The re-use of variables makes it less obvious. Although I don't have a specific idea on how to improve it atm. | 14:58 |
kalikiana_ | But for now it's good we found the leak. | 14:59 |
zsombi | kalikiana_: the biiiiig mistake was that in the loop the change wasn't pushed into the container, whereas in the previous one it was... | 14:59 |
kalikiana_ | zsombi: Yes. And if you just casually go through the code, you will see "aha, it's in there" because the variable has the same name. | 15:00 |
kalikiana_ | daker: Regarding the checkbox. I don't think we want to have any new API here, specifically the checkedState. We don't implement tri-state and if you need that, I'd like you to consider QQC2 for that instead. | 16:07 |
daker | kalikiana_: sure, i'll revert that, first i'll fix the label positionning, then we can discuss how to implement that using QQC2 | 16:09 |
kalikiana_ | Oaky | 16:15 |
kalikiana_ | daker: I commented on the MR https://code.launchpad.net/~daker/ubuntu-ui-toolkit/fix.1333228/+merge/318311 | 16:37 |
daker | kalikiana_: yes, i still didn't finish work on that one, when using \n lineCount is always 1 and the label doesn't wrap correctly | 16:40 |
kalikiana_ | No rush. I just find it useful to document the current state in case others are looking at the branch and wondering if you're waiting for review. | 16:41 |
kalikiana_ | You might want to mark it as "Work in progress" if you didn't want any review | 16:42 |
daker | kalikiana_: thanks | 16:44 |
daker | kalikiana_: what branch should i use to propose a QQC2 checkbox style module ? | 18:43 |
kalikiana_ | daker: https://github.com/CanonicalLtd/uitk2/tree/dev | 18:44 |
daker | kalikiana_: ok | 18:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!