[04:57] <mihir> Good morning :)
[04:57] <mihir> nik90: Good morning :)
[06:10] <dpm> good morning all
[06:41] <mihir> dpm: Good morning :)
[06:48] <dpm> hi mihir
[06:48] <mihir> dpm: Hello :)
[06:50] <nik90_> dpm mihir: Good morning :)
[06:51] <dholbach> good morning
[06:51] <dpm> hey nik90_, morning. Good news: the Alarms API backend (eds) landed yesterday :)
[06:52] <nik90_> dpm: yes I read the irc chat. Awesome!
[06:53] <nik90_> dpm: regarding your email about the alarms notifications
[06:53] <mihir> dpm: we are almost done with our all bugs except one I guess
[06:53] <nik90_> dpm: I was not referring to the design but rather if the notifications actually work. So If set an alarm for say 08:00 AM, will I get a sound if the alarm goes off?
[06:53] <mihir> in calculator
[06:54] <nik90_> mihir: wow, congrats!
[06:58] <dpm> nik90_, gotcha. Yes, in any case, this will need design input. Apart from this bit, are you now unblocked in terms of the alarms API?
[06:58] <nik90_> dpm: I am actually 90% complete with the alarms branch.
[06:59] <nik90_> dpm: I am just bit worried that when my branch is merged to trunk, a user can actaully set and hear an alarm :)
[07:01] <nik90_> dpm: I am just fixing some last minute bugs and testing stuff before proposing merge. Zsombor already had a bried look at my code.
[07:01] <dpm> nik90_, indeed, we'll figure that out
[07:01] <dpm> that sounds awesome
[07:02] <nik90_> dpm: so email was charles kerr was correct?
[07:04] <dpm> nik90_ I don't know, I asked katie and she mentioned mpt was working on indicators, so I CC'd him. We'll find out
[07:05] <nik90_> dpm: okay. As long we get the answers, I am good
[07:06] <dpm> perfect
[07:27] <nik90_> zsombi: ping
[07:28] <zsombi> nik90_: pong
[07:29] <nik90_> zsombi: I created an alarm for 08:00 AM Daily. It saved it fine. However the time now is 09:28 AM. But when I retrieve the alarm.date, it still shows Wed 08:00 instead of Thurs 08:00
[07:29] <nik90_> zsombi: I created this daily alarm yesterday, so when saving it, it shows the correct date.
[07:30] <nik90_> zsombi: but now that the time has passed, shouldnt it update the date to point tomorrow same time?
[07:31] <zsombi> nik90_: not really. The alarm itself will always have the same date when created. The backend's responsibility is to schedule the occurrences based on the data given, relative to the start date
[07:32] <nik90_> zsombi: so I am guessing this is the same case for weekly alarms as well.
[07:32] <zsombi> nik90_: the order the alarm should be displayed is however the order of the occurrence, so if one occurrence expired, it should be placed to a later time
[07:32] <nik90_> zsombi: hmm, I am wondering how then i can find out the next closest active alarm. Previously I was reading the alarm.date and comparing it to the current date
[07:32] <zsombi> nik90_ yes
[07:33] <nik90_> zsombi: couldnt we instead making the backend update the alarm details automatically?
[07:33] <zsombi> nik90_: well, we can add an extra property to the alarm, called nextOccurrence
[07:34] <zsombi> nik90_: not really
[07:35] <nik90_> zsombi: will the nextOccurrence property update automatically?
[07:35] <zsombi> nik90_: will
[07:35] <nik90_> zsombi: can this be added then please? I need that to display certain strings like "Next Alarm in x hours" which depend on it.
[07:35] <nik90_> It isn't mission critical
[07:36] <zsombi> nik90_: however we don't have complete support for updates in all the circumstances, renato promised to implement that part too, so then we can keep it 100% in sync
[07:36] <nik90_> zsombi: ah okay
[07:36] <zsombi> nik90_: sure, need to add a work item to the BP, and we can see how we can schedule it, however seems a bit critical
[07:37] <zsombi> nik90_: so at the moment I can sync this field when fetching, but I don't get notified when the alarm is triggered, so I could update the alarm data. That needs to be done still in EDS backend
[07:38] <nik90_> zsombi: you mean you can sync this field every time I fetch the alarm details?
[07:38] <zsombi> nik90_: yes
[07:39] <nik90_> zsombi: my plan is run a qml timer every minute (when user is in alarm tab), so that would work
[07:40] <zsombi> nik90_: uhh.. no... the fetch is automatic, so whenever you check the model's alarm list, that will pull the same array. That array is updated whenever the backend says so...
[07:41] <zsombi> nik90_: then we also need a force fetch, but remember, that fetch is async, and actually it takes quite a bit of time with EDS backend... in some cases, especially when you have repeating alarms, that takes >20 sec!
[07:41] <nik90_> zsombi: woops okay :D
[07:42] <zsombi> nik90_: so then we need 2 things: nextOccurrence property and forced fetch support in the model.
[07:42] <nik90_> zsombi: so when EDS updates the array, my listview showing the alarms will then automatically update. Nice
[07:42] <zsombi> nik90_: yes, that's the way
[07:44] <nik90_> zsombi: is there a signal that I can catch when EDS updates the array (or refreshes my listview)? I need this to update my next closest active alarm display
[07:45] <zsombi> nik90_: the model itself does not have, however the QAbstractListModel does have
[07:47] <zsombi> nik90_: onDataChanged
[07:48] <zsombi> nik90_: no, sorry, it is onModelReset!
[07:50] <nik90_> zsombi: ah that works! thnx
[07:51] <zsombi> nik90_: if you want to display some ActivityIndicator suggesting that there's something ongoing, you can listen to onModelAboutToBeReset
[07:54] <nik90_> zsombi: thnx. So now the get_active_alarm() is called automatically when an alarm is changed either by the user or by EDS. This is much more reliable and resource friendly.
[07:54] <zsombi> nik90_: ;)
[08:07] <nik90_> dpm,popey: Any new updates on qtlocation qml documentation?
[08:37] <JamesTait> Good morning all, happy Hot Cross Bun Day! :-D
[09:06] <FooBarWidget> is this channel the right place for help with ubuntu packaging?
[09:24] <dpm> nik90_, not yet, sorry. In the meantime you might want to look here for an example:
[09:24] <dpm> http://qt.gitorious.org/qt/qtlocation/source/e31739e1b6d24616654b03d30bcdf6aeba037117:src/location/doc/snippets/declarative/declarative-location.qml
[09:24] <dpm> note that the repo is ahead of what we've got in Ubuntu, so you'd need to import QtLocation 5.0 and not QtPositioning
[09:25] <dpm> there are some unofficial docs here: http://qt.developpez.com/doc/5.0-snapshot/location-positioning-qml
[09:25] <popey> nik90_: yes!
[09:25] <nik90_> dpm: thnx will give it a shot
[09:26] <popey> nik90_: I spoke to mzanetti yesterday, he has a demo...
[09:26] <popey> http://paste.ubuntu.com/6087730/
[09:26] <nik90_> popey: ooh nice
[09:26] <mzanetti> ?
[09:26] <popey> http://paste.ubuntu.com/6087739/
[09:26] <dpm> nice!
[09:26] <dpm> nice work popey and mzanetti :)
[09:27] <nik90_> popey: does this work on phone and desktop? or just phone?
[09:27] <nik90_> mzanetti: thnx
[09:27] <mzanetti> nik90_: it crashes on the desktop :/
[09:27] <mzanetti> but it should run everywhere...
[09:27] <dpm> mzanetti, is the 'sudo start ubuntu-location-service' not supposed to be 'sudo service ubuntu-location-service start'? Or do both work?
[09:28] <mzanetti> dpm: AFAIK the "start <service>" is the new, shorter way. both should work
[09:28] <dpm> ok, nice to know, thanks!
[09:28] <nik90_> dpm: is that for the phone?
[09:28] <nik90_> ^^
[09:28] <popey> yes
[09:28] <dpm> yes
[09:28] <dpm> :)
[09:28] <mzanetti> but I'm not entirely positive... might work only for the user sessions, e.g. "start unity8" and for system services you still need the service <service> start
[09:28] <popey> but on the phone it should autostart now
[09:29] <popey> I have it autostarted here
[09:29] <mzanetti> popey, dpm: yesterday I've contacted some people and I think with the very latest image we have that running already and the apparmor policy is fixed too
[09:29] <popey> nice one
[09:29] <mzanetti> I'll do some last testing this evening and will upload GetMeWheels
[09:30] <dpm> cool
[09:30] <nik90_> popey: okay. Wow will try this after my late breakfast. Btw I tried phablet-flash cdimage-touch, but instead of grabbing the new new image, I think it installs the image that I downloaded when I got the phone.
[09:30] <popey> \o/ late breakfast
[09:31] <mardy> Saviq: hi! I have a D-Bus service which creates a QQuickView in response to some client request; the window is shown and works correctly, but if I swipe it away it doesn't appear in the "Recent apps" list, and therefore it's impossible to find it again
[09:31] <nik90_> popey: mostly brunch :)
[09:31] <popey> nik90_: "phablet-flash cdimage-touch" will download and install the most recent "blessed" / current image
[09:31] <mardy> Saviq: I created a desktop file for it, but it didn't help
[09:31] <popey> you can add --pending to get bleeding edge on it
[09:31] <nik90_> okay
[09:31] <mardy> Saviq: any ideas of what could be wrong?
[09:32] <Saviq> mardy, well, short-term solution - make sure it's started with --desktop_file_hint argument
[09:33] <Saviq> mardy, but this will soon stop working anyway - you'll have to launch it via upstart
[09:33] <Saviq> mardy, so that upstart authorizes the app to show a surface
[09:34] <Saviq> mardy, what's your use case?
[09:35] <mardy> Saviq: the Online Accounts UI: it can be invoked by the SystemSettings or by other applications, and it should appear as modal to the application invoking it (this doesn't work yet), but still the instances need to be aware of each other, not to edit the same accounts at the same time
[09:36] <mardy> Saviq: so I created a D-Bus service; it creates a QQuickWindow with the OnlineAccounts UI, when requested
[09:38] <Saviq> mardy, sounds pretty tricky, a) I'm afraid we didn't consider a process that would dynamically create a surface yet
[09:38] <Saviq> mardy, b) we can only do one surface per .desktop file atm
[09:39] <Saviq> mardy, c) I wonder how secure that would be (arbitrary surfaces appearing as modal to applications feels like a perfect way for spoofing passwords)
[09:39] <mardy> Saviq: I think that the .desktop file is a temporary workaround only; eventually, when we get window reparenting, the created windows will appear as part of the calling application, and not as separate tasks
[09:39] <Saviq> greyback, thoughts ↑?
[09:40] <mardy> Saviq: if (c) becomes an issue, reparenting could be mediated with apparmor, somehow
[09:42] <Saviq> mardy, yeah, possibly - for now, how difficult would it be for you to spawn a separate process for the new window?
[09:43] <mardy> Saviq: well, if we are talking about "for now", the --desktop_file_hint trick you suggested is good enough
[09:43] <greyback> mardy and I have asked for Mir to have  gain the surface parent idea
[09:43] <Saviq> mardy, not sure how long that will work, though
[09:44] <Saviq> mardy, but as long as you only create a single QQW and the whole service is started with --desktop_file_hint, it will work for *some* time
[09:44] <Saviq> greyback, yeah, that in itself is needed for a few reasons
[09:45] <greyback> indeed
[09:45] <Saviq> greyback, I'm just worried we haven't thought of how that would actually work in terms of "how do I know which surface I parent to" and "how do we know some app is not hijacking my password"
[09:46] <mardy> Saviq: in the long run the goal is to be able to create more windows (otherwise I wouldn't bother with the D-Bus service stuff), but for the time being we have no client apps making use of this, so it's all fine :-)
[09:46] <Saviq> mardy, yeah, of course
[09:47] <greyback> Saviq: i've not considered those things either tbh. Would need list of use cases where we need the idea
[09:47] <Saviq> greyback, it should be a safe for a process to have --desktop_file_hint and create surfaces dynamically, right?
[09:47] <mardy> Saviq: how to make sure that the issue is not forgotten? Do you want me to file a bug report?
[09:47] <mardy> Saviq: or will you write it in some blueprint?
[09:48] <Saviq> mardy, yes please, against unity-mir I think
[09:48] <greyback> Saviq: yep. desktop file only for the session. session can have multiple surfaces then
[09:48] <Saviq> greyback, i.e. it will only be considered for app management when the surface is actually created, not when the process starts
[09:49] <Saviq> greyback, it will be trickier with upstart, though (i.e. we might need more "sources" of authenticated surfaces)
[09:49] <greyback> Saviq: yes
[09:50] <greyback> Saviq: mir tells shell when a client connects to it, and naturally when it creates surface. Is only at that stage app is considered running, so app is then managed
[09:50] <labsin> I'm having troubles uploading my click app to https://myapps.developer.ubuntu.com/dev/click-apps. After choosing the click package to upload and pressing save, it keeps saying "0 seconds left" and doen't save.
[09:51] <Saviq> greyback, yup, but I mean that's when we'll ask upstart, if the app is auth'ed to display the surface
[09:51] <Saviq> greyback, but upstart won't know about mardy's DBus service
[09:52] <Saviq> greyback, so we need another way to authenticate it (which, btw, will probably be related to the fact that we want to parent that surface to an app's)
[09:52] <Saviq> greyback, probably an apparmor-protected interface for trusted services that can do that (online accounts, content management etc.)
[09:53] <greyback> Saviq: we don't authenticate individual surfaces right now, only the session/process that creates them. If shell can recognise that the dbus service is mardy's one, it will let it show whatever surface it wants. That is case right now
[09:54] <mardy> Saviq: I guess the issue is only with reparenting, right? We could say that only a few apps are allowed to use the reparening API
[09:54] <Saviq> greyback, yeah, I'm talking long term
[09:54] <mardy> Saviq: the API internally could try to create a file somewhere in the filesystem, and apparmor would block that if the app is not allowed
[09:54] <greyback> Saviq: yep, what you're saying makes sense in future
[09:54] <Saviq> mardy, not only with reparenting, but just the fact that a process wants to display a surface (connects to mir)
[09:55] <Saviq> mardy, will need to be authenticated
[09:55] <Saviq> erm
[09:55] <Saviq> authorized
[09:56] <Saviq> mardy, i.e. you won't be able to just launch any app from the console and expect it to show up - we need it mediated through upstart (if not for anything else - to match surfaces to app ids)
[09:56] <Saviq> otherwise we'd have to go the BAMF way all over again
[09:56] <mardy> Saviq: but most (all?) apps will have to display something, so why do we need to protect it at all?
[09:57] <mardy> apart from the case of an app opening 30 windows :-)
[09:57] <Saviq> mardy, that in itself is not really about protecting
[09:57] <Saviq> mardy, but just having one place (to rule them all) through which apps are launched
[09:57] <mardy> Saviq: ah, so it's about mapping a surface to a well-known app?
[09:57] <mzanetti> greyback: I get this one here: Shell.qml:78: Error: Unknown method parameter type: unity::shell::application::ApplicationManagerInterface*
[09:57] <Saviq> mardy, so that we have an authoritative mapping, yeah
[09:57] <mzanetti> greyback: shouldn't be registered by your plugin?
[09:58] <Saviq> mzanetti, greyback maybe is not registered with full namespace path?
[09:58] <Saviq> remember moc doesn't do well with namespaces?
[09:58] <greyback> mzanetti: no we don't register the interface at all, only the implementation
[09:58] <mzanetti> greyback: I guess we'd need to do that. where is the code?
[09:59] <mardy> Saviq: makes sense (though I'm not sure this belongs to upstart, it seems a task for the shell, IMHO)
[09:59] <Saviq> greyback, I think we need to register the interface too, 'cause otherwise you can't say "return *any* implementation of that"
[09:59] <Saviq> mardy, shell has an app manager that keeps that mapping indeed
[09:59] <Saviq> mardy, but the initial "oh, here's a surface, where's it coming from?" is answered by upstart
[09:59] <mzanetti> Saviq: actually... wouldn't it make sense to register interfaces in the shell itself?
[10:00] <mzanetti> Saviq: and only implementations in the plugins
[10:00] <greyback> mzanetti: qtubuntu (and unity-mir)
[10:00] <Saviq> mardy, as upstart is the only supported way to launch apps
[10:00] <Saviq> mzanetti, you mean like in main()?
[10:00] <mzanetti> Saviq: for instance, yes
[10:01] <Saviq> mzanetti, maybe
[10:01] <Saviq> mzanetti, but
[10:01] <Saviq> mzanetti, we'd need a plugin / library with them
[10:01] <Saviq> mzanetti, as right now interface in plugin a is not the same interface as in plugin b
[10:01] <Saviq> 'cause they're compiled separately
[10:02] <Saviq> plugin a == implementation a / plugin b == implementation b
[10:02] <mzanetti> but they implement the same interface
[10:02] <mzanetti> so it should be the same
[10:02] <Saviq> mzanetti, but they compile it separately
[10:02] <mzanetti> unless there's some version mismatch
[10:02] <Saviq> mzanetti, I think it's not matched just by its name
[10:03] <Saviq> mzanetti, I just think even gcc would complain
[10:03] <mzanetti> complain about what?
[10:03] <Saviq> mzanetti, if you had two separate compiles of the same source code and try to use them from each other as they'd be the same
[10:04] <mzanetti> maybe I'm wrong, but I would have assumed that works just fine
[10:04] <Saviq> mzanetti, what I mean is that if you register ClassA from ClassA.h in both plugin A and B
[10:05] <mzanetti> why would we do that?
[10:05] <Saviq> the objects would not be of the same class
[10:05] <Saviq> scratch that, simpler
[10:05] <Saviq> if you compile ClassInterface in the shell (to register it), and then compile it separately in a plugin
[10:06] <Saviq> I really doubt that an object of ClassInterface from the plugin would be an object of ClassInterface from the shell
[10:06] <mzanetti> saviq, we're not talking about objects here
[10:06] <mzanetti> Saviq: we register a type
[10:06] <mzanetti> and that is the same as long as the .h file wasn't changed
[10:07] <mzanetti> the actual object only comes from the implementation of the plugin. but follows the type which can be compiled wherever you want
[10:07] <mzanetti> maybe I'm missing something
[10:07] <nik90_> mzanetti: In case you are interested, on trying your code in the clock app (in desktop), I get the message Could not reference provider: The name org.freedesktop.Geoclue.Providers.Gypsy was not provided by any .service files/
[10:08] <nik90_> mzanetti: I think this is better than no output :)
[10:08] <mzanetti> nik90_: hehe, yeah. you should be able to get it running by setting up geoclue. but not sure if it's worth the efforts
[10:09] <Saviq> mzanetti, just try, I feel like that's not going to work, but feel free to prove me wrong
[10:09] <Saviq> mzanetti, I just feel like how can QML say that ClassA inherits InterfaceA to match the return type
[10:09] <Saviq> if they've been compiled separately (even from the same source - doesn't matter)
[10:10] <nik90_> mzanetti: yeah, but atleast the clock app does not crash when trying this in desktop making it viable for use on phone.
[10:10] <Saviq> ergh, like how does QML know that they were compiled from the same .h?
[10:10] <mzanetti> the same way it knows it right now
[10:11] <mzanetti> let me try
[10:15] <mzanetti> Saviq: ok... you're right... it doesn't produce the error message any more, but what I get is QObject(0x0)
[10:15] <Saviq> mzanetti, if it matched on class name or something I'd be scared ;)
[10:16] <Saviq> mzanetti, but sure, if we build a lib in unity-api
[10:16] <Saviq> mzanetti, and then link to that from the implementations
[10:16] <Saviq> mzanetti, that would work then
[10:16] <Saviq> there just needs to be a common binary where they live in
[10:16] <mzanetti> Saviq: yeah... I think way to go in the mid-term
[10:17] <mzanetti> for now I'm going to patch qtubuntu
[10:38] <dpm> bzoltan1, I don't seem to connect to the phone to deploy apps to it today. QtC detects the device and enables developer mode correctly, but when pressing Ctrl+F12 to deploy and run my app, I get a "ssh_exchange_identification: Connection closed by remote host" - any ideas what it could be?
[11:13] <dpm> zsombi, I'm trying to get a very simple QML example that displays the camera output occupying the whole phone screen (or at least all the space below the header). I'm not too sure how to do it, but I'm sure it's something trivial for you :) Where should I best specify anchoring and where width/height? -> http://pastebin.ubuntu.com/6092019/
[11:15] <zsombi> dpm: so you'd like to have it as "live" background for the MainView?
[11:17] <zsombi> dpm: is it so?
[11:18] <dpm> zsombi, essentially, yes.
[11:19] <dpm> zsombi, I'd like to show the header with the tab, but if that makes things difficult, I'd be happy to have the camera full screen, in the same way the camera app does
[11:19] <zsombi> dpm: well, in that case I'm afraid you cannot do it like this. You need to specify a style for the MainView as all the MainView content is re-parented onto an internal component which occupies only a portion of the MainView
[11:20] <zsombi> dpm: to my knowledge camera app doesn't have neither header nor tabs
[11:20] <dpm> zsombi, I know, I know, I meant only that the camera app is full screen
[11:21] <zsombi> dpm: ah, so you'd like to have it as background for the Tabs?
[11:21] <dpm> zsombi, yes. Alternatively, can I do it in a way that the camera output is shifted down the mainview the same number of grid units the header occupies? I'm not bothered about a portion of it being off-screen
[11:22] <nik90_> popey, dpm, mhall119: Feel free to test the alarm UI at https://code.launchpad.net/~nik90/ubuntu-clock-app/new-alarm-designs/+merge/183899. The alarm UI has been connected to the alarm manager with EDS integration. However the alarm will not actually ring yet to the platform notification support not being there yet.
[11:22] <nik90_> zsombi: If you have time, please do the honours of reviewing the branch.
[11:22] <popey> SWEEET!
[11:22] <popey> nik90_: will do
[11:22] <dpm> \o/
[11:23]  * popey runs adhoc_branch_build_run.sh lp:~nik90/ubuntu-clock-app/new-alarm-designs
[11:23] <zsombi> dpm: uhh... so: if you want to have the camera view to be under the whole app (also under header) you need to define it in a style component. If you want to have it under Tabs, you can put the Tabs as child of Camera {}, then anchors.fill Camera to its parent
[11:23]  * popey watches it appear on the phone
[11:24] <zsombi> nik90_: ah, thank you, thank you :)
[11:24] <popey> http://popey.com/~alan/device-2013-09-11-122420.png
[11:24] <popey> \o/
[11:25] <popey> http://popey.com/~alan/device-2013-09-11-122453.png
[11:25] <popey> nik90_: http://popey.com/~alan/device-2013-09-11-122513.png  can't see the text to label the alarm
[11:25] <popey> if I pull up it snaps back down
[11:26] <popey> http://popey.com/~alan/device-2013-09-11-122623.png  managed that kinda blind
[11:26] <nik90_> popey: yeah that's something affecting timer and alarm. Somehow I need to anchor the label to the OSK.
[11:27] <nik90_> popey: the workaround for now is to go in order. So set the time then label and then the options
[11:28] <popey> right
[11:29] <popey> looks great though! :D
[11:29] <popey> (needs a setting for only weekdays though)
[11:29] <popey> I don't need waking at 6am on Saturday
[11:29] <nik90_> popey: I think that can be implemented
[11:31] <dpm> zsombi, thanks I'll have a play with it, I need to see what makes sense in the app, I'll probably come back to you :)
[11:31] <zsombi> dpm: okay, good luck!
[11:32] <zsombi> guys, do you happen to know why was it decided so that MainView.backgroundColor chooses between Ambiance and SuruXXX themes?
[11:33] <zsombi> Saviq: ^
[11:35] <Saviq> zsombi, no idea
[11:36] <Saviq> zsombi, but I do remember something about a binding loop
[11:36] <Saviq> zsombi, bug #1204453
[11:36] <ubot2`> Launchpad bug 1204453 in Ubuntu UI Toolkit "Binding loop in MainView when using tabs in unity8 indicators" [High,Confirmed] https://launchpad.net/bugs/1204453
[11:36] <zsombi> Sabviq: yes, I found the cause (style change is applied in MainViewStyle, and then it is destroyed because of theme change...)
[11:53] <bzoltan1> dpm:  I have the same problem :(
[12:16] <danielholm> hey, is it possible to make a Composer Shett fill the whole parent?
[12:16] <danielholm> sheet*
[12:52] <rschroll> mzanetti: The way to refer to the user's home in the apparmor manifest is "@{HOME}" (obviously...).  Once I got that straightened out, those apparently unrelated errors went away, and my click package installed and worked!
[12:53] <mzanetti> rschroll: oh, cool
[12:53] <rschroll> Thanks again for the help!
[13:16] <rschroll> A question on U1db and XDG_DATA_HOME: If you create a database with a relative file path, U1db attempts to put it in $XDG_DATA_HOME.  When testing locally, a program run with qmlscene thinks this is ~/.local/share/Qt Project/QtQmlViewer/.  When running as a click package, this is still the case, but apparmor doesn't allow writes there; it expects XDG_DATA_HOME to be ~/.local/share/@{APP_PKGNAME}/.  Any ideas on how to fix this?
[13:30] <rschroll> And while y'all are considering that, is it possible for a click package to register to handle a mimetype?
[13:34] <dpm> rschroll, I don't think it's possible
[13:35] <dpm> kalikiana, you might be able to answer rschroll's question about U1db paths ^
[13:35] <mhall119> nik90_: so the platform side of alarms isn't working yet?
[13:36] <rschroll> dpm: OK.  Should I submit a feature request somewhere?
[13:38] <dpm> rschroll, you can, but to set the expectations, and given that click packages are supposed to be self-contained, I don't think it's likely to be implemented. In any case, you can do it here, and you'll get the authoritative answer from the click developers: https://bugs.launchpad.net/ubuntu/+source/click/+filebug
[13:38] <rschroll> Thanks
[13:45] <clepto> how can I delete my app's u1db locally?
[13:48] <clepto> dpm, ping
[13:49] <dpm> hi clepto
[13:49] <clepto> dpm, hi! ready to package! I'll follow this right? http://developer.ubuntu.com/resources/tutorials/getting-started/creating-click-packages-with-cpp-extensions/
[13:50] <dpm> clepto, yes, you can follow this, but you'll need to compile your extension for armhf first. Have you already done that/do you know how to do it?
[13:51] <dpm> bzoltan1, jppiiroinen, is "Build application on device" still working? I don't see any extra button on the Devices tab to set it up
[13:55] <boiko> timp: I have seen there were changes to the toolbar/panel
[13:56] <timp> boiko: yes
[13:56] <boiko> timp: but I think there might be a regression, I am trying today's image and I cannot open the toolbar at all
[13:57] <clepto> dpm, no I don't know how to build it for arm
[13:57] <timp> boiko: in gallery-app it works for me. in phone-app I cannot get a toolbar :(
[13:58] <timp> boiko: browser-app and notes-app also work fine
[13:58] <dpm> clepto, ok. I guess you're building it for the desktop atm. How are you doing it? Are you using stock qmake from Qt Creator, or cmake, or something else?
[13:58] <boiko> timp: address-book-app and messaging-app are  not working
[13:59] <timp> boiko: which image?
[14:00] <boiko> timp: I just flashed using cdimage-touch --pending
[14:00] <boiko> not the 5.1 one
[14:00] <timp> boiko: ok I have 20130910.2
[14:00] <clepto> dpm, I'm using qmake, but I never worked with qmake, hakermania did it for me (he is not here now)
[14:00] <timp> boiko: can you check other apps? gallery-app and the webbrowser?
[14:00] <boiko> timp: gallery is not working here either
[14:00] <timp> damn
[14:01] <timp> boiko: I'm downloading the 20130911.1 image now
[14:01] <boiko> timp: and on browser if I hide the toolbar, it does not show up again
[14:03] <timp> that's bad
[14:06] <timp> boiko: what's apt-cache policy qtdeclarative5-ubuntu-ui-toolkit-plugin on device?
[14:06] <bzoltan1> dpm: It is well hidden in th menus... but it is there "platform development environment"
[14:07] <boiko> timp: http://paste.ubuntu.com/6092618/
[14:08] <dpm> clepto, how do you currently build your extension? Do you have a separate project for it? Or do you have a single .pro file for both the QML code and the C++ code?
[14:09] <dpm> bzoltan1, I can't find it. Under which top-level menu is that option?
[14:09] <clepto> dpm, separate, you can see here the structure https://github.com/Clepto/cnotes-ubuntu-touch/tree/cnotes-ubuntu-one
[14:09] <timp> boiko: huh that is old and doesn't have my new toolbar changes
[14:09] <clepto> dpm, dirParserPlugin is the plugin
[14:09] <timp> bzoltan1: ^ do you know what's up there? boiko has toolbar problems in today's pending image with http://paste.ubuntu.com/6092618/
[14:09] <boiko> timp: so something else changed :)
[14:10] <boiko> timp: all autopilot tests that rely on toolbars are failing in the smoke tests too
[14:10] <bzoltan1> timp:  I am affraid that it is HUD issue
[14:11] <timp> like the touch detection of HUD blocking the bottom-edge-swipe in apps??
[14:12] <timp> bzoltan1: who can fix that? and how do you know its a HUD issue?
[14:12] <bzoltan1> timp: Wellark
[14:13] <bzoltan1> timp:  the bottom edge swipe? gee... that is not HUD, in that case I have no idea
[14:13] <timp> bzoltan1: I was just speculating. I just know that the toolbar is not working for boiko, and the image has an UITK package from 3 september
[14:15] <timp> bzoltan1: so version 0.1.46+13.10.20130903.4-0ubuntu1 is after my initial toolbar update, but also after reverting it..
[14:15] <bzoltan1> timp:  upgrade?
[14:15] <dpm> clepto, ok, it seems I can build it on the desktop by doing a:
[14:15] <dpm> qmake dirParser.pro
[14:15] <dpm> make
[14:16] <clepto> dpm, yes, its in the README
[14:16] <timp> boiko, bzoltan1 I have today's stable image (not pending), and it has the same UITK package version, and toolbars work fine for me.
[14:16] <dpm> clepto, let me have a look to see if we can use the https://wiki.ubuntu.com/Touch/CrossCompile instructions as a basis
[14:16] <clepto> dpm, ok, thanks!
[14:17] <timp> boiko: so something else must have changed also
[14:17] <boiko> timp: yes, probably
[14:19] <timp> boiko: did this change for you? https://pastebin.canonical.com/97355/
[14:19] <timp> boiko: do other interactions with the apps still work?
[14:20] <boiko> timp: seems to be the same version: 13.10.1+13.10.20130904-0ubuntu1
[14:21] <boiko> timp: everything else seems to be working fine
[14:22] <clepto> dpm, I'll be right back
[14:23] <timp> boiko: I don't know what's wrong :s
[14:24] <boiko> timp: a dpkg -l on the device in case you need: http://paste.ubuntu.com/6092701/
[14:26] <clepto> dpm, back
[14:31] <timp> boiko: hud seems the same also. I don't know what to look for...
[14:31] <boiko> :/
[14:32] <timp> boiko: do you know of a way to figure out what changed from today's stable image to today's pending image?
[14:32] <boiko> om26er: ^
[14:33] <om26er> timp, boiko you can look at the change in version numbers of packages in the .manifest file
[14:33] <om26er> http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20130911.1/
[14:34] <om26er> there is a .manifest file
[14:34] <om26er> boiko, how to clear sms logs in the messaging app ?
[14:34] <om26er> boiko, I am writing tests where i need to start fresh
[14:35] <boiko> om26er: remove (or move) the ~/.local/share/history-service directory
[14:35] <om26er> boiko, cool
[14:36] <iBelieve> nik90_, ping
[14:41] <timp> boiko: I have to go afk for about an hour, bbl.
[15:06] <timp> boiko: back. so < 1h :)
[15:06] <clepto> dpm, any progress?
[15:07] <timp> boiko: I wonder what can break the toolbar like that. It doesn't even show the toolbar hint when you touch near the bottom of the screen?
[15:08] <dpm> clepto, not yet, sorry, I've been in meetings since :/
[15:08] <clepto> dpm, no problem man, whenever you can!
[15:08] <timp> boiko: I wonder whether somehow pressed events are broken. Do you use that anywhere instead of clicked?
[15:18] <rschroll> A question about Page.flickable: I have a Page that usually has a single ListView, and the flickable property is set to that and everything's fine.  But in some circumstances, I want to display two listviews side-by-side on this page.  I think I should set Page.flickable=null in this case, so the header stays in place regardless of the scrolling of the listviews.  But when I do this, I have two problems: The listview gets a big margin at the t
[15:18] <rschroll> op, and its elements are visible through the header when scrolled.
[15:18] <rschroll> Here's a test case: https://gist.github.com/rschroll/6491639.  Am I doing something wrong, or is this a bug?
[15:28] <iBelieve> rschroll, I've experienced the same problem as a File Manager app developer. I'm pretty sure this is a bug
[15:29] <rschroll> iBelieve: Should it be submitted against ubuntu-ui-toolkit, or something else?
[15:39] <iBelieve> rschroll, Yes, you should submit a bug there because it's a bug with the code that handles the app header
[15:40] <timp> rschroll: the topmargin of the listview is updated automatically when it becomes the flickable of the page.
[15:40] <timp> rschroll: if you have flickable: null in the page, the margin will be gone.
[15:41] <timp> rschroll, iBelieve the cause is this code in the Page:
[15:41] <timp>         Binding {
[15:41] <timp>             target: page.flickable
[15:41] <timp>             property: "topMargin"
[15:41] <timp>             value: internal.headerHeight
[15:41] <timp>             when: page.flickable
[15:41] <timp>         }
[15:42] <timp> hmm.. seems like the value is not reset to 0 when page.flickable is null.
[15:42] <timp> rschroll: when you say flickable = null, you can try to add lisview.topMargin = 0;
[15:42] <rschroll> timp: Just a sec - I'll try
[15:44] <rschroll> timp: That does it for the margin; I still have the transparency issues
[15:48] <iBelieve> rschroll, set clip to true in your ListView
[15:48] <rschroll> iBelieve: fantastic - that does it.
[15:49] <rschroll> iBelieve, timp: thanks for the help!
[15:49] <iBelieve> rschroll, glad that works
[16:35] <boiko> timp: long press is working on the messaging-app
[16:36] <boiko> timp: there is no indication of the toolbar reacting to the swipe from bottom
[16:49] <karni> Hi guys, I've got a QML question. In a DashPreview, I have two buttons under "buttons: " section, and I can't reference any of these two. They have an id, but QML seems not to notice them.
[16:49] <karni> Any hints for a QML newbe? :)
[16:50] <karni> file:///home/phablet/shell/Dash/Music/MusicPreview.qml:214: ReferenceError: buttonIdHere is not defined
[16:50] <karni> I thought it was a forward reference problem, but same error occurs when I try to define property alias foo: buttonIdHere.text
[16:57] <karni> Figured it out the QML way. Used property binding.
[17:40] <daker> karni: the buttonIdHere element is not defined
[17:41] <karni> daker: you're telling me what I pasted, or you mean that ;)? because the button, with that id, *is* in that QML file :)
[17:42] <karni> That's the problem
[17:42] <karni> daker: in any case, I solved it with property binding, so I left that problem behind. thanks
[17:42] <daker> ok
[18:38] <hakermania> clepto, ping
[18:47] <clepto> hakermania, nevermind
[19:06] <nik90_> mhall119: to answer your question long time ago, the platform side does the organisation part but does *not* notify the user that an alarm has gone of
[19:12] <Chocanto> nik90_: Hey :) Did you see with the sdk team about the qml-file plugin ?
[19:13] <nik90_> Chocanto: no...What is the news?
[19:13] <nik90_> :)
[19:13] <nik90_> Chocanto: oh the meeting
[19:14] <Chocanto> nik90_: Yes :) To know what to do with this plugin :)
[19:14] <nik90_> Chocanto: No not yet I am afraid. People are quite busy to get a plugin merged at this time of the cycle.
[19:14] <Chocanto> nik90_: Yes.. I can understand them
[19:15] <Chocanto> nik90_: Ok, I will create a separate plugin so, thank you :)
[19:15] <nik90_> Chocanto: I think for now that's the way to go
[19:15] <Chocanto> nik90_: And it's the only way to go :)
[19:15] <nik90_> hehe
[19:16] <Chocanto> nik90_: And the docviewer isn't working currently, so... things have to be done fast ^^
[19:18] <nik90_> Chocanto: oh okay
[19:19] <nik90_> Chocanto: In that case, coordinate with mhall to get this packages as a separate plugin and merged into the repos.
[19:19] <nik90_> Chocanto: that's how the filemanager and music app have done things
[19:19] <Chocanto> nik90_: And that's how I have done in the past for the poppler plugin
[19:19] <Chocanto> nik90_: So 2 plugins will be needed to run the docviewer, wow ahah
[19:20] <nik90_> Chocanto: yeah :(
[19:20] <nik90_> Chocanto: but this is something which should take discussion early next cycle to avoid this
[19:21] <Chocanto> nik90_: Yes but we had no time to do this
[19:21] <nik90_> Chocanto: i knw
[19:21] <Chocanto> nik90_: But the most important is that this app will work
[19:50] <mhall119> nik90_: Chocanto: is this the file content reader plugin you guys made?
[19:50] <Chocanto> mhall119: Yes it is
[19:54] <mhall119> so we have two options, either we get it part of the "Ubuntu 13.10 Platform", or we package it separately in each of your app's click packages
[19:55] <Chocanto> mhall119: make it part of the Ubuntu 13.10 will need how many days ?
[19:55] <mhall119> Chocanto: we'll need to coordinate with the phablet engineers
[19:56] <mhall119> the good news is that, since it doesn't affect the desktop, we're not under the hard deadlines that we otherwise would be
[19:56] <Chocanto> mhall119: Yes but this plugin is needed for the docviewer
[19:56] <mhall119> popey: who should we talk to about getting these plugins to be part of the click platform?
[19:57] <Chocanto> mhall119: And I think the docviewer is under the hard deadlines
[20:02] <mhall119> pmcgowan: ^^ is the docviewer under FF rules?
[20:05] <pmcgowan> mhall119, would need to check on adding dependencies, but should be fine in universe
[20:06] <pmcgowan> mhall119, you can always include the deps in the click
[20:12] <rschroll> A repeat question on U1db and XDG_DATA_HOME: If you create a database with a relative file path, U1db attempts to put it in $XDG_DATA_HOME.  When testing locally, a program run with qmlscene thinks this is ~/.local/share/Qt Project/QtQmlViewer/.  When running as a click package, this is still the case, but apparmor doesn't allow writes there; it expects XDG_DATA_HOME to be ~/.local/share/@{APP_PKGNAME}/.  Any ideas on how to fix
[20:12] <rschroll>  this?
[20:15] <Chocanto> FF rules ?
[20:20] <asomething> are there any good examples for an app using ConditionalLayout from the SDK?
[20:21] <asomething> I've found a few doing custom stuff using things like "property bool wideAspect: width >= units.gu(80)"
[20:21] <asomething> but nothing actually using ConditionalLayout
[20:22] <asomething> I understand the basics, for instance I'm the one who gave this answer: http://askubuntu.com/questions/332519/can-a-single-ubuntu-sdk-target-touch-and-desktop-with-separate-layouts/340283#340283
[20:22] <asomething> but I'd like to look at a more complex example
[20:29] <iBelieve> rschroll, have you verified that u1db databases don't work on the phone? That's pretty serious. I was told that it should work just by using "<name>.db" as the path.
[20:31] <iBelieve> rschroll, see this discussion: https://plus.google.com/117574309170420884411/posts/JbD7qfdkeWE
[20:32] <iBelieve> nik90_, ping
[20:34] <rschroll> iBelieve: I have no phone to test this on, but this is what I'm seeing using a click installer on the 13.10 desktop
[20:36] <iBelieve> rschroll, according to Stuart Langridge in reply to my Google+ question, it should work out right on the phone.
[20:36] <iBelieve> rschroll, Awhile ago nik90_ said that my data wasn't being saved when the app got restarted, so I don't know if the U1db path used is right or not
[20:41] <rschroll> The path he gives is the same as I see used, and the apparmor profile does not give apps write access for files in that directory
[20:41] <rschroll> Unless it's different on the phone and the desktop.  (But why?)
[21:01] <balloons> iBelieve, did you get anywhere with the filemanager test failures? Any thoughts?
[21:09] <iBelieve> balloons, I don't understand why they're failing. The only one that failed for me is the open file test.
[21:12] <balloons> iBelieve, yes, I did see that even on the desktop
[21:15] <iBelieve> balloons, so the only time most of tests fail is on the phone, right?
[21:16] <balloons> iBelieve, it's failing in the jenkins VM as well
[21:21] <iBelieve> balloons, I don't understand why the tests fail in the VM or on the phone but not on the desktop. Is there any way to watch them being executed to see if the app doesn't look right?
[21:30] <balloons> iBelieve, yes there is
[21:30] <balloons> iBelieve, let me run trunk in the jenkins VM and you can see the video of the failures, ok?
[21:32] <iBelieve> balloons, that's cool that that is possible
[21:32] <ahayzen> mhall119, ping
[21:34] <balloons> iBelieve, you can watch it run here. 91.189.93.70:8080/job/generic-mediumtests/358
[21:38] <mhall119> ahayzen: pong
[21:39] <ahayzen> mhall119, u said a few meetings ago to let u know when the test cases were passing so u could enable something to force the tests to pass before a merge is done... did this ever get enabled?
[21:39] <ahayzen> mhall119, cause it appears tht the tests are passing http://reports.qa.ubuntu.com/smokeng/saucy/image/4157/music-app-autopilot/
[21:39] <mhall119> ahayzen: not that I'm aware of, are all of the tests passing now?
[21:40]  * ahayzen is checking the other devices
[21:40] <mhall119> balloons: who can enable the enforcement of tests?
[21:40] <mhall119> for music app
[21:40] <mhall119> since they're all passing now
[21:41] <ahayzen> mhall119, don't think the Nexus 10 is passing?
[21:41] <ahayzen> mhall119, will it only be the Nexus 4 tht it is enforced on?
[21:42] <ahayzen> mhall119, nexus 4, 7, galaxy are passing but the 10 is failing :/
[21:43] <mhall119> ahayzen: that I don't know, balloons or fginther are the folks to talk to about that
[21:44] <ahayzen> systemsettle before/after were the ones tht failed http://reports.qa.ubuntu.com/smokeng/saucy/image/4158/music-app-autopilot/
[21:49] <clepto> mhall119, to whom should I talk about packaging?
[22:01] <rschroll> Any hints on icons for click packages?  I can only get it to work if I give an absolute path.  Is there a better way?
[22:18] <labsin> rschroll, I got told to use "icon=<icon name>.png" in the desktop file. It doesn't show up right in the dash with me, but I think it's a bug. click apps that are released don't show up ether.
[22:19] <rschroll> labsin: Thanks. Do you (or anyone else) happen to know if SVG files are acceptable.  (They are on the desktop.)
[22:20] <labsin> rschroll, No clue. Wanted to know that too.
[22:20] <labsin> I have no Ubuntu touch supported phone :/
[22:21] <rschroll> labsin: Same here.  Makes this whole process sorta nebulous.
[22:37] <mhall119> clepto: depends on your question
[22:37] <mhall119> clepto: what do you need help with?
[22:38] <clepto> mhall119, cross compiling, but I might need help in general regarding packaging
[22:38] <clepto> mhall119, my app is ready! :D bugfree I believe (so far)
[22:40] <mhall119> clepto: xnox I think can help you with cross compiling
[22:40] <clepto> mhall119, thanks
[22:40] <clepto> xnox, ping