[08:36] <karni> balloons: does click-buddy support (or are there plans to support) qmake projects?
[08:57] <sturmflut2> 84 additions/updates to the App Store over the last seven days \o/
[08:58] <DanChapman> \o/ awesome!
[09:00] <sturmflut2> In the past I usually installed every new app on my bq to test it, but it's getting too much to do that every morning
[09:01] <sturmflut2> On monday alone there were 27 changes
[09:04] <sturmflut2> If anybody is looking for a "weekend project", I think there could be some real value in a script that posts every change to the app store on social media. I even have most of the code in my app store RSS Feed generator
[09:05] <popey> thats been done
[09:05] <popey> https://twitter.com/uappexplorer
[09:06] <popey> well, i assume that's automated
[09:06] <popey> but there's not a lot of posts.
[09:10] <sturmflut2> popey: Oooooh
[09:12] <sturmflut2> Brian really deserves an award for all of this
[11:45] <kalikiana> brendand: ping, wrt https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1463925
[11:49] <brendand> kalikiana, need a review?
[11:51] <kalikiana> brendand: the branch isn't 100% done yet, and there's a bug that prevents the bits I have from working: on my touchscreen, under unity7, the touch input prints logs but never does anything
[11:51] <kalikiana> I was hoping you might have some ideas or suggestions on what to look for
[12:26] <brendand> kalikiana, i would say touch on desktop hasn't been tested much, so may just be broken :/
[12:26] <brendand> kalikiana, if you file a bug against autopilot with a clear test case we could have a look
[12:27] <kalikiana> brendand: I'm pondering doing this in 2 steps. I'll finish this branch to get rid of mode in all test cases. then a follow-up branch could enable using touch when touch is available
[12:28] <kalikiana> that would make lots of test cases where you'd see it
[12:48] <kalikiana> brendand: changed all instances of mode now that had do depend on the input type https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/autoPilotConverge/+merge/261658
[12:49] <kalikiana> the cases left are dealing with unity7 and testing the current hard-coded mode behavior for the input device
[13:24] <Elleo> does anyone have any pointers for debugging an app failing to launch, but not reaching a stage where anything is written to an upstart log file? (but can be launched fine from the command line)
[13:26] <kalikiana> Elleo: how about running it under X11 with no upstart?
[13:31] <Elleo> maybe, not sure I'd learn much from that which I don't already from launching from the command line though; since the X11 desktop file would have to basically be a copy of what I'm running on the command line, since it doesn't add any of the extra QML import paths and things that upstart does on the phone
[13:51] <nerochiaro> oSoMoN: do we have a way to get screenshots for the top sites ?
[13:52] <oSoMoN> nerochiaro, nope, we don’t
[13:52] <nerochiaro> oSoMoN: so in the wide view i am just going to put big black rectangles for now ?
[13:53] <oSoMoN> nerochiaro, that’s something we need to discuss with design: either we want placeholders with a favicon in the center (but that would result rather ugly I think), or we want a list view instead
[13:53] <nerochiaro> oSoMoN: james mulholland is our man, right ?
[13:53] <oSoMoN> nerochiaro, can you start the conversation with design (James and Rae) to get their opinion?
[13:53] <nerochiaro> oSoMoN: ok
[13:54] <nerochiaro> oSoMoN: and for the top bar used to choose between the top sites and bookmarks, is there a component from the SDK that can do it, or we just use custom stuff with abstract buttons ?
[13:54] <oSoMoN> nerochiaro, I don’t know, you’ll have to check with the UITK folks
[13:55] <nerochiaro> oSoMoN: ok, will do. was just a quick check in case you had an idea in mind already
[13:55] <nerochiaro> thanks
[14:02] <arcaneblast> hi
[14:57] <sturmflut2> Is there a full list of command line arguments that webapp-container supports? "webapp-container --help" is incomplete and there is no man page.
[14:58] <sturmflut2> Oh, --help lists more arguments when run on the desktop rather than on the phone
[14:58] <sturmflut2> o_O
[15:06] <dpm> popey, I think you looked into this a while ago. Could you add a comment with your findings on https://bugs.launchpad.net/ubuntu-clock-app/+bug/1324636 ?
[15:07] <popey> will take a look
[15:08]  * popey assigns self
[15:17] <brendand> kalikiana, my only question would be about the semantic difference between == Touch and != Mouse
[15:17] <brendand> kalikiana, are there more than two types? i can't think of any others
[15:25] <kalikiana> brendand: the difference is right now theoretical, you woudn't see if they were wrong unless we get another type of device
[15:26] <kalikiana> maybe kinect :-D
[15:26] <brendand> kalikiana, maybe some comments explaining the reasoning would be helpful?
[15:26] <kalikiana> brendand: well, those places all have comments
[15:27] <kalikiana> such as 'doesn't work on touch right now'
[15:27] <kalikiana> or select all not being implemented on touch
[15:28] <brendand> kalikiana, for example:
[15:28] <brendand> +        if base._get_input_device_class() == input.Touch:
[15:28] <brendand> 50	             raise NotImplementedError(
[15:28] <brendand> 51	                 'Drag does not work on the phone because of bug #1266601')
[15:29] <brendand> maybe a bad example
[15:29] <kalikiana> brendand: what would you add there?
[15:29] <brendand> but the text of the error should be changed
[15:29] <brendand> to not say 'phone' but rather 'touch input'
[15:30] <kalikiana> oh, good point
[15:38] <brendand> kalikiana, btw you need to request a review from either canonical-platform-qa or me specifically
[15:38] <brendand> oh no wait
[16:02] <dpm> thanks a lot popey
[16:40] <sturmflut2> http://sturmflut.github.io/ubuntu/touch/2015/06/11/how-to-run-standalone-html5-apps-on-an-ubuntu-device/
[16:41] <sturmflut2> I am actually surprised by how well even quite complex HTML5 games work on a device like the Aquaris E4.5
[16:46] <mzanetti> mardy, ping
[16:50] <daker> sturmflut2: yes thanks to oxide & the chromium upstream project
[16:51] <sturmflut2> daker: Jep!
[18:57] <mzanetti> rpadovani, hey, mind reviewing a reminders branch? https://code.launchpad.net/~mzanetti/reminders-app/enable-deleting-notebooks-and-tags/+merge/261774
[19:38] <nerochiaro> oSoMoN: pushed a few more tests to the keyboard branch (had dinner in the meantime)
[19:47] <oSoMoN> nerochiaro, thanks! I had dinner too, will now take a look
[19:49] <nerochiaro> oSoMoN: thanks
[19:57] <rpadovani> mzanetti, I'm going to take a look but... the delete api wasn't in premiumn apis only?
[19:57] <mzanetti> rpadovani, our API key got upgraded
[19:58] <mzanetti> not really premium, but we got access to those to methods
[19:58] <mzanetti> rpadovani, read the comments in notesstore.cpp
[19:59] <rpadovani> mzanetti, ah, I see, thanks
[20:00] <oSoMoN> nerochiaro, flake8 failure
[20:01] <nerochiaro> oSoMoN: what ? i could have sworn i had ran flake8 before committing
[20:01] <oSoMoN> we should probably have a commit hook that runs the unit tests :)
[20:03] <nerochiaro> oSoMoN: that's what i said :)
[20:03] <nerochiaro> oSoMoN: fixed
[20:04] <oSoMoN> nerochiaro, looking at the bzr documentation for hooks, it looks like the hook has to be installed locally in your bzr plugins dir, it doesn’t look like it can be local to the branch
[20:04] <nerochiaro> that's cool. checking flake8 is a good thing in general i suspect
[20:04] <nerochiaro> oSoMoN:
[20:05] <oSoMoN> yeah, you could have a general flake8 hook for all your branches, including those that don’t have a single bit of python code
[20:14] <rpadovani> mzanetti, seems it works, but minor issues: https://code.launchpad.net/~mzanetti/reminders-app/enable-deleting-notebooks-and-tags/+merge/261774/comments/655115
[20:15] <nerochiaro> oSoMoN: flake8 will probably be ok with it anyway
[20:16] <mzanetti> rpadovani, thanks
[20:16] <nerochiaro> oSoMoN: my head is a bit messed up by now, but i think that in Browser.qml when i check "if (!chrome.visible) return" i should really be checking "if (recentView.visible) return"
[20:16] <nerochiaro> oSoMoN: actually nevermind
[20:18] <oSoMoN> nerochiaro,  "if (!chrome.visible) return" is correct, as we also want to return if the history view is visible
[20:18] <oSoMoN> or if the settings view is visible
[20:18] <rpadovani> mzanetti, also, +            print("NetworkingStatus.online:", NetworkingStatus.online) it should be NetworkingStatus.Online (big O)
[20:18] <mzanetti> right... will fix
[20:19] <nerochiaro> oSoMoN: then a lot of that logic needs to be revised
[20:19] <oSoMoN> nerochiaro, why?
[20:19] <nerochiaro> oSoMoN: because the conditions in which shortcuts are allowed become harder and harder to read
[20:20] <nerochiaro> oSoMoN: ideally we should have a shortcut class with an enabled property, to make it clear when the shortcut can be triggered
[20:20] <nerochiaro> oSoMoN: or something more declarative like that
[20:21] <nerochiaro> oSoMoN: right now the whole code is becoming scarily imperative
[20:21] <oSoMoN> nerochiaro, right, that sounds like a potential good idea, not sure about the implementation details, but feel free to give it a go
[20:21] <nerochiaro> oSoMoN: well, not today as i have no more energy, and tomorrow i am out
[20:21] <oSoMoN> nerochiaro, ok, let’s keep it for next week then
[20:21] <nerochiaro> oSoMoN: you sure bill we be allright with it ?
[20:21] <nerochiaro> oSoMoN: he was in a rush to get this stuff merged
[20:22] <nerochiaro> oSoMoN: i personally think it is worth it
[20:22] <oSoMoN> nerochiaro, I think it’s fine if we do it on Monday
[20:23] <nerochiaro> oSoMoN: ok, i will think about the implementation tomorrow, maybe if i have time throw a sketch at you to see if it makes sense
[20:23] <nerochiaro> oSoMoN: thanks for all the reviews
[20:23] <oSoMoN> sounds good
[20:30] <rpadovani> oSoMoN, wrt historyUpdateOnLoadCommitted, you add onTitleChanged and onIconChanged because it's possible the title or the icon are loaded after the loadevent has been fired so you update history to have a favicon and a title anyway, right?
[20:31] <oSoMoN> rpadovani, let me read my code again, I need to refresh my memory
[20:31] <rpadovani> oSoMoN, https://code.launchpad.net/~osomon/webbrowser-app/historyUpdateOnLoadCommitted/+merge/259361
[20:32] <oSoMoN> rpadovani, yeah, that’s correct
[20:46] <rpadovani> oSoMoN, when I change the url, all connections to old server aro dropped? Could happen that a resource of the old site is loaded after the url is changed? Same thing for scripts: is the execution stopped in the same moment the url changes? (well, I expect it's so, just to be sure)?
[20:47] <oSoMoN> rpadovani, I would expect so, that’s a question for chrisccoulson
[20:49] <rpadovani> oSoMoN, anyway, looks good to me (apart if what I wrote above doesn't happen, because could result a strange history, but we have some worst problem if isn't all dropped when the page change)
[20:49] <rpadovani> oSoMoN, just a comment: https://code.launchpad.net/~osomon/webbrowser-app/historyUpdateOnLoadCommitted/+merge/259361/comments/655123
[20:51] <chrisccoulson> changing the URL doesn't change what's in the webview until the load gets committed (it's still possible to get events for the current page before that - including permission requests etc)
[20:51] <chrisccoulson> I'm not sure if that answers your question :)
[20:52] <oSoMoN> rpadovani, we don’t want to update the title if it has changed since it was last recorded, because some pages do this ugly trick to update the title continuously to achieve an ugly "scrolling title" effect
[20:52] <rpadovani> chrisccoulson, yes, thanks
[20:53] <chrisccoulson> I should point out - WebView.url shouldn't be used for any policy decisions anywhere in an application. It should only be displayed in the addressbar :)
[20:53] <rpadovani> oSoMoN, right, but maybe the title changes for another reason (like result of a game, it says 0-0, then 0-1, and so on). But I see your point there
[20:54] <oSoMoN> rpadovani, using the page title for this kind of information is wrong anyway, and we don’t want to update the history DB everytime there is a dynamic update of the title
[20:54] <oSoMoN> rpadovani, that’s consistent with how chromium behaves
[20:55] <oSoMoN> try e.g. browsing to http://htmlmarquee.com/title.html and open the history page
[20:55] <rpadovani> oSoMoN, okay, gotcha, let me just check a last case and then I approve it
[20:56] <oSoMoN> thanks
[20:56] <oSoMoN> rpadovani, I’m replying to your comment, for future reference
[20:57] <oSoMoN> (in case the question comes up again)
[20:57] <rpadovani> oSoMoN, but anyway the first time title is updated you update the history. I think you should add if(title){webviewInternal.storedTitle = title} in the onLoadEvent
[20:58] <rpadovani> or am I missing something?
[21:00] <rpadovani> oSoMoN, and plus you should the same check on Icon, because some sites (including Gmail) update the icon when you have a notification
[21:00] <oSoMoN> rpadovani, when we get the load event, it might be that the title hasn’t been reset yet, i.e. I’m getting a load event for page B but webview.title still has the value of page A’s title
[21:00] <rpadovani> *you should do
[21:01] <oSoMoN> rpadovani, in that case, we don’t want to set storedTitle, otherwise that would prevent the next valid title update from updating the db
[21:01] <oSoMoN> rpadovani, for the icon it’s a bit more tricky, but I don’t remember why now, let me scratch my head for a minute, it’ll come back
[21:03] <rpadovani> oSoMoN, mhh, about title: if title is valid when the onLoadCommitted is fired, then onTitleChanged isn't fired, and maybe it's fired after 10 minutes for another reason, and you're going to save the new title
[21:04] <oSoMoN> rpadovani, that’s right, but I have no way of knowing that, do I ?
[21:06] <rpadovani> oSoMoN, no, I don't have a better implementation in my mind atm, I'm just thinking to corner case about your code. If I've a better idea I'll say you
[21:08] <rpadovani> oSoMoN, don't get me wrong, I think it's better than the actually, and it's good enough to be merged. Only, it isn't perfect imo (but probably other brwosers have the same problem, because tometimes in history there are strange things)
[21:09] <oSoMoN> rpadovani, you’re right, I didn’t think it was that easy to update the favicon dynamically, but http://www.p01.org/releases/DEFENDER_of_the_favicon/ is a great example of how one can abuse this
[21:09] <oSoMoN> I’ll need a similar mechanism as for the title
[21:10] <oSoMoN> I’ll also add some comments to make the code more explicit
[21:11] <rpadovani> oSoMoN, also chromium on desktop saves also redirect (but I prefer our implementation on that)
[21:13] <rpadovani> oSoMoN, on chromium when the icon changes they update they icon in history but not the title, crazy guys: you could have the webmail icon with (3) unread, and title that says 5
[21:14] <oSoMoN> huh, are you sure they update the icon?
[21:15] <oSoMoN> oh, they do indeed
[21:15] <oSoMoN> that’s bad
[21:17] <rpadovani> oSoMoN, well, since chromium implementation is worst than ours, let's say you add a check for the icon update, then your MR is good enough to be merged IMO
[21:17] <rpadovani> oSoMoN, sounds ok?
[21:17] <oSoMoN> sounds good :)
[21:17] <oSoMoN> I’m adding the check for the icon, and will document it in a more verbose fashion
[21:17] <rpadovani> oSoMoN, also they don't update history in real time as we do, tsk, noobs :P
[21:18] <rpadovani> oSoMoN, great! Ping me when you've done
[21:18] <oSoMoN> rpadovani, well, it’s probably actually a good thing
[21:19] <rpadovani> oSoMoN, what? I mean, open a history in a tab, open a new tab, navigate to a new site, go to the history tab, the new site isn't shown
[21:19] <rpadovani> it sounds a bit strange
[21:20] <oSoMoN> rpadovani, is it eventually updated, or is it just that the history page is static?
[21:20] <rpadovani> oSoMoN, it seems static to me
[21:21] <oSoMoN> rpadovani, but if you reload the history page, the new entry appears, right?
[21:21] <rpadovani> oSoMoN, right
[21:21] <oSoMoN> rpadovani, I guess that’s only a limitation of having the history view implemented as a web page
[21:23] <rpadovani> oSoMoN, well, I think you can find a workaround for that, but anyway, not our problem :-)
[21:23] <oSoMoN> indeed
[21:35] <rpadovani> oSoMoN, wrt keyboard-shortcuts, the suggestions list works in a completely different way from chromium (and I prefer the chromium way) there is no way to use suggestions and continue typing. One of the thing I do on chroimium when I want to search on wikipedia is ctrl+t, type wi, a couple of times arrow down, url address becomes wikipedia because is suggested, then i type the voice I'm looking for
[21:35] <rpadovani> this isn't possible with the actual implementation of the keyboard shortcuts for suggestions
[21:36] <rpadovani> a possible way adding a shortcut (tab?) that injects the suggestion selected in the address bar. What do you think?
[21:36] <oSoMoN> rpadovani, I see what you mean, and you’re right, this is much more useful in chromium
[21:36] <oSoMoN> rpadovani, Ugo’s branch already makes it much better anyway, so I’d say we implement such an improvement in a second iteration
[21:37] <rpadovani> oSoMoN, okay. then as usability looks good to me, I take jsut a look to the code
[21:38] <oSoMoN> rpadovani, I pushed an update to my historyUpdateOnLoadCommitted branch
[21:38] <rpadovani> on it
[21:39] <mzanetti> rpadovani, all fixed
[21:40] <rpadovani> 5 minutes and I check :-)
[21:41] <rpadovani> oSoMoN,  I like the idea of the readonly property, it indeed improves a bit more the function! Approved :-)
[21:42] <oSoMoN> rpadovani, thanks
[21:58] <rpadovani> mzanetti, approved
[21:58] <mzanetti> rpadovani, thanks :)
[21:58] <mzanetti> rpadovani, if you are still in the mood, there's a new one by now :)
[21:59] <rpadovani> mzanetti, of course :-)
[22:00] <oSoMoN> rpadovani, I commented on https://code.launchpad.net/~rpadovani/oxide/type-info/+merge/260065
[22:01]  * oSoMoN is headed to bed
[22:01] <rpadovani> well, thanks :D
[22:04] <mzanetti> rpadovani, and one more :) https://code.launchpad.net/~mzanetti/reminders-app/fix-count-when-sorting/+merge/261785
[22:13] <rpadovani> mzanetti, on it, I left some comments on improve-edit-tags
[22:22] <mzanetti> rpadovani, cool, thanks a bunch
[22:55] <mzanetti> rpadovani, fixed
[22:55] <rpadovani> mzanetti, I finish another review and then I take another look
[22:56] <mzanetti> rpadovani, it's not urgent... you can also go to bed if you want :D
[22:57] <rpadovani> mzanetti, nah, I prefer sleeping in the morning now uni lessons are over :-)
[23:11] <rpadovani> mzanetti, approved but not top approved so we can have also popey's opinion