| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === zoktar_ is now known as zoktar | ||
| === jussi01 is now known as jussi | ||
| nic-doffay | Saviq, sorted with the tests now cheers. Getting one concerning debug message upon running qmlscene though: file:///usr/lib/i386-linux-gnu/qt5/qml/QtTest/TestCase.qml:69: ReferenceError: qtest is not defined | 08:45 |
|---|---|---|
| nic-doffay | Any ideas? | 08:45 |
| Saviq | nic-doffay, that usually happens when you're not running under qmltestrunner | 08:45 |
| Saviq | nic-doffay, if it happens when you are, that's certainly weird | 08:45 |
| nic-doffay | Saviq, I'm trying to run just the infographics test qmltestrunner from the root with no luck. | 08:48 |
| nic-doffay | The import is working though. | 08:48 |
| Saviq | nic-doffay, is it in a branch somewhere? | 08:48 |
| nic-doffay | Nm sorted. | 08:48 |
| nic-doffay | Command line didn't pick up a mistake. | 08:49 |
| Saviq | k | 08:49 |
| nic-doffay | Saviq, should I first ensure that the Infographics test shows correctly with qmlscene before writing the tests? | 08:50 |
| Saviq | nic-doffay, if you look at some of the other tests (like tst_Stage.qml for example) | 08:50 |
| Saviq | nic-doffay, it's nice to have a way to run and control it with qmlscene | 08:50 |
| Saviq | nic-doffay, so that you can see what's happening | 08:50 |
| nic-doffay | Saviq, ok great. | 08:51 |
| Saviq | nic-doffay, you can run tst_Stage.qml both under qmlscene (and control manually) and qmltestrunner (and run the actual tests) | 08:51 |
| Saviq | nic-doffay, would be great to do the same for Infographics | 08:51 |
| nic-doffay | Saviq, that shouldn't be a problem. | 08:52 |
| === pete-woods1 is now known as pete-woods | ||
| === ubot5` is now known as ubot5 | ||
| MacSlow | Saviq, did you have a moment to look at https://code.launchpad.net/~macslow/unity/phablet-notification-renderer/+merge/155512 again... just waiting for the last "approved" to mark it ready for merging | 10:42 |
| Saviq | MacSlow, yeah, just about to get to it | 10:42 |
| MacSlow | ok | 10:42 |
| dednick | mzanetti_: ping | 10:48 |
| mzanetti_ | dednick: hey | 10:49 |
| Saviq | MacSlow, approved! | 10:52 |
| Saviq | MacSlow, you might want to have a look at https://code.launchpad.net/~saviq/unity-api/add-shell-notifications-api/+merge/163557 | 10:52 |
| Saviq | MacSlow, which is https://code.launchpad.net/~saviq/unity/phablet.notification-interface-tests/+merge/155914 "converted" to lp:unity-api - the separate project | 10:53 |
| Saviq | MacSlow, and actually made pass | 10:53 |
| MacSlow | Saviq, thanks... looking | 10:53 |
| MacSlow | Saviq, btw... working on making changes to a notification actually get through to the QML-side (backend-frontend merge work) | 10:55 |
| MacSlow | Saviq, that'll make two more regression test pass (append- and update-notification examples) | 10:56 |
| Saviq | MacSlow, cool | 10:56 |
| MacSlow | Saviq, confirmation notifications will "benefit" from this too of course | 10:56 |
| tsdgeos | Saviq: greyback: http://paste.kde.org/~tsdgeos/744926/ i think i found a sane enough test that shows how contentY is broken with lists with sections | 11:02 |
| greyback | tsdgeos: could you not use the flick() method of the ListView? | 11:04 |
| tsdgeos | flick sucks | 11:04 |
| tsdgeos | for some reason doesn't set moving to true | 11:04 |
| tsdgeos | which makes the "tryCompare(listView, "moving", false);" | 11:05 |
| tsdgeos | succed too early | 11:05 |
| greyback | I never quite understood moving vs flicking. I suspect moving only due to user interaction | 11:05 |
| tsdgeos | not according to docu | 11:05 |
| greyback | yeah, I know | 11:05 |
| Saviq | greyback, flicking is when you release your finger | 11:06 |
| Saviq | greyback, moving is ~ dragging | 11:06 |
| tsdgeos | Saviq: according to docu moving = dragging || flicking | 11:06 |
| Saviq | well, both are moving | 11:06 |
| Saviq | yeah | 11:06 |
| Saviq | that | 11:06 |
| tsdgeos | but then the flick() function doesn't set any | 11:06 |
| tsdgeos | anyway that's not what you should be looking at in the test :D | 11:06 |
| greyback | Saviq: yep, that's what I meant by "user interaction" | 11:06 |
| tsdgeos | it's the fact that listView.contentY = 0; | 11:07 |
| tsdgeos | // Make sure the list is on top | 11:07 |
| tsdgeos | tryCompare(listView, "contentY", 0); | 11:07 |
| tsdgeos | fails | 11:07 |
| greyback | tsdgeos: yeah, I know, but lots of mouseMoves doesn't always happen reliably. But for the point of your test, it will do | 11:07 |
| tsdgeos | which is imho totally braindead | 11:07 |
| greyback | Why do I suspect you'll be pointed to the docs: "It is not recommended to use contentX or contentY to position the view at a particular index. This is unreliable since removing items from the start of the list does not cause all other items to be repositioned, and because the actual start of the view can vary based on the size of the delegates." | 11:08 |
| === MacSlow is now known as MacSlow|lunch | ||
| greyback | even though yeah, that's not the point | 11:08 |
| Saviq | greyback, but we don't want to position at a particular index, do we? | 11:09 |
| Saviq | greyback, at least that's not the inherent issue? | 11:09 |
| greyback | Saviq: sure it isn't, but it implies they don't want you settings contentY at all. In that example they'd recommend positionViewAtBeginning() | 11:10 |
| Saviq | greyback, I didn't yet look at the example, but having a scrollbar on a listview must be somewhat supported... | 11:10 |
| greyback | Saviq: agreed | 11:10 |
| greyback | I wonder how it's done with the TableView QtQuickControl that was proposed... | 11:11 |
| tsdgeos | greyback: positionViewAtBeginning doesn't pass wither | 11:12 |
| greyback | tsdgeos: interesting | 11:12 |
| tsdgeos | you can try | 11:12 |
| greyback | (grrr, just switched to zsh. I've entered the qt5 repo, and it's scanning the whole thing just to show me a nice prompt) | 11:13 |
| tsdgeos | :D | 11:13 |
| greyback | nice idea, but think I'll disable that | 11:13 |
| Saviq | tsdgeos, hmm, listView.contentY = 0 won't always put the list at the top | 11:16 |
| Saviq | tsdgeos, that's what originY is supposed to compensate for, no? | 11:16 |
| Saviq | tsdgeos, but even so, setting it to 0 should get you to 0 | 11:17 |
| tsdgeos | Saviq: well, the fact is that it does put the list at the top | 11:17 |
| Saviq | tsdgeos, yeah I can see | 11:17 |
| tsdgeos | just that originY is 24 and contentY is 24 | 11:18 |
| greyback | tsdgeos: would originY = section header height? | 11:18 |
| tsdgeos | but that makes no sense | 11:18 |
| tsdgeos | since it is exactly in the same situation thatn at the beginning | 11:18 |
| tsdgeos | so i'd expect the values to be the same | 11:18 |
| tsdgeos | greyback: sure, but that's a bug imo | 11:19 |
| Saviq | tsdgeos, do you also sometimes get 80, sometimes 24 as the contentY value? | 11:19 |
| tsdgeos | mostly 24 | 11:19 |
| Saviq | tsdgeos, btw, originY always == contentY at the end of the test for me | 11:19 |
| tsdgeos | yes | 11:20 |
| Saviq | tsdgeos, so if you ask me | 11:20 |
| Saviq | tsdgeos, that's per design | 11:20 |
| Saviq | tsdgeos, in that contentY _can't_ get lower than originY | 11:20 |
| tsdgeos | sure | 11:20 |
| tsdgeos | but why is originY 24 ? | 11:20 |
| tsdgeos | because everythign is at the top | 11:20 |
| Saviq | because the creation / destruction of section headers made it so | 11:21 |
| Saviq | when one of the section headers was destroyed | 11:21 |
| tsdgeos | what's even funnier is this | 11:21 |
| tsdgeos | http://paste.kde.org/~tsdgeos/744938/ | 11:21 |
| tsdgeos | see what happens if you set contentY to 0 | 11:21 |
| tsdgeos | wait a bit | 11:22 |
| tsdgeos | and set it to 0 again | 11:22 |
| tsdgeos | jump! | 11:22 |
| tsdgeos | Saviq: you are saying you think it's ok the exact situation to be represented by two different values of originY? | 11:23 |
| Saviq | tsdgeos, yes | 11:23 |
| Saviq | tsdgeos, that's why there's both contentY and originY | 11:23 |
| tsdgeos | ok, explain the jump then :D | 11:23 |
| Saviq | tsdgeos, thing is with a ListView you should never ignore originY | 11:24 |
| tsdgeos | i'm not ignoring it | 11:25 |
| Saviq | tsdgeos, you shouldn't be setting contentY without taking originY into account | 11:25 |
| Saviq | tsdgeos, if you assumed that "0" is at originY | 11:25 |
| Saviq | which it is supposed to be | 11:25 |
| Saviq | the test would pass | 11:25 |
| tsdgeos | Saviq: what about the jump then? | 11:25 |
| === mmrazik is now known as mmrazik|afk | ||
| Saviq | tsdgeos, let me check something | 11:26 |
| tsdgeos | i mean, i can buy your argument that contentY will never be smaller than originY thus contentY==originY means at beginning even if they both are 123, but the example with the jump gets me a contentY of 0 and originY of 24 | 11:28 |
| tsdgeos | which makes no sense to me ether | 11:29 |
| tsdgeos | +i | 11:29 |
| Saviq | tsdgeos, so this works http://pastebin.ubuntu.com/5670470/ | 11:29 |
| Saviq | tsdgeos, and this works every other time http://pastebin.ubuntu.com/5670475/ | 11:32 |
| Saviq | tsdgeos, ok so... I take it back that contentY can't be lower than originY | 11:33 |
| Saviq | after all you can scroll it to negative values | 11:33 |
| Saviq | tsdgeos, so you should always be able to set it to 0 (and it should _get_ set to 0, even if that means scrolling beyond the beginning) | 11:34 |
| tsdgeos | agreed | 11:35 |
| Saviq | tsdgeos, the jump I'd explain with the fact that originY gets recalculated during the wait(1000) | 11:35 |
| tsdgeos | nah, originY sttays at 24 | 11:35 |
| tsdgeos | and yes, one of the qml guy is arguiing "you should never use contentY" | 11:35 |
| tsdgeos | well, make it readonly if so | 11:35 |
| Saviq | exactly | 11:35 |
| Saviq | and does that mean that scrollbars should stick to items? that's bollocks | 11:36 |
| Saviq | that's what happens in Friends now - and I hate it... | 11:36 |
| tsdgeos | scrollbyitem is retarded imho | 11:36 |
| Saviq | tsdgeos, so to my understanding http://pastebin.ubuntu.com/5670475/ should work | 11:37 |
| Saviq | tsdgeos, contentY == originY should mean that you're at the beginning | 11:38 |
| Saviq | and that's exactly what happens when you use ListView:;positionAtBeginning() | 11:38 |
| tsdgeos | ¡but it doesn't | 11:38 |
| Saviq | yup | 11:39 |
| tsdgeos | see how the first time you get only half of the crap | 11:39 |
| Saviq | yup | 11:39 |
| tsdgeos | and tbh i think that if we fix that | 11:39 |
| tsdgeos | my contentY will be fixed too | 11:39 |
| Saviq | and you should be able to set contentY to 0 when originY != 0, just as you can set it to negative | 11:39 |
| tsdgeos | it's just the same thing but looking at it from the other side | 11:39 |
| Saviq | tsdgeos, and I agree, too, that if contentY is never supposed to be used, then it should be readonly, but then there should at least be a scrollBy(real) | 11:40 |
| tsdgeos | so i'll try to get this fixed and then convince someone in Qt | 11:41 |
| tsdgeos | :D | 11:41 |
| Saviq | tsdgeos, cheers | 11:42 |
| greyback | yep, qtquickcontrols are setting the contentX/Y directly, nothing fancy. | 11:44 |
| tsdgeos | yep | 11:47 |
| tsdgeos | flickableItem.contentY = value | 11:47 |
| tsdgeos | thing is | 11:47 |
| tsdgeos | if you set the contentY "slowly" | 11:48 |
| tsdgeos | it'll work | 11:48 |
| tsdgeos | and you'll be able to reach 0 | 11:48 |
| tsdgeos | with everything being fine | 11:48 |
| tsdgeos | this is confusing | 11:49 |
| === _salem is now known as salem_ | ||
| tsdgeos | anyway, fooooood | 11:54 |
| === MacSlow|lunch is now known as MacSlow | ||
| === mzanetti_ is now known as mzanetti | ||
| === salem_ is now known as _salem | ||
| === greyback is now known as greyback|lunch | ||
| === mmrazik|afk is now known as mmrazik | ||
| nic-doffay | Saviq, what do I need to do to include LightDM in my qmlscene on command line? | 12:22 |
| Saviq | nic-doffay, -import builddir/plugins should do | 12:22 |
| Saviq | nic-doffay, actually | 12:22 |
| Saviq | -I builddir/plugins | 12:22 |
| Saviq | -import is for qmltestrunner | 12:22 |
| nic-doffay | Saviq, cheers! | 12:23 |
| === mzanetti is now known as mzanetti|lunch | ||
| paulliu | tsdgeos: when I do make testLensView, I got LensView.qml:42:21: TyoeError: Result of expression is not an object. | 12:27 |
| paulliu | tsdgeos: Is that normal? | 12:27 |
| paulliu | tsdgeos: I think it works before. But now I got empty categories from the fake Lens. | 12:28 |
| === dednick is now known as dednick|lunch | ||
| nic-doffay | Saviq, qmlscene -I builddir/tests/utils/modules -I builddir/plugins/ | 12:41 |
| nic-doffay | Not finding either Test or LightDM module. | 12:41 |
| Saviq | nic-doffay, they're both there, did you build recently? | 12:42 |
| Saviq | nic-doffay, and really, just add your test to tests/qmltests/CMakeLists.txt | 12:42 |
| nic-doffay | Saviq, I have already. | 12:43 |
| nic-doffay | A window isn't popping up though when I make it. | 12:43 |
| tsdgeos | paulliu: not sure what may have changed, can you try going back in teh history to see wehn that happened? | 12:43 |
| Saviq | nic-doffay, did you add it to the first list or to the second one? | 12:43 |
| Saviq | nic-doffay, you need to add them to the second list, the "qmlunittests" one is for non-graphical tests | 12:43 |
| Saviq | nic-doffay, drop it under "add_qml_test(Greeter Greeter ..." | 12:44 |
| nic-doffay | Saviq, second list. | 12:44 |
| Saviq | nic-doffay, branch? | 12:44 |
| nic-doffay | Saviq, lp:~unity-team/unity/infographics-with-lightdm | 12:46 |
| paulliu | tsdgeos: ok, let me check. | 12:46 |
| Saviq | pete-woods, btw, "infographicmodel.cpp:0: Note: No relevant classes found. No output generated." | 12:47 |
| Saviq | pete-woods, you don't need the explicit #include for moc with CMAKE_AUTOMOC enabled, too | 12:47 |
| Saviq | nic-doffay, « qmlscene -I builddir/plugins/ -I builddir/tests/utils/modules/ tests/qmltests/Greeter/tst_Infographics.qml » works fine here | 12:49 |
| Saviq | nic-doffay, well, it runs, but http://pastebin.ubuntu.com/5670658/ | 12:49 |
| nic-doffay | Ok Saviq when I make the test should a scene be run too? | 12:50 |
| === mzanetti|lunch is now known as mzanetti | ||
| Saviq | nic-doffay, not getting your question? | 12:50 |
| Saviq | nic-doffay, ah when "make test..."? | 12:51 |
| nic-doffay | Saviq, yeah | 12:51 |
| Saviq | nic-doffay, yes, a window should be there | 12:51 |
| Saviq | nic-doffay, but it will close as soon as the test is done | 12:51 |
| nic-doffay | Saviq, ah I see. | 12:51 |
| Saviq | nic-doffay, so because it fails, it closes the window straight away, too | 12:51 |
| Saviq | <Saviq> pete-woods1, btw, "infographicmodel.cpp:0: Note: No relevant classes found. No output generated." | 12:55 |
| Saviq | <Saviq> pete-woods1, you don't need the explicit #include for moc with CMAKE_AUTOMOC enabled, too | 12:55 |
| * pete-woods1 pete-woods | 12:55 | |
| === Thijser is now known as thijser | ||
| === pete-woods1 is now known as pete-woods | ||
| pete-woods | whoops | 12:56 |
| pete-woods | Saviq: thanks | 12:56 |
| davidcalle | didrocks, ping | 12:56 |
| didrocks | davidcalle: pong | 12:57 |
| davidcalle | didrocks, ça va? :) | 12:57 |
| didrocks | ça va, pingomachine, mais ça va :) | 12:58 |
| didrocks | et toi? | 12:58 |
| davidcalle | didrocks, bien :) | 12:58 |
| davidcalle | didrocks, do you know the archive inclusion status of 100scopes? | 12:58 |
| === _salem is now known as salem_ | ||
| didrocks | davidcalle: what I told yesterday in the hangout, this is depending on everything to be in due to the autopilot change | 13:00 |
| didrocks | davidcalle: so 1-2 weeks | 13:00 |
| davidcalle | didrocks, I'm asking more specifically about the Universe inclusion and MIR for scopes themselves :) | 13:01 |
| didrocks | davidcalle: it's the same timeline, it's linked to it :) | 13:02 |
| dandrader | Saviq, about running the DirectionalDragArea example on the device: do you get the behavior I described. It's odd. I installed an event filter on the QCoreApplication instance and no input events come by at all if drags come from beyond left, right and top edges | 13:03 |
| dandrader | but they do work fine from the bottom border | 13:03 |
| Saviq | dandrader, if the shell is running behind it, yes | 13:04 |
| Saviq | dandrader, because the shell installs input filters | 13:04 |
| dandrader | Saviq, qml-phone-shell wasn't running | 13:04 |
| davidcalle | didrocks, ok. Anything special you need from me for that? Like a maintenance promise signed with my blood or something? :P | 13:04 |
| Saviq | dandrader, in that case you should get all the events from all edges | 13:04 |
| dandrader | Saviq, it's odd because that wasn't happening back in Oakland | 13:04 |
| dandrader | so I guess something changed in the meantime | 13:04 |
| dandrader | Saviq, do you also get this behavior? | 13:05 |
| Saviq | dandrader, checking | 13:06 |
| Saviq | dandrader, nope, qmlscene --fullscreen -I builddir/plugins/ tests/plugins/Ubuntu/Gestures/edgeDragExample.qml | 13:07 |
| === greyback|lunch is now known as greyback | ||
| Saviq | dandrader, and all the edges work fine | 13:07 |
| didrocks | dandrader: ahah, nothing yet, we will go to the MIR starting next week I guess :) | 13:08 |
| didrocks | davidcalle: ^ | 13:08 |
| didrocks | sorry dandrader ;) | 13:08 |
| davidcalle | didrocks, ok! | 13:08 |
| Saviq | didrocks, you need to fix your tab-completer ;) | 13:08 |
| didrocks | Saviq: you meant, my brain? :p | 13:08 |
| dandrader | Saviq, well, that's some good news. I will flash my phone with the latest-and-greatest | 13:09 |
| didrocks | I typed 2 characters! | 13:09 |
| didrocks | it wasn't enough :p | 13:09 |
| Saviq | didrocks, yeah, but that shouldn't have completed if ambiguous | 13:09 |
| dandrader | Saviq, it does if you use xchat for instance | 13:09 |
| dandrader | (my case) | 13:09 |
| Saviq | didrocks, dandrader xchat-gnome here | 13:09 |
| Saviq | da >> nothing | 13:09 |
| Saviq | well, a list of da* | 13:09 |
| Saviq | only dan >> / dav >> completes | 13:10 |
| dandrader | I'm old-school plain xchat | 13:10 |
| Saviq | dandrader, seems the false-negatives on a Nexus 10 have gone away, too | 13:11 |
| dandrader | Saviq, great. | 13:12 |
| Saviq | dandrader, and the "red stuck", too | 13:12 |
| didrocks | Saviq: yeah, here, it tries to be too smart :p | 13:14 |
| didrocks | Saviq: taking the latest/closest to the conversation on that chan | 13:15 |
| Saviq | didrocks, ah, nasty ;d | 13:15 |
| === olli_ is now known as olli | ||
| mzanetti | Saviq: so, who prepares the release now? should i? | 13:51 |
| Saviq | mzanetti, /me | 13:51 |
| mzanetti | ok | 13:51 |
| Saviq | /we should really release more often | 13:52 |
| Saviq | will try and release daily | 13:52 |
| sil2100 | pstolowski: ping | 13:53 |
| pstolowski | sil2100: pong | 13:53 |
| mzanetti | Wellark: hey ho | 13:55 |
| Wellark | mzanetti: ho, hey | 13:57 |
| === timchen1` is now known as timchen119 | ||
| Wellark | :) | 13:59 |
| Saviq | Cimi, should bottom swipe work now for revealing the Dash bar? | 14:01 |
| Cimi | no | 14:01 |
| Cimi | Saviq, there's a bug in the panel | 14:01 |
| sil2100 | tedg: ping | 14:01 |
| Saviq | Cimi, k | 14:01 |
| Cimi | Saviq, functionality currently disabled, if you removed the "locked: true" in DashBar.qml works | 14:01 |
| tedg | sil2100, Howdy | 14:02 |
| Cimi | (with a minor bug, on the SDK side) | 14:02 |
| nic-doffay | Saviq, any idea about this? https://pastebin.canonical.com/91097/ | 14:02 |
| sil2100 | tedg: hello! While browsing the autopilot test results for unity nux using the new hud, I noticed a small strange 'regression' | 14:03 |
| sil2100 | tedg: that sometimes when you type in a command, it appears in the results, you press enter and there is like an 0.5-1.0 second lag until the command gets actually executed | 14:03 |
| sil2100 | tedg: might happen only when the results are still updated | 14:04 |
| sil2100 | tedg: I don't remember that in the past - is that normal? Or should the action be instantenous? | 14:04 |
| tedg | sil2100, It should be "instant" but right now the Unity 7 compat layer isn't very ideal. We were actually just talking about that. | 14:05 |
| tedg | sil2100, The issue is that it's building a query each time, and thus init'ing the voice engine. | 14:05 |
| Saviq | mzanetti, https://code.launchpad.net/~saviq/unity/phablet.release-176/+merge/164192 | 14:08 |
| mzanetti | Saviq: on it | 14:08 |
| sil2100 | Oh | 14:08 |
| Saviq | nic-doffay, what about it? | 14:09 |
| sil2100 | tedg: is there even support for voice input in the unity nux compatibility layer? | 14:09 |
| nic-doffay | Saviq, apparently pete-woods sorted a fix out... | 14:09 |
| tedg | sil2100, There's no way to activate it, but if you sent a DBus command it would work. | 14:10 |
| dandrader | Saviq, about using enum classes. How do you envision the API on the QML side? Currently it's like "direction: DirectionalDragArea.Rightwards". You would prefer "direction: DirectionalDragArea.Direction.Rightwards"? | 14:11 |
| Saviq | dandrader, generally yeah, I prefer enums wrapped to avoid conflicts and misunderstanding | 14:12 |
| Saviq | dandrader, but it would really be "Direction.Rightwards" | 14:12 |
| Saviq | dandrader, or "WhateverNameYouImportedAs.Direction.Rightwards" | 14:12 |
| GuidoPallemans | I have a design Idea for unity-next/8, would this be the correct place to show it? | 14:13 |
| === pete-woods is now known as pete-woods|food | ||
| sil2100 | tedg: is there a way to get this 'lag' fixed here, or it's not worth it? Since I can modify the tests to not fail because of that | 14:14 |
| sil2100 | But this would mean we're ready to accept this problem | 14:14 |
| tedg | sil2100, I think that, for today, we should modify the test. But, we should look into ways to make HUD faster on Unity7. | 14:15 |
| tedg | sil2100, I'm not quite sure what the answer is going to be there, but it shouldn't block landing stuff. | 14:15 |
| dandrader | Saviq, I think the best way to avoid conflicts and misunderstanding is having it this way "direction: DirectionalDragArea.Rightwards" | 14:16 |
| sil2100 | tedg: ok, I'll maybe fill in a quick bug about it, fix the tests but maybe attach the bug number to the workarounds I made | 14:17 |
| dandrader | Saviq, so you known that value belongs to DirectionalDragArea context | 14:17 |
| sil2100 | So that we won't loose scope of this one | 14:17 |
| sil2100 | tedg: thanks! | 14:17 |
| kgunn | GuidoPallemans: show away | 14:17 |
| Saviq | dandrader, only problem is when you grow a bunch of enums on DirectionalDragArea (sure, maybe not a problem here) | 14:17 |
| Saviq | dandrader, you start mixing them up | 14:18 |
| Saviq | dandrader, not only because I'm used to adding "Invalid" as the first enum | 14:18 |
| dandrader | Saviq, just "Direction.Rightwards" you don't know where that Direction comes from unless you import it with with a prefix, in which case you end up with long names | 14:18 |
| GuidoPallemans | Idea: http://paste.ubuntu.com/5670932/plain/ | 14:18 |
| Saviq | dandrader, but also, because named imports are recommended | 14:18 |
| Saviq | dandrader, it should always be "DDA.Direction.Rightwards" | 14:19 |
| dandrader | argh | 14:19 |
| dandrader | IMHO named imports are a last resort of avoiding naming clashes | 14:19 |
| dandrader | they just unnecessarily bloat names | 14:20 |
| dandrader | reducing readability | 14:20 |
| Saviq | dandrader, DirectionalDragArea.Rightwards is not long? ;) | 14:20 |
| kgunn | GuidoPallemans: will pass on to design folks | 14:20 |
| GuidoPallemans | thanks! | 14:21 |
| dandrader | Saviq, well, that's the name of the class | 14:21 |
| Saviq | dandrader, but really the most important thing is enum clashes within the same class | 14:21 |
| Saviq | dandrader, we'd need to prefix them to be "DirectionRightwards" etc. to prevent clashes | 14:21 |
| Saviq | so the net result would be DirectionalDragArea.DirectionRightwards | 14:22 |
| dandrader | Saviq, the "wards" ending already does the trick | 14:22 |
| Saviq | vs. DDA.Direction.Rightwards | 14:22 |
| Saviq | dandrader, sounds like one more flame war | 14:22 |
| dandrader | Saviq, as with coding style, it's a subjective matter | 14:23 |
| Saviq | dandrader, I lean towards named imports and wrapped enums ;) | 14:23 |
| kgunn | MacSlow: btw, meant to tell you...streaming music app was pretty cool | 14:23 |
| kgunn | too bad it was created at the expense of riding the motorcycle | 14:23 |
| MacSlow | kgunn, yeah... still raining here | 14:23 |
| MacSlow | kgunn, not very typical for May around here | 14:24 |
| Saviq | dandrader, but I'm not religious, might get converted | 14:24 |
| dandrader | Saviq, you know that named imports are getting in the way when you have to shorten then with cryptic acronyms | 14:24 |
| dandrader | whose meaning can only be understood by having a look at their definitions | 14:24 |
| Saviq | dandrader, it's just namespaces | 14:25 |
| Saviq | dandrader, and the cryptic acronyms can be made better | 14:25 |
| nic-doffay | mzanetti, any suggestions on what you think should be tested with the infographics? | 14:26 |
| Saviq | dandrader, how would you go about unclashing invalid direction vs. invalid something else in a single class, then? | 14:26 |
| mzanetti | nic-doffay: would need to check the code again. give me a minute | 14:26 |
| dandrader | it's a named entity, like variables, methods, classes, etc. The naming concerns apply to it just as well (understandability, concise, etc) | 14:26 |
| dandrader | Saviq, ^ | 14:26 |
| Saviq | Rightwards, Leftwards, DirectionInvalid? | 14:27 |
| nic-doffay | cheers mzanetti | 14:27 |
| dandrader | Saviq, I would do it like in your example | 14:28 |
| mzanetti | nic-doffay: Dot.qml: set different states and check if status eventually goes to Image.Ready when you give a correct state string | 14:28 |
| mzanetti | nic-doffay: no Idea how one would test something like Circle.qml... Did you by any chance came across something like testing shaders in your previous job? would be interesting to know if/how that is possible. | 14:30 |
| nic-doffay | mzanetti, this is the first company I've been in that tests at all! | 14:30 |
| Saviq | dandrader, I agree that having to wrap enums in a separate QObject class to expose them like I wanted to is awkward, so here's definitely one argument against | 14:31 |
| MacSlow | kgunn, there are big plans still in the pipe for the DigitallyImported client... but that has to wait for more rainy weekends :) | 14:31 |
| nic-doffay | mzanetti, should I use the onStatusChanged to check for the image? | 14:31 |
| mzanetti | nic-doffay: I'd say a tryCompare() would do | 14:31 |
| nic-doffay | mzanetti, I imagine testing shaders you'd just plug in different uniforms. | 14:32 |
| kgunn | MacSlow: :) | 14:32 |
| nic-doffay | Not much else you can do. | 14:32 |
| Saviq | dandrader, care for a flamewar on unityuiteam@lists...? ;) | 14:32 |
| mzanetti | nic-doffay: Infographics.qml: set a model and verify some of the dots reflecting data in the model | 14:32 |
| dandrader | Saviq, I have a trump car in my favor: that's how Qt does it :D | 14:32 |
| kgunn | katie: so for indicator access from "lock screen"/greeter, i noticed you left a note 2 days ago | 14:32 |
| dandrader | s/car/card | 14:33 |
| mzanetti | nic-doffay: well, just feeding a shader with stuff wouldn't be enough. you need a way to verify if it actually does the expected things | 14:33 |
| kgunn | should we make it so sliding is the only means of access ? | 14:33 |
| Saviq | dandrader, yeah, and you never know what the freakin' enum is for ;) | 14:33 |
| kgunn | dednick|lunch: ^ | 14:33 |
| === dednick|lunch is now known as dednick | ||
| kgunn | dednick: maybe you guys already spoke (luxury of co-location :) | 14:34 |
| kgunn | katie: dednick just trying to get to the point of resolution, i keep promising we're going to enable this :) | 14:36 |
| dednick | kgunn: no, we haven't talked about it. havent been into the office. | 14:36 |
| kgunn | katie: maybe we could enable as dednick's change (w/ single tap) | 14:36 |
| kgunn | and then work on a hint afterwards ? | 14:37 |
| kgunn | this way we make some progress | 14:37 |
| katie | kgunn, yes I left a comment | 14:38 |
| dednick | kgunn, katie: we have this document for interaction updates. https://docs.google.com/a/canonical.com/document/d/1iXhf9CpfGncAVc8zKDnq7fpFCyLOntefF7LatmBdZsw/edit#heading=h.5xqn14xtq4u2 | 14:39 |
| nic-doffay | mzanetti, I'm not aware of any shader testing traditions since shaders are usually pretty small. | 14:39 |
| dednick | katie: can we get validation on the indicator hint tap and amend point 2 of that document. | 14:40 |
| dednick | kgunn: i think it should be ok to merge my branch and once i get to the interaction updates make the required changes. | 14:41 |
| kgunn | dednick: cool, help | 14:41 |
| kgunn | 's keep my promises :) | 14:41 |
| katie | dednick, sure, let me just talk to Mika about it | 14:43 |
| dednick | katie: ta | 14:43 |
| dednick | tsdgeos, Saviq: could either of you? https://code.launchpad.net/~nick-dedekind/unity/phablet-greeter-indicators/+merge/157330 | 14:46 |
| Saviq | dednick, do what? approve? is it design-approved like this, then? | 14:47 |
| dednick | Saviq: review/approve. The open in greeter is as per design. The tap design will change slightly, but is part of another iteration. | 14:49 |
| Saviq | dednick, ok | 14:50 |
| dednick | Saviq: thanks | 14:50 |
| kgunn | tsdgeos: ping | 14:56 |
| tsdgeos | kgunn: hi | 14:56 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| katie | dednick, mika is changing the document now.. does it make sense? | 15:16 |
| nic-doffay | mzanetti, I was attempting to reference an alias which apparently is wrong, however an alias in tst_PageHeader appears to reference an alias in PageHeader. Any ideas? | 15:16 |
| nic-doffay | line 33 in tst_PageHeader. | 15:16 |
| nic-doffay | references line 31 in PageHeader... | 15:17 |
| dednick | katie: yes. thanks | 15:17 |
| mzanetti | nic-doffay: can you show me the code that doesn't work? | 15:18 |
| dednick | katie: although some more detail would help. ie how long we want it to hint for. | 15:19 |
| nic-doffay | https://pastebin.canonical.com/91128/ line 12 mzanetti | 15:19 |
| katie | dednick, fair enough! I'll get some more detail in there for ya :) | 15:19 |
| dednick | katie: thanks :) | 15:20 |
| mzanetti | nic-doffay: you can't access internal things | 15:20 |
| mzanetti | nic-doffay: only the public properties of Infographics can be referenced directly | 15:20 |
| mzanetti | nic-doffay: think of "public:" and "private:" in C++ terms | 15:20 |
| mzanetti | nic-doffay: only those properties in the top-level item are public | 15:21 |
| mzanetti | nic-doffay: anyways, you can still access them for testing: | 15:21 |
| === pete-woods|food is now known as pete-woods | ||
| mzanetti | nic-doffay: open Infographics.qml and go to line 430 | 15:23 |
| mzanetti | nic-doffay: add this: | 15:23 |
| mzanetti | objectName: "dots" | 15:23 |
| mzanetti | in your test you can do this: | 15:23 |
| mzanetti | var dots = findChild(infographic, "dots") | 15:23 |
| mzanetti | nic-doffay: ^ | 15:23 |
| nic-doffay | mzanetti, line 430? | 15:23 |
| mzanetti | nic-doffay: sorry... line 430 in this diff: https://code.launchpad.net/~unity-team/unity/infographics-with-lightdm/+merge/163783 | 15:24 |
| nic-doffay | mzanetti, handy thanks! | 15:24 |
| dandrader | Saviq, another thing against standalone enum objects is that they should make sense and be generally useful in the entire namespace where they live. Whereas an enum that lives inside a class has to make sense just for that class. In other words: keep it in the scope where it's used. | 15:33 |
| cyphermox | thomi: can you or someone in your team look into the autopilot functional tests currently failing for daily release? | 15:49 |
| cyphermox | sil2100: ^ so you know... | 15:49 |
| cyphermox | http://10.97.0.1:8080/job/ps-generic-autopilot-release-testing/392/testReport/ | 15:49 |
| thomi | cyphermox: they're not fixed yet? sure | 15:50 |
| thomi | cyphermox: also, join #ubuntu-autopilot :) | 15:50 |
| cyphermox | I don't know, perhaps it just needs to be rerun, but that was running last night | 15:50 |
| thomi | cyphermox: late last night I fixed all the tests, and asked didrocks to re-run the stack, but maybe he didn't get around to it | 15:50 |
| thomi | cyphermox: but those results are old :) | 15:50 |
| didrocks | thomi: saw my mail? | 15:51 |
| cyphermox | alright then :) | 15:51 |
| didrocks | thomi: your fix didn't merge | 15:51 |
| thomi | didrocks: awwwww :( | 15:51 |
| thomi | let me work out why | 15:51 |
| cyphermox | didrocks: I'll pick this back up | 15:51 |
| didrocks | :) | 15:51 |
| didrocks | thanks :) | 15:51 |
| * thomi moves conversation to #ubuntu-autopilot | 15:51 | |
| * didrocks is away for now | 15:51 | |
| nic-doffay | mzanetti, have another moment? | 15:52 |
| mzanetti | nic-doffay: ofc | 15:54 |
| Saviq | dandrader, like Qt.*? ;) | 15:55 |
| mzanetti | evil :D | 15:55 |
| nic-doffay | mzanetti, line 446 in the diff. | 15:55 |
| nic-doffay | I've accessed the children in the dots which are CirclePositioners. | 15:55 |
| nic-doffay | What would be the best method to now access the dot. | 15:56 |
| mzanetti | nic-doffay: can you show what you have now please | 15:57 |
| nic-doffay | mzanetti, https://pastebin.canonical.com/91144/ | 15:58 |
| mzanetti | nic-doffay: ok... now I understand... sorry... | 15:59 |
| nic-doffay | mzanetti, no prob | 15:59 |
| mzanetti | nic-doffay: so: you add an objectName to the Dot {} | 15:59 |
| mzanetti | nic-doffay: something like this: | 15:59 |
| mzanetti | objectName: "dot" + index | 16:00 |
| nic-doffay | mzanetti, right so this would be the best way to externally reference anything at any time. | 16:00 |
| mzanetti | nic-doffay: then you can findChild("dot1"), findChild("dot5") etc | 16:00 |
| mzanetti | nic-doffay: does that help you? | 16:01 |
| nic-doffay | mzanetti, could I just do that from the parent? | 16:01 |
| mzanetti | yeah. I think so | 16:01 |
| mzanetti | one sec | 16:01 |
| nic-doffay | mzanetti, the algorithm is recursive | 16:01 |
| nic-doffay | It won't encounter other hidden QML dangers would it? | 16:02 |
| mzanetti | nic-doffay: shouldn't... but not entirely sure... could be that Animations and Transitions mess things up | 16:02 |
| mzanetti | nic-doffay: anyways, you can access children by using dots.itemAt(x).children[0] | 16:03 |
| mzanetti | that would give you the Dot of CirclePositioner with index x | 16:03 |
| mzanetti | nic-doffay: ^ | 16:03 |
| mzanetti | nic-doffay: check out the implementation of findChild() in tests/qmltests/UnityTestCase.qml | 16:04 |
| nic-doffay | mzanetti, yeah I had a look at it. | 16:04 |
| nic-doffay | mzanetti, I'll try not doing too many tricks. | 16:04 |
| === chrisccoulson is now known as firefox-is-aweso | ||
| === firefox-is-aweso is now known as chrisccoulson | ||
| mzanetti | nic-doffay: imho using Dot { objectName: "dot" + index } and using findChild() would be the cleanest | 16:05 |
| nic-doffay | mzanetti, yeah that's what I'm sticking with atm. | 16:05 |
| nic-doffay | mzanetti, cheers! | 16:05 |
| mzanetti | yw | 16:06 |
| sil2100 | cyphermox: I'm looking into that | 16:15 |
| sil2100 | cyphermox: I sent an e-mail to thomi yesterday and he fixed those problems, but the merge is not merging properly - looking into that | 16:16 |
| thomi | sil2100: should be mergable now | 16:18 |
| thomi | sil2100: I forgot to commit my last changes :-/ | 16:19 |
| dednick | Saviq: ping | 16:21 |
| sil2100 | Ah ;) | 16:21 |
| sil2100 | thomi: awesome, thanks! | 16:22 |
| sil2100 | cyphermox: did you fire a QA stack re-build? | 16:22 |
| sil2100 | I can't wait to see the results | 16:22 |
| dednick | omg. nautilus is kicking my arse with this new search behaviour! | 16:30 |
| nic-doffay | dednick, what's different? | 16:33 |
| dednick | seems to be doing a recursive search. | 16:34 |
| nic-doffay | mzanetti, https://pastebin.canonical.com/91156/ | 16:34 |
| nic-doffay | Here's what I'm testing in the dot at the moment. Any further comments or suggestions? | 16:34 |
| dednick | anyone having trouble with unity-lens-mock on desktop? i'm getting a python error. http://pastebin.ubuntu.com/5671314/ | 16:36 |
| dednick | on raring | 16:37 |
| katie | dednick, vesar is doing a prototype for the indicator hint. perhaps talk to him or mesq for more details... | 16:40 |
| dednick | katie: ok. thanks | 16:40 |
| sil2100 | kenvandine, cyphermox, didrocks: we're commencing the merge-in of scope's into trunks | 16:41 |
| sil2100 | The branch that switches 100scopes in cu2d-config is ready since a week | 16:42 |
| sil2100 | So I'm handling this one | 16:42 |
| kenvandine | sil2100, great | 16:42 |
| sil2100 | kenvandine: pstolowski and me just landed libunity elements | 16:43 |
| Saviq | dednick, pong | 16:46 |
| mzanetti | nic-doffay: looks good. you could use a _data() function and test all existing states | 16:46 |
| dednick | Saviq: have you noticed any problems with mock lenses on desktop? unity-lens-mock doesnt work for me. | 16:47 |
| dednick | but works on phone | 16:47 |
| nic-doffay | mzanetti, cool. I'll also add checks for the other states. | 16:47 |
| Saviq | dednick, works here on raring, maybe you have some smart scope-y things around? | 16:47 |
| Saviq | dednick, and how does nautilus "kick your arse" with the search? | 16:48 |
| dednick | Saviq: possible i guess. but dont think so. | 16:48 |
| Saviq | dednick, I'm still not sure I like it better than the usual type-ahead, but it does work, and relatively quick, too | 16:48 |
| dednick | dednick: returning multiple results for python2.7 in the /usr/lib folder. :) dont know which one to open! | 16:49 |
| Saviq | slightly too disruptive, though | 16:49 |
| Saviq | dednick, talkin' to yourself, eh? you sure the cold is through? | 16:49 |
| dednick | i think there was a bug when using it earlier though. It didnt seem to update the current search folder when i changed folders. was still searching home folder when i was in /usr/lib. | 16:50 |
| dednick | Saviq: hehe. maybe the cold meds is making me hallucinate. | 16:50 |
| dednick | (more than usual) | 16:50 |
| Saviq | ;d | 16:51 |
| === dandrader is now known as dandrader|lunch | ||
| === mmrazik is now known as mmrazik|afk | ||
| mdeslaur | #ubuntu-uds-foundations-1 | 18:01 |
| mdeslaur | gah, wrong window | 18:01 |
| === dandrader|lunch is now known as dandrader | ||
| === mmrazik|afk is now known as mmrazik | ||
| gatox | hi, i'm having some problems when trying to execute unity-next in the desktop: http://paste.ubuntu.com/5671882/ | 19:47 |
| gatox | i'm following the steps in the CODING file, but it doesn't seem to work, and about the people lens, the doc mention this step: | 19:48 |
| gatox | run the People lens daemon | 19:48 |
| gatox | -------------------------- | 19:48 |
| gatox | $ ~/unity/unity_build/libexec/unity-people-daemon | 19:48 |
| gatox | but that part is not being build | 19:48 |
| gatox | any ideas/help? | 19:48 |
| sergiusens | Saviq: ^^ | 19:51 |
| kgunn | gatox: so the unity build is busted ? | 20:05 |
| kgunn | not unitynext...but the orig unity | 20:05 |
| kgunn | gatox: just curious....from unity-next dir | 20:07 |
| gatox | kgunn, what?? i've just build unity-next, but when i try to execute ./run the window with the phone shell open, but after a couple of seconds it dies with a segfault | 20:07 |
| kgunn | run ./build_unity -u & then ./build_unity -c | 20:07 |
| gatox | ack | 20:07 |
| kgunn | which updated & cleanly builds the original unity bits that unitynext still relies on | 20:08 |
| gatox | kgunn, ack, i'll do that right now | 20:08 |
| kgunn | gatox: sorry...major window swap distractions.... :) i may seem incoherent (more than usual) | 20:08 |
| === dandrader_ is now known as dandrader|afk | ||
| gatox | kgunn, nop.... same problem | 20:12 |
| gatox | kgunn, http://paste.ubuntu.com/5671995/ | 20:13 |
| kgunn | gatox: oops should've looked a bit closer | 20:14 |
| kgunn | looks like a Qt version incompatibility issue | 20:14 |
| kgunn | might run apt-get dist-upgrade | 20:15 |
| kgunn | (also keep an eye out for old ppa's) | 20:15 |
| gatox | kgunn, ack..... will check | 20:17 |
| kgunn | gatox: i'm trying in // | 20:18 |
| gatox | kgunn, it's upgrading | 20:20 |
| gatox | kgunn, there was several qt stuff to upgrade.... i thought i did it this morning | 20:21 |
| kgunn | gatox: hope that fixes it... | 20:22 |
| kgunn | i just built from scratch and it seems ok (./run that is) | 20:22 |
| kgunn | gatox: side note....you don't even have to run the people daemon | 20:23 |
| kgunn | it'll complain | 20:23 |
| gatox | kgunn, ack, thx | 20:23 |
| kgunn | but it'll run | 20:23 |
| === dandrader|afk is now known as dandrader | ||
| gatox | kgunn, now it's working, what a silly mistake.... sorry :P | 20:27 |
| gatox | kgunn, thanks | 20:27 |
| kgunn | gatox: no worries....i am 10x worse trust me :) | 20:28 |
| tedg | bregma, So I just got a VM to put Unity under and upstart job. Basically, started by upstart instead of gnome-session. Thoughts on doing that in saucy? | 20:31 |
| tedg | s/and/an/ | 20:31 |
| bregma | tedg, you mean you're running compiz as an upstart job? | 20:33 |
| tedg | bregma, Yes, and removing it from the gnome-session config for the ubuntu session. | 20:34 |
| bregma | do an MP and we'll test it | 20:35 |
| tedg | Unfortunately it requires a gnome-session MP and a Unity one. | 20:35 |
| tedg | So it'll be a bit tricky to put in a single one. | 20:35 |
| tedg | But I guess I can just put instructions in. | 20:35 |
| bregma | how will that affect g-s-d and all that other wonderful stuff? | 20:37 |
| tedg | That stuff still gets launched by gnome-session. Just gnome-session doesn't start the window manager. | 20:37 |
| bregma | but Unity wants g-s-d to be running, so is sequencing going to be an inssue? | 20:38 |
| tedg | Jobs that are interested can put a NoShowIn=ubuntu in /etc and then an upstart job. | 20:38 |
| tedg | Hmm, it worked :-) | 20:38 |
| tedg | Let me find out why ;-) | 20:38 |
| tedg | Ah, stgrabber had already converted it. | 20:39 |
| tedg | So no, not an issue. | 20:39 |
| tedg | bregma, Cool, I figured out how to make it safe :-) | 20:54 |
| tedg | Watching the Unity 8 in archive session. Very impressed the big wooden tunnel bregma works in. | 21:15 |
| bregma | that's the loft of my cosy log cabin in the woods | 21:16 |
| bregma | all wood all the time | 21:17 |
| ChrisTownsend | Is that an euphemism? | 21:18 |
| === salem_ is now known as _salem | ||
| eean | sil2100: what's the status of the appmenu plugin on Qt 5? do the 'menubar' plugins no longer work? it's a bit confusing in all the lp bugs. | 21:59 |
| sil2100 | eean: hi | 22:09 |
| eean | yo | 22:09 |
| sil2100 | eean: you mean the status in saucy, yes? | 22:09 |
| eean | I mean the status in stuff I can download and build :) | 22:09 |
| eean | I'm deploying an app with Qt 5.0.2. | 22:10 |
| sil2100 | heh ;) Well, if you run raring, the global appmenu for Qt 5 applications should work fine | 22:10 |
| sil2100 | Would have to check 5.0.2 though | 22:11 |
| eean | via the menubar plugin? | 22:11 |
| eean | so I'm shipping my own qt as well. do I need to patch vanilla Qt 5.0.2? | 22:11 |
| sil2100 | But the rule is, on raring it should 'just work', but on saucy the patches that were enabling the menu support got reverted, so currently there is no appmenu *yet*, but it's being worked on | 22:11 |
| sil2100 | Yes, sadly | 22:11 |
| eean | I don't use Ubuntu, I just deploy to users who do :) | 22:11 |
| eean | OK | 22:11 |
| sil2100 | eean: the thing is, the Qt5 appmenu plugin is a bit 'hacked up' | 22:12 |
| sil2100 | eean: the real support, which will not require any patching or whatsoever, will be released soon | 22:12 |
| sil2100 | For now, it requires patching Qt5 | 22:12 |
| eean | 'released' .... do you have the code sitting somewhere that I could build? :D | 22:13 |
| sil2100 | Not yet! But just give me some free time to be able to finish my tests ;) | 22:14 |
| eean | cool. | 22:14 |
| eean | should I bother recompiling qt 5 with the patches or will it be ready soon enough anyways? | 22:15 |
| eean | my users are live with in-window menus for a bit ;) | 22:15 |
| eean | my users *can live | 22:15 |
| sil2100 | Let's define 'soon enough' ;p | 22:16 |
| * sil2100 hides | 22:16 | |
| eean | a couple weeks | 22:16 |
| eean | I guess | 22:16 |
| sil2100 | Yes, I think this would be the case | 22:16 |
| eean | OK | 22:16 |
| eean | I'll watch lp then :) | 22:16 |
| sil2100 | eean: this depends on how smoothly all the daily-release-related stuff here goes, I'll give you a sign if I'll have to push things back so that your users won't have to wait like 10 weeks for something so trivial | 22:17 |
| eean | OK great | 22:17 |
| eean | the worst is gnome's gmenu which doesn't have a non-gtk public api. Qt apps are just out cold from having an app menu. but that's a problem for a different irc network. :) | 22:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!