=== chriadam|away is now known as chriadam
[01:11] <liuxg> nik90, ping
[01:13] <liuxg> how to get the attributes in javascript when using the "XMLHttpRequest" to parse the xml? I do not want to use "XmlListModel" in QML
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[06:29] <dholbach> good morning
=== JMulholland_ is now known as JMulholland
[08:57] <dpm> bzoltan, kalikiana, zsombi - quick question: someone asked me if responsive localization worked in Ubuntu. That is: how can a text be displayed abbreviated in a form factor where there is not enough space to show it, and then it would display fully (non-abbreviated) in a bigger enough form factor. I'm sure there would be really clever ways to do this, but I guess an easy way to implement it would be to use Layouts and msgctxt to have the same messag
[08:57] <dpm> e written in each layout, but with a different gettext message context so that each can be translated independently?
[09:06] <kalikiana> dpm: hmm without having tried itxl, you could use the active layout name as part of the domain name
[09:06] <dpm> kalikiana, what's itxl?
[09:07] <kalikiana> That's me failing to type properly :-)
[09:10] <dpm> kalikiana, still not sure what you meant, but I think having support for msgctxt would be a more natural way to do it: http://pastebin.ubuntu.com/10937497/
[09:10] <dpm> then you'd need just a domain and one .po/.mo file
[09:18] <kalikiana> dpm: so what is stopping you from doing just that?
[09:18] <kalikiana> Assuming South is the name of a layout here
[09:25] <dpm> kalikiana, what's stopping us from using it is the fact that we don't support msgctxt in the i18n API, but I guess it shouldn't be too complex to add it as an optional parameter to the i18n.tr() call
[09:26] <dpm> kalikiana, "South" could be the name of a layout indeed, but in general, it can be any string for developers to give more context on the use of that string
[09:26] <dpm> so it's like a translator context message,
[09:27] <dpm> and when you add it, you can have that translatable string twice in the .po file, which otherwise wouldn't be possible
[09:28] <kalikiana> dpm: we have i18n.ctr
[09:29] <kalikiana> though there's a bug about making it an argument to i18n.tr, the functionality is there
[09:37] <dpm> kalikiana, oh, I couldn't see it in the docs - https://developer.ubuntu.com/api/qml/sdk-14.10/Ubuntu.Components.i18n/
[09:37] <dpm> out of date perhaps?
[09:38] <kalikiana> dpm: it's vivid API/ 1.2
[09:39] <kalikiana> still waiting for current docs to show up there…
[09:41] <kalikiana> dpm: it's i18n.ctr("South", "S")
[09:41] <kalikiana> or dtr respectively
[09:41] <kalikiana> *dctr
[09:42] <dpm> ok, cool, and I see bug 1417680 now too
[09:42] <ubot5> bug 1417680 in ubuntu-ui-toolkit (Ubuntu) "Add context to i18n.tr(), deprecate ctr()" [Medium,Confirmed] https://launchpad.net/bugs/1417680
[09:45] <kalikiana> yep, we just noticed a bit late there was no need for the extra function name
=== chriadam is now known as chriadam|away
=== MacSlow is now known as MacSlow|lunch
=== MacSlow|lunch is now known as MacSlow
[12:48] <mhall119> zsombi: t1mp: changing a page's flickable seems to have unpredictable results
[12:50] <mhall119> for example, I want it to be null when I have enough window height (on the desktop) that it's not worth hiding the header, but then switch to a ListView when there isn't enough height
[12:51] <mhall119> so I used flickable: uReadIt.height < units.gu(70) ? postsList : null
[12:51] <mhall119> but when switching between them, sometimes the top of the ListView is under the Header when scrolled all the way up, other times it's well below the Header when scrolled all the way up
[12:51] <mhall119> am I doing something wrong, or is this a bug?
[13:13] <t1mp> mhall119: best not to change the flickable. That was a temporary workaround
[13:14] <t1mp> mhall119: in Ubuntu.Components 1.3 I added page.head.visible and page.head.locked properties to properly specify the behavior that you want
[13:14] <t1mp> mhall119: stable 1.3 will be released with ubuntu 15.10, but we have an unstable version in our staging now
[13:14] <t1mp> where unstable means that the APIs are not fixed yet
[13:16] <t1mp> mhall119: also, I could imagine that on a larger screen we decide to lock the header by default. But that is up to design.
[13:37] <mhall119> t1mp: ok, but until 15.10 I'm stuck with what's possible now
=== rickspencer3_ is now known as rickspencer3
[13:40] <mivoligo> mhall119: bzoltan: ping ping
[13:40] <bzoltan> mivoligo: pong pong
[13:41] <mivoligo> mhall119 asked me to ping ping ;)
[13:41] <mhall119> bzoltan: mivoligo was having the same issue as me with the APP_ID in the Makefile being backwards
[13:41] <mhall119> mivoligo: can you pastebin "apt-cache policy qtcreator-plugin-ubuntu-common"
[13:42] <mhall119> mivoligo: also, what release of Ubuntu are you on?
[13:42] <bzoltan> mhall119: darn ... something is wrong with the PPA
[13:42] <mivoligo> mhall119: bzoltan: 14.04
[13:43] <bzoltan> mivoligo:  mhall119 -> https://launchpad.net/~ubuntu-sdk-team/+archive/ubuntu/ppa/+files/qtcreator-plugin-ubuntu-common_3.1.1%2B15.04.20150421-0ubuntu1~0trusty1_all.deb
[13:43] <mivoligo> mhall119: http://paste2.org/mj33syAX
[13:44] <mhall119> well now, mivoligo has the latest version
[13:44] <mhall119> mivoligo: can you test that the bug still exists if you create a new project?
[13:44] <mivoligo> mhall119: bzoltan: I don't know if I still have the issue, let me check
[13:45] <bzoltan> mivoligo: would you please pastebinit /usr/share/qtcreator/templates/wizards/ubuntu/simple-app-qmlproject/Makefile
[13:46] <mivoligo> bzoltan: http://paste2.org/5k6DPYj9
[13:48] <bzoltan> mivoligo:  it is correct APP_ID=%ProjectName:l%.%ClickDomain:l%
[13:48] <mivoligo> bzoltan: mhall119: just created a test project, no issue there
[13:49] <bzoltan> mivoligo: _PROFIT_ :D
[13:50] <mhall119> ok, so it's still just me :)
[13:50] <mivoligo> bzoltan: mhall119: I had that issue about a week ago when trying to add translations to Pop That Wrap. dpm helped me find what the problem was
[13:51] <mhall119> mivoligo: right,and they fixed it in qtcreator-plugin-ubuntu-common
[13:51] <mhall119> you have the latest version with the fix, for some reason apt won't get me that version
[13:52] <mivoligo> mhall119: are you on 14.04?
[13:55] <mhall119> mivoligo: no, 14.10
[13:58] <mivoligo> mhall119: well, you can just change APP_ID in Makefile for now :)
[13:58] <mhall119> mivoligo: I know
[13:59] <mivoligo> or update to 14.04 :D
[13:59] <mhall119> bzoltan: so you can mark my bug as fix released, and I'll just fix my apt at some point
[13:59] <mhall119> mivoligo: or 15.04 :)
[13:59] <mivoligo> :)
[13:59] <bzoltan> mhall119:  Ok, that is what we will do <- zbenjamin ^
[14:00] <bzoltan> mhall119:  but please share with me once you figure out what hides the packages for you
=== _salem is now known as salem_
[14:02] <mhall119> bzoltan: will do
=== salem_ is now known as _salem
=== chihchun is now known as chihchun_afk
=== _salem is now known as salem_
[16:42] <akiva-thinkpad> hello all
=== chihchun_afk is now known as chihchun
=== davidbarth is now known as dbarth
[18:44] <balloons> akiva-thinkpad, I talked briefly with benjamin about the MP for the AP plugin. He and I are on the same page. I think it makes sense to land just the runconfig approach at first. You agree?
=== aaron__ is now known as ahoneybun
=== aaron__ is now known as ahoneybun
[20:23] <akiva-thinkpad> balloons, oh hey
[20:24] <akiva-thinkpad> balloons, as I understand it, don't have the menu, just have the runconfig?
[20:25] <akiva-thinkpad> If that is the case, then I disagree for a very simple reason. The menu method is very stable. The run config method is a lot more difficult to impliment
[20:26] <akiva-thinkpad> I'll give you an example
[20:26] <akiva-thinkpad> I grabbed the core app for the terminal app
[20:27] <akiva-thinkpad> After building it in qtcreator, I had a compile error,
[20:27] <akiva-thinkpad> error 2 or something. It is failing make for some reason to just run the app on a regular run configuration
[20:28] <akiva-thinkpad> Now, I can still go to the menu, and still run tests. Doesn't make sense to me, but it lets me, and works without a hitch.
[20:28] <akiva-thinkpad> However when I try to run the autopilot run config, it will not let me run it, giving the same make error
[20:29]  * akiva-thinkpad does not like how he explained this.
[20:30]  * akiva-thinkpad will try again.
[20:33] <akiva-thinkpad> The reason I disagree with you and zbenjamin on implementing the Run Configuration first, is because the Menu is much more stable, simple, and reliable in comparison.
[20:36] <akiva-thinkpad> When the test's output is properly displayed in a application output, I will regard it as stable.
[20:38] <akiva-thinkpad> The reason why the Run Configuration is less stable is because its implementation is more complicated.
[20:42] <mhall119> bzoltan: zbenjamin: I've been getting frequent crashes of uReadIt recently, not sure if it's a change I made or something in devel-proposed, http://paste.ubuntu.com/10942067/ shows the error from the last crash
[20:44] <akiva-thinkpad> The reason I say it is more complicated, is because the checklist UI requires memory, the base class I derive from does things which is beyond the functionality needed for my run config, and it is easier to have memory leaks within the run configuration.
[20:50] <akiva-thinkpad> ah
[20:56] <akiva-thinkpad> zbenjamin, I actually forgot about implementing it in the locator
[21:06] <akiva-thinkpad> I am just going through your review thanks for taking the time to look at it. I actually forgot to remove the merge proposal, because this is more of a WIP.
[21:36] <oSoMoN> nerochiaro, https://code.launchpad.net/~osomon/webbrowser-app/systemwide-search-engines/+merge/257830 is partially based on your code, I’d appreciate if you could review it
=== salem_ is now known as _salem
[23:51] <trickvi_> I'm getting ready to make a first contribution so bare with me: I want to add a new on screen keyboard, where would I find the relevant code to look at and hack on?