[07:11] <dholbach> good morning
[07:20] <Mirv> it seems it's not just me with vivid click chroot creation problem failing + umounting encrypted home dir bug #1436852
[07:20] <Mirv> which is kind of reliefing since it means I'm not the only person in the world who can (mis)configure his system in that way
[07:33] <aquarius> popey, so you and I both can't build anything. What thing are we doing wrong which is presumably obvious to C++ people? :)
[08:22] <popey> aquarius: well, i can build C++ stuff, but for some reason not today
[08:33] <uglyandstupid> morning all
[08:41] <uglyandstupid> What's Ubuntu's way of exposing native API to both HTML and QML UI code ?
[08:44] <uglyandstupid> i.e when you have a service daemon offering Play/Pause API that someone would like to call from JS/QML code
[08:50] <oSoMoN> nerochiaro, good morning! have you seen my last comment on https://code.launchpad.net/~uriboni/webbrowser-app/bookmarks-in-suggestions/+merge/256459 ?
[08:51] <nerochiaro> oSoMoN: on it in a few minutes
[08:51] <oSoMoN> thanks
[08:53] <aquarius> popey, yeah, I can compile other things (I checked that). I don't understand how to get actual output from Ubuntu SDK about where the compile is looking for libraries, rather than just a one-line error!
[08:54] <nik90> zsombi: ping
[08:54] <zsombi> nik90: pong
[08:54] <aquarius> uglyandstupid, to offer some other service to QML code, write a QML extension plugin which talks whatever the API is and exposes it to QML code. I don't know how new APIs are exposed to HTML5 apps; oSoMoN may know
[08:55] <nik90> zsombi: How is it that your theming stuff along with the new header style landed in vivid? I thought no new API was allowed to land in vivid this late in the cycle?
[08:55] <zsombi> nik90: perhaps a mistake, or you got the overlay PPA as well...
[08:55] <nik90> zsombi: this is on the phone
[08:56] <zsombi> nik90: then it was a mistake
[08:56] <nik90> ah ok
[08:56] <zsombi> nik90: and afaik new header style supposed to be 1.3 as well... or perhaps that is independent on the new header config APIs
[08:57] <zsombi> nik90: yes, they are independent...
[08:57] <nik90> zsombi: the reason I asked is that in Podbird and ureadit, we use a property called "theme" which we change...but turns out that is now used by the SDK and is declared as final..as a result Podbird and ureadit crash on the latest vivid :)
[08:58] <zsombi> nik90: well, happens :)
[08:58] <aquarius> haha! I just asked mhall119 on g+ why the version number of the components didn't change for that breaking change :)
[08:58] <nik90> zsombi: either way the new header looks cool, lets hope that stays in vivid
[08:59] <nik90> aquarius: yeah don't get me started on the frameworks issue :P
[08:59] <zsombi> nik90: I don't think so as it was based on 1.3 changes :/
[08:59] <zsombi> nik90: :)
[08:59] <zsombi> nik90: aquarius: we're working on that too
[08:59] <aquarius> am a bit worried that breaking changes aren't changing the version number, which means that this change will break any app which uses "theme" as a variable, even if that app doesn't change. Stopping this happening is what version numbers are *for* :(
[09:00] <zsombi> aquarius: so your apps import 1.2 UITK, right?
[09:00] <zsombi> or earlier
[09:00] <aquarius> actually, mostly earlier
[09:00] <nik90> zsombi, aquarius: I think it will be reverted..since it breaks core apps *visuall* like clock, browser, reminders etc
[09:00] <nik90> s/visuall/visually
[09:00] <zsombi> I hope you don't import 0.1..!
[09:01] <popey> (I hope apps were tested)
[09:01] <zsombi> nik90: it will be reverted in a sense that 1.3 won't be there
[09:01] <zsombi> I hope at least...
[09:01] <nik90> same
[09:02] <zsombi> nik90: aquarius: the theme property is exported for 1.3 versions only, but unfortunately Qt versioning is a mess :/
[09:02] <aquarius> riddling probably imports 0.1 because it's old. Caxton and Readability import 1.1.
[09:02] <zsombi> nik90: aquarius: so if a component implementation imports 1.3, it exports that to 1.2 as well :/
[09:03] <zsombi> aquarius: then it would be about the time to get rid of the 0.1 import
[09:03] <aquarius> zsombi, why? it works.
[09:03] <nik90> well this is devel-proposed..so this kind of breakage is expected..which is why I was really surprised to see https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/landing_2015-04-17/+merge/256647 land in vivid
[09:04] <zsombi> nik90: aquarius: it does... but it's not healthy :) it only has 1.0 APIs
[09:04] <aquarius> but I don't use anything outside those APIs (by definition).
[09:04] <aquarius> No benefit to upgrading!
[09:04] <zsombi> aquarius: yep, until we remove that
[09:04] <zsombi> 16.04 will definitely do remove 0.1 support!
[09:05] <zsombi> and will come with 2.0
[09:05] <aquarius> then I look forward to it throwing deprecation warnings for at least a year beforehand, to warn developers about it
[09:05] <aquarius> because of course you wouldn't just do a release which broke perfectly working apps for no reason other than disc space. :)
[09:05] <zsombi> aquarius: see the blog: all deprecated APIs removed in 2.0
[09:06] <aquarius> it's not a deprecated api! :)
[09:06] <zsombi> aquarius: all apps importing 1.x will work, but 2.0 APIs won't have any deprecated 1.x APIs
[09:06] <zsombi> aquarius: well, kinda yes :) 1.0 = 0.1 in this case :)
[09:07] <zsombi> aquarius: but we encourage people to get rid of 0.1 imports
[09:07] <zsombi> so in that sense is deprecated :)
[09:07] <aquarius> that's not what I mean. I personally do not feel that a few words on a blog that app devs don't read is enough to tell people that a thing is deprecated. Why not make it throw warnings? So developers see it.
[09:08] <nerochiaro> oSoMoN: pushed the fix. is it going to be merged today ? i would like to submit the MR for the suggestions on top of that one
[09:08] <nerochiaro> oSoMoN: but i guess i can just do that with a prerequisite branch
[09:08] <zsombi> aquarius: then tell me how to announce better the deprecation. 0.1 module deprecation cannot be shopwn in any runtime logs, and if blogs, emails are not read, how should we do?
[09:08] <oSoMoN> nerochiaro, it won’t be merged today, but yes, you can mark it as a prerequisite
[09:09] <zsombi> aquarius: the plan has been announced in many channels, u-d-c blog, g+, IRC, so those who wanted to read they did
[09:10] <nik90> zsombi: may be starting with 15.10 or something, any apps importing 0.1 will have a deprecation warning asking devs to upgrade to 1.x similar to component deprecation?
[09:10] <zsombi> nik90: just said: no way to post warning on import versions :/
[09:10] <nik90> aquarius: although aquarius ^^ will not be noticeable by you until you run your app importing 0.1 in qtcreator and see these warnings
[09:10] <nik90> zsombi: ah..missed that
[09:11] <zsombi> nik90: unless we duplicate all components for 0.1 and post a warning there :(
[09:12] <aquarius> zsombi, why can't it be announced? Just add "Component.onCompleted: console.warn('This is deprecated! upgrade, you lazy toad');" to the top of all components?
[09:12] <uglyandstupid> aquarius: thanks
[09:12] <zsombi> aquarius: and how do you know that it had been imported with 0.1?
[09:12] <zsombi> aquarius: without duplicating all components for 0.1?
[09:13] <aquarius> zsombi, hang on. I assumed that you have an Ubuntu/Components/0.1 folder somewhere with 0.1 components in it, and then an Ubuntu/Components/1.0 folder somewhere with 1.0 components in. Is that not the case?
[09:13] <zsombi> aquarius: nik90: but having 2.0 without the deprecated 1.x APIs doesn't mean the 1.x will chease working
[09:14] <zsombi> aquarius: well, my dear friend, get the sources and see, there's nothing like that :)
[09:14] <zsombi> aquarius: it would be a HUGE maintenance burden
[09:14] <zsombi> to have separate component and plugins for each minor update
[09:14] <aquarius> it wouldn't be a maintenance burden at all, would it? Once you've released 1.2, you never ever touch that folder again; that's what a release is
[09:15] <zsombi> aquarius: the versioning was always bad, it shoul dhave always been started with 1.0, not with 0.1
[09:15] <zsombi> aquarius: wouldn't it?
[09:15] <aquarius> it doesn't get maintained. Bugs are fixed in newer versions. that's the point of version numbers :)
[09:15] <zsombi> aquarius: have you ever thought that each minor changes would require component duplication?
[09:15] <zsombi> and I guess yo always liked to get fixes on components, right?
[09:16] <zsombi> so, fixing a bug would require us to "backport" to each component in each minor version, which is a maintenance burden
[09:16] <aquarius> Yep. That's exactly what I believed happened. You release 1.2 and that's 1.2 for ever. If there are bugs in it, tough. (There is a period *before* 1.2's release when there is a "1.2" which keeps changing, of course.)
[09:17] <aquarius> No, you don't backport the bug fixes; the bug stays there. Because it's been released. In the same way, if you fix a bug in a deb package, you have to increase the version number. Otherwise it can't be installed
[09:18] <zsombi> aquarius: yes, you are right
[09:18] <aquarius> that may not be the way we do things, but I'm pretty sure it's the way QML versioning *expects* that you're doing things -- that's why you have to specify a version number to import. If my app says "import Ubuntu.Components 1.2" and works on some machines and not others because they and I have different "versions" of "1.2"... that's what version numbers are meant to stop happening!
[09:19] <aquarius> there aren't meant to be two different "versions" of 1.2 :-)
[09:19] <zsombi> aquarius: however, that would also mean that your app importing 1.0 would have the same bug even if the device got upgraded to use 1.1
[09:20] <aquarius> yep
[09:20] <aquarius> which is unfortunate
[09:20] <aquarius> however, it is less bad than my working app importing 1.0 *breaking* when I haven't touched it :)
[09:20] <zsombi> aquarius: so you'd need to upgrade your app then...
[09:20] <zsombi> aquarius: well, I agree on that
[09:21] <aquarius> yes. I have clearly decided that the bug in 1.0 didn't affect my app enough to avoid releasing it, or I really do hate that bug and so I've worked around it in my app somehow
[09:21] <zsombi> aquarius: and QML versioning does not expect that either
[09:21] <aquarius> when a new version of the UITK comes out, I need to upgrade my app to use it. That's what I expect, indeed
[09:21] <aquarius> I do not expect a working version of the UITK to change under me and break my app :(
[09:21] <aquarius> I didn't even realise that I was *supposed* to be expecting that :(
[09:21] <zsombi> aquarius: see QtQuick plugin, they export the same components with revisions, and QML documents are the same for all versions
[09:23] <zsombi> aquarius: QtQuick.Controls for instance they do this: same component exported to all minor versions
[09:23] <zsombi> aquarius: and btw, there was an email - inm - long ago about asking app devs to turn to import 1.0 instead of 0.1 :)
[09:23] <aquarius> so a QML programmer is *meant* to expect that a component they import might change and break their app?
[09:24] <zsombi> aquarius: not change and break, but to get bugs fixed, yes
[09:24] <zsombi> aquarius: if breaks, then we need to fix that
[09:24] <aquarius> (also, I have just looked through and searched the blog and it doesn't mention deprecating this stuff, unless I'm missing something :))
[09:24] <zsombi> aquarius: but if it is because of some API we add, that is not on us, sorry
[09:25]  * nik90 checks
[09:25] <zsombi> aquarius: the blog might not say that, but major version bumping means that the 2.0 plugin will not bring anything kicked out from 1.x, also it means that it will be a separate module
[09:25] <aquarius> I'm totally fine with it being a separate module
[09:25] <zsombi> aquarius: that is the way ytou do in QML extension plugins
[09:25] <aquarius> that's a great idea
[09:26] <nik90>  aquarius: well it does say in 2.0: Clean up deprecated components..I presume that means being removed
[09:26] <aquarius> what I expect is that when I ship a package which mentions in click frameworks that it uses ubuntu-sdk-14.10, that that will continue to work
[09:26] <zsombi> aquarius: also, keeping separate module for each minor would be the best way, but QML plugin system doesn't let us do that :/
[09:26] <aquarius> nik90, ya, but it doesn't say what the deprecated things *are* :)
[09:26] <zsombi> aquarius: so the only way to support backwards minor versions is to have them under the same module :(
[09:27] <aquarius> zsombi, what? that's bloody stupid.
[09:27]  * aquarius looks annoyedly at Qt
[09:27] <zsombi> aquarius: every release announces the deprecations...
[09:27] <karni> Hi folks. I have a question. When I insert text into a text field, currently the way it works the text field won't know there's a text in it until after you press space (to "accept" the word into the text field). What's a suggested workaround for that? If we add voice note support in Telegram similar to Android, we end up not being able to send 'yo' ('yo<space>' is fine), because the microphone button is still visible, even though there's ...
[09:27] <karni> ... text in the text field. the only workaround I can imagine is using keyboard Enter as "Enter to send"
[09:28] <nik90> karni: Elleo is the best person to talk to about this ^^
[09:28] <zsombi> karni: I guess it's the input method which messes you there
[09:28] <karni> zsombi: correct
[09:28] <zsombi> karni: how do you insert the text?
[09:28] <zsombi> karni: so call Qt.inputMethiod.comit()
[09:29] <karni> zsombi: the user types the text. I know commit() works, but how would I know when to do that.
[09:29] <zsombi> karni: maybe an idle timer?
[09:29] <karni> I want to send "bro" to you zsombi, but unless I press space, I wouldn't be able to do that
[09:29] <karni> zsombi: I guess that'd be last resort (yet another workaround :( )
[09:29] <zsombi> karni: there should be a send button, right?
[09:30] <karni> Elleo: hey bro, asked a question couple lines above, would you have suggestions? ↑
[09:30] <zsombi> karni: when you press the Send button, you call commit before sending
[09:30] <karni> zsombi: the send button is a microphone button, so you can press it and record a voice note that is immediately sent. when you strat typing, it *should* animate to a regular 'send' button
[09:30] <karni> zsombi: ha. there's no 'send' button until that time, that's the problem :(
[09:31] <zsombi> karni: well, there has to be something which triggers the sending
[09:31] <karni> zsombi: once you type (*and* press space), microphone animates to a send button.
[09:32] <zsombi> ok
[09:32] <karni> on Android, you have things like onTextChanged whatever, so that's easy. here, we have input method preventing the text field from knowing about text.
[09:32] <zsombi> why only at space pressing? doe sit animate to send when you type? or only at space?
[09:32] <zsombi> aaaah
[09:32] <karni> zsombi: because space commits last input method word
[09:32] <zsombi> I see now!
[09:32] <Elleo> karni: the text will be committed on a focus change if you press a send button or similar
[09:32] <Elleo> karni: assuming you let the button take focus (otherwise call Qt.inputMethod.commit() when it's pressed)
[09:32] <karni> which may be the first one
[09:32] <Elleo> karni: ah, are you wanting to just detect that there's text being entered to change the button?
[09:33] <Elleo> karni: I'm pretty sure there's a property you can monitor to know when text is being composed (but hasn't been committed yet)
[09:33] <zsombi> there was sthing on teh text field...
[09:33] <Elleo> iirc the messaging app uses it to activate their send button
[09:33] <karni> Elleo: I need to detect *before* the send button is visible. actually, that _would_ show the send button
[09:33] <zsombi> karni: inputMethodComposing() signal
[09:33] <Elleo> karni: yeah, that's what I mean
[09:33] <zsombi>  or sthing lik ethat
[09:33] <karni> whoooo \o/
[09:33] <karni> exactly what I needed, thanks guys! I'll have a look at the messaging app / that method !
[09:33] <zsombi> karni: sorry, that API si a bit huge... hard to find all you need, but it's there :)
[09:34] <karni> :) I'm glad it's there!
[09:34] <Elleo> yeah there's an inputMethodComposing property on text stuff that messaging-app is using
[09:34] <karni> lovely, that's what I needed :)
[09:34] <Elleo> karni: line 985 of Messages.qml
[09:34] <karni> =D
[09:35] <karni> \o/
[09:37] <Elleo> :)
[09:56] <Saviq> Elleo, I think a UITK update broke Podbird:
[09:57] <Saviq> file:///opt/click.ubuntu.com/com.mikeasoft.podbird/0.5/share/qml/podbird/podbird.qml:68 Cannot override FINAL property
[09:57] <nik90> Saviq, Elleo: Already fixing it now :)
[09:57] <nik90> Saviq: it is due to new UITK that landed in devel-proposed
[09:57] <Saviq> nik90, yeah, I wonder if that's not a bug there though
[09:58] <aquarius> popey, I filed https://github.com/rschroll/beru/issues/83 for rschroll anywya
[09:58] <nik90> Saviq: we just used a property called "theme" that so happens that the new SDK also uses :)...
[09:59] <Saviq> nik90, ah!
[09:59] <Saviq> nik90, got it
[09:59] <Elleo> Saviq, nik90: yeah, to me it seems like a UITK bug if it breaks existing apps by changing API without changing API version
[09:59] <nik90> Saviq: we just had a long discussion and it might be a mistake that the new UITK introduces new properties in vivid...might get reverted
[09:59] <nik90> Elleo: it might get reverted (hopefully)...but nonetheless my fix ensures it wont break when we switch to ubuntu.components 1.2
[10:00] <Elleo> nik90: won't hurt us to rename the property though
[10:00] <nik90> Elleo: just had to rename theme to appTheme for now..exactly
[10:00] <aquarius> it won't, but it basically means that we now don't know how to pick property names in case the SDK team decide in the future that they want that name instead :(
[10:01] <nik90> aquarius: I suspect that with recent changes around the vivid-overlay PPA that was announced in the mailing list, the new UITK landed accidentally (my guess)
[10:01] <Elleo> nik90: yeah
[10:02] <aquarius> ya, but it landing accidentally isn't the point. Surely even if it hadn't been released today, it'll be released at some point, and break podbird and ureadit when it does release?
[10:03] <nik90> aquarius: yeah it will..I know we had the long discussion just few minutes back :)
[10:04]  * aquarius grins
[10:04] <aquarius> this does worry me rather
[10:04] <nik90> aquarius: I guess this is a UOS topic about being backwards compatible
[10:04] <Elleo> yeah, app devs need to be certain that their apps won't be broken by things out of their control
[10:04] <aquarius> (also, as popey says, testing new sdk releases against existing apps would be good. I mean, you can't test everything, I understand that, but podbird is a featured app!)
[10:04] <ogra_> guys, you are still talking about something unreleased ...
[10:05] <aquarius> ogra_, ya, but when it *is* released, it'll have the same problem.
[10:05] <aquarius> ogra_, because breaking changes are ported downlevel.
[10:05] <ogra_> it isnt borken on the released phone ... and devs have enough time to fix their stuff before it hits the phone ...
[10:05] <ogra_> what we need to do is being loiuder and make more announcements to them
[10:05] <Elleo> ogra_: app devs shouldn't have to fix anything for an API that was already stable
[10:05] <aquarius> ogra_, hang on, you're suggesting that app devs need to run pre-release versions of the OS? I don't!
[10:06] <ogra_> Elleo, the 15.04 API is not stable yet ...
[10:06] <nik90> ogra_: well in our defense, the main focus now for the phone is to switch to vivid and this breakage just landed on vivid. Also aquarius's point here is that newer versions of the SDK shouldn't break apps that depend on older API
[10:06] <aquarius> the API shouldn't change. New versions can change, sure, but I'm not using the new versions.
[10:06] <ogra_> come back after thu ...
[10:06] <Elleo> ogra_: but the app doesn't use the 15.04 api it uses the 14.10 api
[10:06] <Elleo> ogra_: the problem is that changes in 15.04 break the 14.10 api
[10:06] <ogra_> uh oh !
[10:06] <nik90> ogra_: and also podbird uses 14.10 API
[10:06] <ogra_> ok
[10:07] <ogra_> ignore me then ... i didnt get that
[10:07] <aquarius> ogra_, this is like SRUing a breaking change into libpng and not changing the version number, so all your apps are suddenly using the new version and so break. :)
[10:07] <mivoligo> mhall119: ping
[10:08] <ogra_> aquarius, indeed ... and the released APIs are supposed to never change
[10:08] <aquarius> ogra_, no problem whatsoever with new versions of the SDK containing breaking changes; that's a good idea, and what version numbers are for. :)
[10:08] <ogra_> right
[10:08] <aquarius> ogra_, indeed they are not. However, that is not the case. See above conversation :-)
[10:08] <ogra_> i thought you guys were only talking 15.04
[10:09] <mcphail> on a related subject, does there need to be a specific Ubuntu namespace/naming convention for QML components?
[10:09] <aquarius> nope. You release an app today which adds a property called "ograColour" to your MainView, and in the next release of the SDK the SDK team decide to add a FINAL ograColour property... and your already-released, already-working app will break. This is why we're complaining :)
[10:10] <mcphail> aquarius: that's really what I was asking. Should official Ubuntu components and properties be prefixed?
[10:11] <aquarius> mcphail, actual Ubuntu UITK components are thus prefixed; they're in Ubuntu.Components
[10:11] <mcphail> aquarius: yes, but if Ubuntu add a AutoRangePicker it will break my AutoRangePicker
[10:12] <aquarius> mcphail, it shouldn't, because you aren't importing the new Ubuntu.Components version which includes it
[10:13] <mcphail> aquarius: maybe, but it might, at least, break when I have to use a newer version. If all components were prefixed with Ub_, I wouldn't have that problem
[10:13] <aquarius> that'd be really annoying, though
[10:13] <nik90> mcphail: but that would make all the public API ugly
[10:13] <nik90> imagine doing Ub_ListItem.Standard etc
[10:14] <aquarius> it is equivalent to your AutoRangePicker being called McP_AutoRangePicker, and way less intrusive
[10:14] <ogra_> mcphail, if you are scared you can just prefix your own function
[10:14] <mcphail> yes, true
[10:14] <nik90> mcphail, aquarius: Although, app devs could do this import Ubuntu.Components 1.1 as UT ... and then use UT.MainView{} etc.. etc ... but still one shouldn't have to do this
[10:15] <aquarius> but it'd also be way annoying for me to have to namespace all the properties I create *just in case* the SDK team decide they want to own that name at some point in the future
[10:15] <aquarius> which is why we are all complaining about breaking changes showing up in already-released versions :)
[10:16] <mhall119> mivoligo: pong
[10:16] <mivoligo> mhall119: grab it if you like it: https://sc-cdn.scaleengine.net/i/6018f5288b9679ee23f3c988b47f3b48.png
[10:16] <mcphail> nik90: I actually like that idea. It would namespace the components nicely, although probably not the properties?
[10:16] <mhall119> mivoligo: nice!
[10:16] <mhall119> thanks
[10:17] <mivoligo> mhall119: yw :)
[10:17] <nik90> mcphail: well you will be referring to properties by their parent id, so that should be ok
[10:17] <mhall119> mivoligo: what's your G+ profile URL?
[10:18] <mivoligo> mhall119: no idea
[10:18] <mivoligo> mhall119: name is  Michał Prędotka ;)
[10:19] <mhall119> ah, thanks, didn't know your IRC ;)
[10:19] <mivoligo> :P
[10:27] <ogra_> mhall119, why are you awake ?
[10:27]  * ogra_ is totally not used to these G+ posts at this time of day :P
[10:29] <aquarius> mhall119 is in London, I think :)
[10:29] <mhall119> yes I am
[10:32] <ogra_> thats no excuse :P
[10:33] <mhall119> and I have free unlimited coffee
[10:33] <mhall119> for definitions of "unlimited" that require hotel staff to periodically refill the pitcher
[10:36] <ogra_> now *that* is an excuse :)
[10:38] <popey> also, the definition of "coffee" is a bit loose
[10:40]  * DanChapman thought pitchers were for cocktails not coffee
[10:41] <ogra_> DanChapman, i think in the case of coffee it is "American Mug"
[10:41] <ogra_> everything is bigger over there :)
[10:41] <DanChapman> hah :-D
[11:04] <DF__> Hey guys
[11:05] <DF__> i just need some help with connecting to a Mysql database, can some here helpme out??
[11:06] <davmor2> popey: is it black and not tea?
[11:07] <davmor2> popey: if so then it's coffee :D
[11:08] <davmor2> popey: find the argentinian in the room and ask if they have any Mate :)  End of problem
[11:09] <popey> DF__: hiya
[11:09] <popey> DF__: we don't ship the mysql libraries on the phone I think
[11:09] <popey> DF__: you can make your phone read-write but that isn't a tested process (as I linked you to previously)
[11:09] <popey> DF__: are you developing an app to go in the store?
[11:10] <mzanetti> charles, hi there. is it expected that reminders notifications don't work at all any more in vivid? i.e. do I need to change anything in my code?
[11:13] <DF__> popey yes
[11:13] <DF__> popey: yes
[11:13] <mhall119> zsombi: you should probably attend http://summit.ubuntu.com/uos-1505/meeting/22406/themes-on-devices/
[11:14] <mhall119> since you're workign on the theme enhancements, right?
[11:14] <DF__> it's for a school project here in portugal, but i want it to release on the ubuntu store so every one here in portugal who has a ubuntu phone, can use it
[11:17] <mhall119> DF__: can you include the mysql binary (and libs) in your .click and use them that way?
[11:17] <mhall119> DF__: I'm assuming you're connecting to a remote instance of mysqld, not a local one
[11:17] <mhall119> if you are trying to use a local database, use the sqlite-backed LocalStorage QML component instead
[11:18] <DF__> nope, i have my DB on my localhost
[11:19] <DF__> i have 2 problems, wich are 1 connecting to my loclahost database and 2 install libqt5sql5-mysql on my phone
[11:22] <zsombi> mhall119: yes
[11:23] <zsombi> mhall119: could you pls file a bug with the "theme" property being visible in 1.2 UITK? pls...
[11:25] <mhall119> zsombi: sure
[11:28] <mhall119> zsombi: aquarius nik90 Elleo https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1447113
[11:37] <aquarius> mhall119, cool. I hope this is correctly seen as an example of the wider problem (that is: just fixing this one case isn't really a fix :))
[11:37] <mhall119> aquarius: that is my assumption, yes
[11:37] <mhall119> zsombi:
[11:37] <mhall119> ?
[11:38] <zsombi> what do you mean?
[11:41] <zsombi> mhall119: aquarius: if you mean that we won't only fix that particular property, but the whole toolkit, then yes, this will fix all 1.2 UITK stuff
[11:42] <aquarius> zsombi, yeah, that's what I meant -- this isn't fixed by, say, renaming the SDK "theme" property to "uitheme". It's a general problem that my apps will break if at any future point the SDK team invent a final property which I'd already used as a name :)
[11:43] <zsombi> aquarius: we never thought about renaming it to uitheme or anything else, we meant to fix it for 1.2 not getting any 1.3 properties
[11:43] <aquarius> zsombi, ah, I've just seen that you assigned the bug to yourself, cool. I was more worried that it might get picked up by someone who wasn't part of the above conversation :)
[11:43] <zsombi> aquarius: well, sorry, we cannot check what properties do apps declare when getting new APIs in...
[11:43] <zsombi> :)
[11:44] <aquarius> zsombi, I know you can't check -- and if I don't use the new APIs, there should be no conflict, is my point ;)
[11:44] <zsombi> aquarius: the thing with the theme not being FINAL is that if you override, it will break our theming
[11:44] <zsombi> yes
[11:44] <aquarius> totally agree that your properties should be final.
[11:45] <zsombi> aquarius: I'm already working on this.... it will get some time to get all the things separated properly
[11:45] <aquarius> that way, when I start using a version of the UITK with your property in, I can't override it. That's correct :)
[11:45] <aquarius> zsombi, cool :)
[12:35] <Elleo> nik90: merged your vivid fix; the new UITK header makes podbird look even better :)
[12:36] <nik90> Elleo: :)
[12:37] <nik90> Elleo: btw once greek language is 100% done, I think we can release.
[12:37] <nik90> Elleo: everyone whom I contacted have finished translating their language to 100%
[12:38] <Elleo> nik90: okay, cool
[13:05] <popey> hmm
[13:05] <popey> podbird 0.5 crashes on arale
[13:06] <Elleo> popey: latest vivid image?
[13:06] <popey> yes
[13:06] <nik90> popey: yes podbird crashes on devel-proposed..we have a fix in trunk for it
[13:06] <popey> ok
[13:06] <popey> \o/
[13:06] <popey> knew you'd be on it
[13:06] <nik90> popey: that's what we were discussing with aquarius and sdk devs and complaining loudly about it ;)
[13:07] <popey> hah
[13:07] <popey> i do like the new icon :)
[13:07] <nik90> yeah kevin did a really good job there with the visuals
[13:07] <Elleo> yeah
[13:11] <aquarius> I wonder if we'll have partisan camps based on who did the design. snwh vs Kevin: choose a side :-)
[13:12] <Elleo> heh
[15:03] <om26er> boiko, Hi!
[15:05] <davmor2> aquarius: designer Rap Battle, it's the only way to decide :D
[16:07] <om26er> mzanetti, Hello!
[16:08] <om26er> mzanetti, I tried to look into the reminders failure but didn't make much progress, partly because it looks like the issue is in the client code which I don't really understand.
[16:08] <om26er> re: bug 1444690
[16:08] <om26er> who is the best person I should talk to ?
[16:31] <bzoltan_> aquarius: nik90:  the sdk was reverted, so the problem should be gone
[16:32] <nik90> bzoltan_: is the new header style still landing in vivid though?
[16:42] <nik90> jhodapp: hey your playlist silo, does it have everything for apps to get playlist support? Or is some other additional work to be done?
[16:54] <jhodapp> nik90, it's just the backend support, still need to add the Qt/QML layer so client apps can take advantage of it
[16:55] <nik90> jhodapp: ah ok..put out a call when you want some testing done for it.
[16:55] <jhodapp> nik90, definitely will do so, I'm going to want a lot of testing
[16:56] <jhodapp> nik90, will most likely start on the next bit of work on this next week
[16:56] <jhodapp> nik90, maybe something to try by the end of next week at the earliest
[17:06] <nik90> jhodapp: cool
[17:46] <mzanetti> om26er, what's the client code?
[17:46] <mzanetti> om26er, my code or python-libthrift etc?
[17:46] <om26er> mzanetti, yours
[17:47] <mzanetti> mhm
[17:47] <om26er> mzanetti, the error probably comes from ttypes.py, doesn't it ?
[17:48]  * mzanetti reads the bug again
[17:49] <mzanetti> om26er, but wait...
[17:50] <mzanetti> om26er, that "raise errors.EDAMNotFoundException()" comes from the python stuff, doesn't it?
[17:51] <om26er> mzanetti, yes, the code comment there mentions that it will raise an exception if the note is not found on the server
[17:51] <om26er> mzanetti, initially we had been thinking this might be an issue in the CI lab wifi setup blocking staging server but later we were able to reproduce the issue locally as well.
[17:52] <om26er> mzanetti, do you know who wrote that test? the test seems to *not* really test anything (no asserts)
[17:52] <mzanetti> om26er, probably Carla
[18:36] <ant400468> hi all
[18:37] <ant400468> there is someone?
[18:38] <ant400468> i'm an holder of ubuntu phone
[18:38] <popey> hi
[18:38] <ant400468> and when try to run the first my html 5 app got an exception
[18:39] <ant400468_> hi all again
[18:39] <ant400468_> when i try to run the first my html 5 app got this excption
[18:40] <ant400468_> Errore irreversibile: /tmp/myhtml5app.ant400468_0.1_all.click failed to install. WARNING:root:Signature check failed, but installing anyway as requested Traceback (most recent call last):   File "/usr/bin/click", line 86, in <module>     sys.exit(main())   File "/usr/bin/click", line 82, in main     return mod.run(args)   File "/usr/lib/python3/dist-packages/click/commands/install.py", line 62, in run     package_path, us
[18:40] <ant400468_> every one can help me?
[18:41] <ant400468_> devices is connected and also emulator i think is okay
[18:41] <ant400468_> there is someone please?
[18:43] <ant400468_> hi all there is someone?
[18:51] <ant400468_> hi guys anyone can help to run run my first html 5 app for ubuntu phone? please?
[20:08] <nik90> rpadovani: ping
[20:09] <rpadovani> nik90, pong
[20:09] <nik90> rpadovani: hey, how do you build and run ubuntu-calculator-app in qtc?
[20:10] <nik90> rpadovani: for me it complains "could not find @APP_HARDCODE@ in the manifest file"
[20:11] <rpadovani> nik90, well, it's a pure qml app, you can run it from terminal, qmlscene app/ubuntu-calculator-app,qml. The error sounds a bit strange, I build a package a couple of weeks ago and used to work
[20:12] <nik90> rpadovani: I am trying this on 14.04, so cant run it on my desktop..I guess I can try building the click via the terminal...just strange though
[20:13] <rpadovani> nik90, oh, just tried on qtc on vivid, works fine. I don't have time to investigate right now, but I'll take a look, thanks
[20:13] <nik90> rpadovani: np
[20:15] <aquarius> popey, who does Shorts? Is that one of the core apps? If so, registering it at https://www.subtome.com/ might be cool
[20:28] <ilesteban> Hi all. I'm a qml/c++ newby, so be nice ;). I'm building my first ubuntu phone app, and I wanted to use TTS (text-to-speach). I found this library that does exactly what I need: http://bazaar.launchpad.net/~themuso/qml-speechd
[20:29] <ilesteban> The problem is that I don't know how to "include" this library as part of the app I'm building.
[20:29] <ilesteban> I was able to build the project locally, and install it. If I run the app I'm building in my desktop, everything works fine. After all, the .so is installed in my local.
[20:31] <ilesteban> But when I run the app inside an emulator, I got an (obvious) error saying that "module "Speechd" is not installed"
[20:31] <ilesteban> My question is: what should I do in these cases? Should I include the sources from qml-speechd in my project?? Or is there a better way to do this?
[20:39] <nik90> ilesteban: it depends on your project build type (Cmake or Qmake) where you need to specify where to install your "Speechd" module
[20:40] <nik90> ilesteban: and ofc build it for the armhf arch (phone) and i386 (emulator)
[20:44] <ant400468_> hi guys anyone can help to run run my first html 5 app for ubuntu phone? please?
[20:47] <ant400468_> hi guys anyone can help to run my first html 5 app for ubuntu phone? please?
[20:54] <ilesteban> nik90: But building the .so for the different architectures is something that has to be done outside my project right?
[20:54] <ilesteban> nik90: (I think Java has spoiled me... :P)
[20:56] <nik90> ilesteban: well if your cmake or qmake is set up properly, it will automatically build your click package for the architecture you specify
[20:56] <nik90> as a whole package
[20:57] <nik90> ant400468_: it looks like people familiar with html5 aren't around..
[20:57] <ilesteban> nik90: but the sources for speechd don't need to be in my same project, right?
[20:57] <nik90> ilesteban: it should
[20:57] <nik90> ilesteban: considering that speechd is not installed on the phone by default
[20:57] <ilesteban> hmm... interestig.
[20:58] <nik90> ilesteban: curious but why would it be outside your project?
[20:58] <nik90> ilesteban: it seems like a library that only your app seem to be using..so why would it already be shipped on the phone?
[21:00] <ilesteban> nik90: no reason :). Coming from Java, whenever I want to use a third-party lib in my project, the only thing I need is its .jar file present in my project (classpath). I thought that this was also true for qmake/cmake.
[21:00] <ilesteban> replace .jar to .so (and specific architecture)
[21:00] <nik90> ilesteban: well you could do it like that as well if you want
[21:00] <nik90> ilesteban: but you still need someone to give you that .so file for all necessary archs
[21:01] <nik90> ilesteban: while it would be easier considering you have access to the source to adjust your cmake/qmake file to build it for you on the fly when creating a click package
[21:01] <ilesteban_> correct
[21:02] <ilesteban_> nik90: but if you are saying that including the sources of the lib in my project is a good approach, I'm fine with that.
[21:02] <ilesteban_> It seems to be the easiest way
[21:03] <ilesteban_> nik90: thanks!
[21:03] <nik90> ilesteban_: yw
[23:46] <Elleo> nik90: http://i.imgur.com/xBjTh2n.png <-- we've just hit 1000 users :)
[23:49] <liuxg> how to hide the title bar in a Page in my QML app so that my app can take more space of the screen
[23:49] <nik90> Elleo: WOW!
[23:50] <nik90> liuxg: you can set the page title to an empty string to hide it
[23:51] <liuxg> nik90, oh, really? let me try it. thanks
[23:51] <nik90> liuxg: in Ubuntu.Components 1.3 new properties head.visible and head.locked will be made available to do it in a more official way
[23:51] <nik90> liuxg: the solution now is more a hack
[23:53] <liuxg> nik90, thanks. it really works. thanks for the tip  :) I am now on 14.10, so Ubuntu.Components 1.3 is not available to me :)
[23:53] <nik90> Elleo: I was just reading more about WorkerScript to improve the performance of Podbird while refreshing the listviews where the UI freezes for a few seconds
[23:54] <Elleo> nik90: yeah, I looked into that a while back and ran into some problems, can't remember what exactly
[23:54] <nik90> liuxg: well Ubuntu.Components 1.3 is not available to anyone yet...I believe Ubuntu.Components 1.2 will be available when the phone switches to vivid
[23:54] <Elleo> nik90: but decided that since it might be necessary to rewrite the networking/parsing stuff in C++ for compatibility with some servers anyway that it'd probably make more sense to just do some threading on that side
[23:55] <Elleo> nik90: iirc you can't access any of the localstorage stuff from a worker script, so you basically have to do the network operation in the worker, then pass all the xml back to the main thread for parsing
[23:55] <nik90> Elleo: true, but eventually that c++ plugin will write it into the sqlite database and in the qml side we will be reading the database and transferring it into a listmodel..I think that last part is also intensive
[23:56] <liuxg> nik90, yeah, it is true. thanks
[23:56] <Elleo> nik90: we can do the listmodel creation in a C++ thread though
[23:56] <nik90> Elleo: oh yeah that would help considerably
[23:57] <Elleo> nik90: whereas I don't think we can create the listmodel from the database directly in a workerscript due to that disallowing localstorage
[23:57] <nik90> Elleo: right now I had 15 podcasts subscribed to and on adding another one it froze the gui for like 2-3 seconds which doesnt look good
[23:57] <Elleo> nik90: yeah
[23:57] <nik90> I found an example online where they show the listmodel itself being populated inside the workerscript, but nothing yet with the localstorage
[23:58] <nik90> so I guess that can be a blocker
[23:58] <Elleo> nik90: you can't do any .imports from workerscripts
[23:58] <Elleo> nik90: they're very limited on purpose
[23:58] <Elleo> nik90: http://doc.qt.io/qt-5/qml-qtquick-workerscript.html#restrictions
[23:59] <nik90> ah yes
[23:59] <Elleo> nik90: there's also some nasty bugs in qml's xmlhttprequest implementation that it'd be good to avoid via the C++ implementation