=== JanC is now known as Guest21659
=== JanC_ is now known as JanC
=== benonsoftware is now known as Guest30663
[06:42] <ShR3K> Is there any process about how to compile unity8 with ubuntu sdk ide. I have problem when I want to open the project with CMakeLists.txt
[06:45] <Saviq> ShR3K, can you paste the errors please?
[06:46] <Saviq> (on pastebin)
=== \b is now known as benonsoftware
[06:52] <ShR3K_> saviq : http://pastebin.com/z6H62fZD
[06:54] <ShR3K> I have no argument, my generator is the generic Unix desktop and this happen when I click on "Execute CMake"
[07:00] <Saviq> Shr3K that file should be generated by cmake... did you try running ./build.sh -s; ./build.sh in the trunk checkout?
[07:08] <ShR3K> Saviq, Ok I'm doing it. But is it the same process to compile it for armhf devices ?
[07:09] <ShR3K> Saviq, ./build.sh -c and Execute CMake on ubuntu sdk ide
[07:10] <Saviq> Shr3K, right, I misguided you last night, didn't know you were building unity8 for the phone
[07:11] <Saviq> Shr3K in that case the most tried is using sbuild https://wiki.ubuntu.com/SimpleSbuild or libertine to build on the device
[07:13] <Saviq> biab
[07:13] <ShR3K> Saviq, Sorry for this confusion. I'll test it and I'll be back later probably
[07:45] <tsdgeos> Saviq: the yakkety builds fail because of python3 regression?
[07:59] <Saviq> tsdgeos, more like I fooked something in my scripts, checking
[08:00] <Saviq> ah d'oh
[08:00] <Saviq> that's what you get for editing the jobs manually ;P
[08:00] <Saviq> tsdgeos, will be good now
[08:00]  * Saviq restarts
[08:00] <tsdgeos> oki
[10:12] <salty-horse> hey. does Unity require a .desktop file for an application to have an icon? I have an SDL2 program that sets an icon. it shows up in metacity, but unity only shows a default question mark icon.
[10:18] <Saviq> salty-horse, yes, AFAIK it's required for names, descriptions, icons etc.
[10:18] <salty-horse> any particular reason for not supporting it like metacity? (and perhaps other WM's. haven't tested others yet)
[10:21] <Saviq> salty-horse, likely because it's just better UX to have a better icon than X can pass through (scalable, for example) and then there's translations etc.
[10:21] <Saviq> and that's the only way to have the icon when the app's not running
[10:21] <Saviq> basically, .desktop file better, and it's less code to maintain to not fall back to the X11-provided one
[10:30] <salty-horse> Saviq, still a bit of a bummer. btw, I have a bug to report about icons set with SDL 1.2 that do show up, but wrong. for now, here's a teaser: <https://i.imgur.com/7IJwrsm.png> shows up as <https://i.imgur.com/qR8fpjt.png>
[10:31] <Saviq> salty-horse, it's not like a .desktop file is something difficult to provide
[10:31] <Saviq> salty-horse, looks like something went wrong with channels
[10:32] <salty-horse> Saviq, but what if you want to change the icon to have it show something? and what if it's an old program that doesn't come with a .desktop file but DOES set an icon? oh well. :)
[10:32] <salty-horse> Saviq, yeah, I'll investigate later with a simple icon that has distinct RGBA quadrants
[10:32] <Saviq> salty-horse, you shouldn't change the icon to show anything - an icon is a static representation of which app that is
[10:33] <Saviq> salty-horse, and whoever packages the old app can supply the desktop file
[10:33] <Saviq> we really need to be able to say something is end-of-life, we can't support legacy for centuries to come
[10:33] <salty-horse> is that "rule" in the freedesktop.org guidelines? :)
[10:34] <Saviq> salty-horse, guidelines are just that - guidelines
[10:34] <salty-horse> Saviq, also, as a developer running a program I compiled myself from the development path, I won't see an icon for it, right?
[10:34] <Saviq> salty-horse, if you put a .desktop file in ~/.local/share/applications that matches the binary name, you will
[10:35] <Saviq> not sure exactly how BAMF does the matching
=== alex-abreu|off is now known as alex-abreu
=== mardy_ is now known as mardy
[14:37] <tsdgeos> pstolowski: mzanetti: greyback: i approved this https://code.launchpad.net/~josharenson/unity8/add-timestamps-to-dash-log/+merge/295538 feel free to comment if you disagree :D
[14:37] <mzanetti> no, it's fine
[14:37] <mzanetti> I looked at it but couldn't make up my mind on date yes/no
[14:37] <josharenson> mzanetti: I added the date
[14:38] <mzanetti> so I decided to not comment
[14:38] <josharenson> yyyy-mm-dd+original time
[14:38] <greyback> lgtm
[14:38] <mzanetti> +1
[14:39] <josharenson> mzanetti: greyback tsdgeos if you like the time format, I think I'll add it to unity8.log too (a la https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1498169)
[14:39] <ubot5> Launchpad bug 1498169 in Canonical System Image "some logs in .cache/upstart are missing date/timestamps" [High,Confirmed]
[14:39] <mzanetti> oh, was this only the dash?
[14:40] <josharenson> mzanetti: yeah
[14:40] <mzanetti> yes please add it to unity8 too
[14:40] <josharenson> ok
[14:59] <pstolowski> tsdgeos, thanks! i didn't expect such massive diff :?
[14:59] <pstolowski> :/
[15:00] <tsdgeos> pstolowski: 1 line diff is massive? ?¿
[15:00] <pstolowski> tsdgeos, me kidding :P
=== dandrader is now known as dandrader|afk
=== Oer is now known as OerHeks
[15:35] <cimi> tsdgeos, https://code.launchpad.net/~aacid/unity8/noFixedArtShapeSizeForCardToolCard/+merge/295424/comments/758415
[15:36] <cimi> tsdgeos, this is weird, it passes locally
[15:36] <cimi> tsdgeos, but you're touching that code aren't you?
[15:37] <cimi> unless it's a weird merge
[15:37] <tsdgeos> https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/label=amd64,release=xenial+overlay,testname=qmluitests.sh/806/testReport/junit/%28root%29/qmltestrunner/Card__test_art_shape_fixed_size/ is real
[15:37] <tsdgeos> but i had fixed that one
[15:37] <cimi> yeah in the following branch?~
[15:38] <tsdgeos> no, in here
[15:38] <cimi> I see it passing here https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/label=amd64,release=xenial+overlay,testname=qmluitests.sh/808/
[15:38] <cimi> ok
[15:38] <tsdgeos> but this CI is less smart than the old one (or i think)
[15:38] <tsdgeos> Saviq: there?
[15:38] <tsdgeos> cimi: i forced pushed and CI didn't re-run, i'll retrigger it
[15:38] <cimi> tsdgeos, i can retrigger
[15:39] <tsdgeos> i just did :D
[15:39] <tsdgeos> Saviq: is there a way we can make CI run on force-pushes (eventually ones that have smaller or equal revision number) ?
[15:43] <josharenson> mzanetti: tsdgeos I don't know if you took a look at the latest Autoscroller draft, but unless you have issues w/ it, I'm going to make it part of the dash-autoscrolling MP
[15:43] <josharenson> unless you think there is a compelling reason to push for it to be included in the uitk
[15:43] <mzanetti> josharenson, didn't look at the latest revision yet
[15:43] <Saviq> tsdgeos, yeah we'd need to work on the python scripts we've inherited
[15:44] <mzanetti> yeah, I think what saviq meant was to push it to the sdk
[15:44] <tsdgeos> josharenson: me had a look either, i guess you can start working on it and i'll give it a look tomorrow morning first thing
[15:44] <josharenson> mzanetti: ok I'll update the comments to better match qdoc style
[15:44] <josharenson> tsdgeos: sure, no worries
[15:45] <tsdgeos> mzanetti: i guess for now we can be "happy" if we don't have two implementations (launcher and scopes list)
[15:45] <tsdgeos> and then move it up to the sdk?
[15:45] <mzanetti> yeah, I guess that's ok
[15:46] <Saviq> +1
[15:46] <mzanetti> just ran it. it behaves like I'd expect it now
[15:48] <mzanetti> josharenson, not 100% sure I understand how you use the containerHeight property
[15:49] <josharenson> mzanetti: let me take a look, it was necessary at some point, but may no longer be
[15:49] <mzanetti> also I think 2 of the 3 bindings have wrong syntax and just do nothing
[15:49] <mzanetti> josharenson, ^
[15:50] <josharenson> mzanetti: ah missing ""
[15:50]  * josharenson wonders how this works at all w/ those broken...
[15:50] <mzanetti> josharenson, yeah, but I'm also not sure what they should do. seems the one on contentX/contentY is enough
[15:50] <josharenson> ok
[15:51] <mzanetti> josharenson, well, in general looks not too bad. clean it up a bit and then yeah, put it into the MP
[15:52] <josharenson> mzanetti: the container height was to determine where the bottom of the visible surface was. For example, if you run tryDash and shrink the window in the y direction, the list height extends past the window, but the parent height was updating with the resize... probably an issue specific to the original dash MP
[15:55] <mzanetti> josharenson, shouldn't you be able to get all of that either from the size of the item itself, or from the flickable.contentHeight etc?
[15:56] <josharenson> mzanetti: the contentHeight was still larger than the window for the dash case IIRC
[15:56] <josharenson> mzanetti: its unlikely that itll ever be an issue in real life though
[15:59] <mzanetti> josharenson, if you're talking about the size of the listview itself, not the content, it should be the same as the autoscroller height itself now
[15:59] <mzanetti> so to me it looks like this could go away, but I might still miss a detail somewhere
[16:00] <josharenson> mzanetti: ok ill get rid of it and see if it breaks ever
[16:52] <bschaefer> attente, hello! Soo maliit-inputcontext-gtk3
[16:52] <bschaefer> on vivd
[16:52] <bschaefer> vivid* is just an empty package. Need to figure out the best way we should get a valid input context to the vivid overlay?
[16:52] <attente> bschaefer: oh sorry. totally forgot to reply...
[16:52] <bschaefer> attente, o no worries :)
[16:53]  * bschaefer would have poked you everyday until you did!
[16:53] <bschaefer> attente, my main concern is ... we'll have to also do maliit-framework but im not sure if theres an API/ABI break
[16:53] <bschaefer> in that...
[16:56] <attente> bschaefer: i'm not sure how the overlay works, but can it just ship the maliit-inputcontext-gtk3 module in the correct location?
[16:56] <bschaefer> attente, well the issue with that ... is maliit glib
[16:57] <bschaefer> is now moved back into the maliit-framework?
[16:57]  * bschaefer should double check that
[16:57] <attente> yeah, should be
[16:58] <attente> so vivid doesn't have maliit-glib?
[16:58] <bschaefer> attente, im pretty sure it does though ill have to double check if its empty or not
[16:58]  * bschaefer isnt sure what the maliit-inputcontext-gtk3 is empty for vivid
[16:58] <bschaefer> sure why*
[16:59] <attente> basically there was a huge re-factor where jan ripped all of that stuff out into separate repos
[16:59] <bschaefer> attente, it only has libmaliit-glib0 - transitional dummy package
[16:59] <attente> but nobody ever re-packaged the new repos
[16:59] <attente> damn. ok
[16:59] <bschaefer> attente, o i see, soo yeah i think... ill need to re-package the maliit-framework
[17:00] <bschaefer> which will have the maliit glib lib
[17:00] <attente> yeah
[17:00] <bschaefer> annnd the inputcontext gtk3 should be happy
[17:00] <bschaefer> attente, cool thanks!
[17:00] <attente> bschaefer: does that mean sru'ing that to vivid?
[17:00] <bschaefer> attente, no hopefully this goes straight into the overlay
[17:00] <bschaefer> overlay == ppa that we stuff packages that need to be backported
[17:00] <attente> oh ok
[17:01] <bschaefer> attente, soo the only issue here is if there is a API/ABI break of anything that depends on
[17:01] <bschaefer> maliit-frameowrk
[17:01] <bschaefer> would also need to be backported which ... hopefully is zero otherwise ill have to figure out what to do :)
[17:02] <attente> can't imagine that any api/abi was broken
[17:02] <bschaefer> attente, well then thats good news :) If the keyboard works
[17:02] <bschaefer> then that will show
[17:03] <bschaefer> since it'll crash otherwise
[17:03] <bschaefer> soo it'll be an easy catch if there is
[17:03] <attente> true :) i just wish you didn't have to go through all the work of doing it in the case that it breaks
[17:04] <bschaefer> attente, i know :(
[17:04] <attente> the good news is it looks like not much happened there upstream beyond migrating from qmake to cmake
[17:04] <bschaefer> attente, once we move to xenial + overlay
[17:04] <bschaefer> o sweet
[17:04] <bschaefer> ill look around there as well just to double check
[17:04] <attente> bschaefer: thanks!
[17:05] <bschaefer> attente, np, and thank you for the info!
=== dandrader|afk is now known as dandrader
[17:36] <dandrader> mterry, is there still a reason for the "needs fixing" here? https://code.launchpad.net/~dandrader/qtmir/removeHotspot/+merge/293629
[17:37] <mterry> dandrader, nope, just upgraded to abstain.  thanks
[17:38] <dandrader> ltinkl, mind top-approving that back again https://code.launchpad.net/~dandrader/qtmir/removeHotspot/+merge/293629 ?
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader