[11:00] <lpotter> why are some windows full screen and others are just a slice on the right side on tablet? it's confusing and annoying
[11:00] <lpotter> is that a bug or feature?
[11:02] <davmor2> lpotter: it's sidestage it is phone sized apps open in it and then you can have for example webbrowser and notes open together on one screen
[11:04] <lpotter> it seems random and confusing
[11:41] <faenil> how do I change display resolution in unity8 on desktop? :/
[11:42] <faenil> lpotter: I think at the moment it's the app that specify its sidestage behaviour using special tags in .desktop
[11:42] <faenil> but the future is "all apps should be able to switch to fullscreen or sidestage"
[11:42] <faenil> not sure about that though
[12:18] <flux__> faenil, right X-Ubuntu-StageHint=SideStage
[12:19] <flux__> yay libertine updates
[15:04] <mterry> ltinkl, I just noticed that the silo finished building sometime yesterday  :)
[15:11] <mterry> tedg, the debian/libubuntu-app-launch2.symbols file needs updating in your app-object branch to include all the c++ api
[15:12] <tedg> mterry: Ah, yeah.
[15:12] <tedg> mterry: Is there an easy way to get the c++ symbol list?
[15:12] <tedg> mterry: Usually for C I just look at the diff that the deb packaging stuff prints out.
[15:13] <mterry> tedg, fakeroot dh_makeshlibs | sed -e 's/^\+ \(.*\) \(.*\)/\+ \1 0replaceme/' -e 's/\([+-]\) \(_.*\) \(.*\)/\1 (c++)"\2" \3/' | c++filt > /tmp/diff_for_symbols
[15:13] <mterry> tedg, from https://wiki.ubuntu.com/DailyRelease/FAQ
[15:13] <tedg> mterry: Sweet, thanks!
[15:24] <mterry> tedg, http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/modules/Unity/Application/desktopfilereader.h
[15:24] <mterry> tedg, that's the list of info we pull from desktop files
[15:24] <mterry> tedg, read http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/modules/Unity/Application/desktopfilereader.cpp for the actual keys read that correspond to that API
[15:24] <tsdgeos> cimi: you can see in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-054/+packages it's still being buit
[15:24] <tsdgeos> built
[15:25] <tedg> mterry: Really? What do you guys use exec() for?
[15:28] <mterry> tedg, ... seemingly nothing I could find.
[15:28] <mterry> tedg, skip that one for now.  maybe we used it in a hack in the past
[15:28] <tedg> mterry: K
[15:30] <flux__> X-( https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1535058
[15:36] <mterry> tedg, we do have some code that supports legacy ways of launching apps in qtmir -- those do check the process's command line and try determining desktop file from desktop_file_hint and parse it
[15:36] <mterry> and stage_hint
[15:37] <mterry> tedg, how common is that these days?  Can we just drop it?
[15:37] <mterry> tedg, we have two special checks for maliit-server and qt5/libexec/QtWebProcess
[15:37] <tedg> mterry: I think we can just drop it, I don't know of any users of it today.
[15:37] <tedg> mterry: We should probably ping someone like greyback or Saviq to see if they know.
[15:37] <flux__> i use -- --desktop_file_hint=
[15:38] <tedg> flux__: For what?
[15:38] <flux__> to launch apps
[15:38] <flux__> doh
[15:42] <faenil> mzanetti: has anyone started looking at https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1535058 ?
[15:42] <faenil> we need to usertest core apps, but if unity8 doesn't cooperate... :|
[15:53] <faenil> Saviq: ^
[15:54] <oSoMoN> greyback, hey, have you had a chance to take a look at https://code.launchpad.net/~osomon/qtubuntu/qkeyevent-native-virtual-key/+merge/282515 ? or will you have some time to look at it soon-ish ?
[15:56] <greyback> oSoMoN: I'll get dandrader to have a look
[15:57] <greyback> it looks reasonable
[15:57] <oSoMoN> thanks!
[16:15] <mzanetti> faenil, don't think so
[16:19] <faenil> mzanetti: isn't it, like, super critical? XD
[16:19] <faenil> no apps start, at all :D
[16:19] <mzanetti> what?
[16:20] <faenil> mzanetti: have you read the bug? :D
[16:20] <mzanetti> oh, I thought it'd be the one where they stop when launched directly after closing
[16:21] <flux__> mzanetti, no! they don't launch at all
[16:21] <flux__> X-(
[16:21] <faenil> mzanetti: no, they don't launch at all, this is another bug
[16:24] <oSoMoN> dandrader, remember bug #1459362 ? I could use your help in understanding why a bunch of touch events go to the item below a SwipeArea before a drag is detected
[16:25] <dandrader> hmm
[16:28] <dandrader> oSoMoN, oh, so you got a minimal test app. good progress
[16:28] <oSoMoN> dandrader, yeah, it’s much easier (and more urgent too) now that SwipeArea is a public component :)
[16:44] <Saviq> @unity: I either broke Unity8 CI, or I made it faster, we'll find out soon ;)
[16:44] <dandrader> oSoMoN, commented on the bug
[16:47] <oSoMoN> dandrader, thanks, I commented back
[16:47] <mterry> tedg, in you app-object branch, does IconPath ever be relative (i.e. a theme icon name)?
[16:49] <tedg> mterry: Right now I'm just passing what the desktop file has.
[16:49] <tedg> mterry: I've debated about that, but icon themes is kinda a pain.
[16:49] <mterry> tedg, looks like you make a full path out of what the desktop file has..
[16:49] <tedg> mterry: But I think we're gonna have to handle that, because you wouldn't know the data paths for the libertine icons.
[16:49] <tedg> mterry: More meaning of resolving the icon themes than full/relative
[16:50] <tedg> Paths are easy, icon themes are not :-)
[16:50] <mterry> tedg, right...  But we presumably need icon theme support -- we don't know size we want ahead of time
[16:50] <faenil> dandrader: oSoMoN since you're talking about letting events through
[16:51] <faenil> dandrader: oSoMoN please take into account that you might have a scrollbar on any edge of the screen, and the scrollbar is draggable even on touch when the content is > 10 pages
[16:51] <mterry> tedg, something like if (fullPath) { return iconPath; } else { return "image://theme/" + iconPath; } is what I would expect me to do in qtmir (or UAL to do itself)
[16:52] <faenil> dandrader: oSoMoN so the shorter delay before scrollbars gets events, the better...at the moment I see a big delay between the moment I drag the scrollbar and the moment it actually moves, and I'm thinking it's because swipearea is blocking events at the beginning while it's deciding if it's a drag
[16:53] <oSoMoN> faenil, in the case of the browser we should be safe, as oxide’s scrollbars are not draggable
[16:53] <dandrader> faenil, because that app that has scrollbars doens't know how to handle touch cancelation events, thus unity8 has to withhold the touch events until it's sure it's not a drag
[16:54] <dandrader> faenil, sending touch/gesture cancellation events to apps hasn't been done yet.
[16:56] <faenil> dandrader: wait, I don't get it. Who should be sending touch cancel?
[16:56] <dandrader> faenil, unity8
[16:56] <dandrader> faenil, if the SwipeArea in question live in unity8, that is (the left, right and top edges)
[16:57] <dandrader> s/live/lives
[16:59] <tsdgeos> cimi: silo 54
[17:00] <cimi> tsdgeos, yeeep
[17:00] <faenil> dandrader: so, let's assume the usecase is the user is trying to grab the scrollbar
[17:00] <faenil> what do you see as flow of events?
[17:01] <faenil> swipearea will get the events first, right? because it's in unity
[17:01] <faenil> i.e. on top of everything
[17:01] <dandrader> faenil, yes
[17:02] <faenil> so, how do you see that working good while the user is trying to grab the scrollbar?
[17:02] <faenil> working well*
[17:03] <dandrader> faenil, Then unity8 has a TouchGate in front of the app window which will withhold touch events from it until it's notified that the app has gained ownership over then (because the SwipeArea decided the touch is not performing a drag)
[17:03] <faenil> exactly, so, swipearea has to decide that it's not a drag first. But that's what I see happening,
[17:03] <faenil> the scrollbar gets events with a big delay at the beginning
[17:04] <tedg> mterry: Sorry, got distracted. The problem is that you don't know the icon theme search path.
[17:04] <tedg> mterry: And there could be a bunch of icon them roots.
[17:04] <faenil> and I just wanted to let you guys know that and see if we can find a better solution, because the delay is suboptimal
[17:04] <tedg> mterry: So you need to effectively adjust your XDG_DATA_DIRS to match those roots.
[17:04] <dandrader> faenil, no way around it unless the app is able to touch cancellation events. but we don't have written support for it yet
[17:04] <tedg> mterry: Which is kinda sucky.
[17:04] <dandrader> faenil, no way around that delay near the edges, I mean
[17:04] <faenil> dandrader: I still don't see why touch cancellation would improve that
[17:05] <mterry> tedg, like a libertine app might have a whole icon theme inside it?
[17:05] <mterry> tedg, so we need rooted icon themes?
[17:05] <dandrader> faenil, but mouse events are not delayed. so dragging a scrollbar near the screen edge is immediate
[17:05] <tedg> mterry: No, the libertine container would. And we'd have potentially multiple containers.
[17:05] <mterry> tedg, oh one global container?
[17:05] <tedg> mterry: So think that you could have a vivid and a trusty one.
[17:05] <mterry> ah right
[17:05] <tedg> mterry: Or three vivid ones, just for fun.
[17:06] <faenil> dandrader: but mouseevents are only synthesized from touch if touch is not handled
[17:06] <mterry> tedg, so we *could* modify our icon lookup code to look in those.  but we really only want to do that if the app is from that container
[17:06] <faenil> dandrader: I'm talking about draggin scrollbar with a touch device, mind you
[17:06] <faenil> we're talking about touchscreen
[17:06] <mterry> tedg, you could give us something like image://libertine-theme/container-name/icon-name
[17:07] <mterry> tedg, and adjust the icon lookup parser to understand that
[17:08] <tedg> mterry: Yeah, so the issue I ran into there is that it seems that the Qt code for icon theme lookup is kinda singleton based. Which makes sense for /usr/share/icons …
[17:08] <dandrader> faenil, let me rephrase: " but mouse events are not delayed. so dragging a scrollbar near the screen edge with a mouse is immediate"
[17:08] <tedg> mterry: So we end up chasing down the rabbit hole
[17:10] <faenil> dandrader: I got that...but the only way to get mouse events is to get events synthesized from touch events, and that won't happen until swipearea lets them through
[17:10] <faenil> right?
[17:10] <faenil> because whenever you use the touchscreen to grab the scrollbar, swiparea grabs touch
[17:11] <mterry> tedg, well...  for Ubuntu SDK apps, we must end up pointing at a single icon right?
[17:11] <mterry> tedg, maybe libertine apps can just give us a single icon too
[17:11] <faenil> dandrader: oh I missed the point you edited. Yeah, it will be immediate with mosue
[17:11] <mterry> tedg, but maybe still allow desktop files to use a icon theme name, since it's technically permissible
[17:11] <faenil> mouse*
[17:12] <dandrader> faenil, I'm not talking about synthesizing mouse events out of touch events. I was talking about mouse events coming from an actual mouse device
[17:12] <tedg> mterry: Yeah, so perhaps we'll solve the icon theme situation just in the libertine case and give themes in the legacy root case.
[17:12] <mterry> tedg, when they are on the system
[17:12] <dandrader> faenil, yes
[17:12] <faenil> dandrader: ok, we don't care about that ;)
[17:12] <mterry> tedg, yeah
[17:12] <tedg> How many apps do we have installed as debs? Just system-settings?
[17:12] <faenil> dandrader: we care about improving the touch UX :D anything I or you can do
[17:12] <faenil> ?
[17:12] <dandrader> faenil, nothing you can do about that delay near the screen edges
[17:12] <mterry> tedg, more but I don't remember list
[17:13] <mterry> tedg, like 5 or less
[17:13] <mterry> 5 or fewer  :)
[17:13] <faenil> dandrader: alright..
[17:14] <dandrader> faenil, to solve that we (unity8 team, maybe mir team as well)  have to implement detecting support for touch cancellation from apps and sending them if the do support it
[17:14] <faenil> dandrader: again :D please explain how touch cancellation would improve that, because I Don't get how
[17:14] <tedg> mterry: Looks like on my phone: dialer, mediaplayer, messaging, system settings and browser.
[17:14] <dandrader> faenil, and then for apps to change their code to handle touch cancellation if they want to get rid of that delay
[17:14] <mterry> tedg, 5!  bam
[17:15] <tedg> mterry: Curious if we can just change those to not use icon themes :-)
[17:15] <faenil> dandrader: why should unity send a touch cancellation if swipearea is still thinking what do with the events?
[17:15] <mterry> tedg, stop trying to kill icon themes
[17:15] <dandrader> faenil, no
[17:16] <dandrader> faenil, unity8 would send touch events to app immediately, even though unity8's edge swipeArea is still doing gesture detection
[17:16] <dandrader> faenil, then, if unity8's edge SwipeArea decided that this is an edge drag gesture, unity8 would send a touch cancellation event to the app
[17:16] <faenil> dandrader: ah okay! yeah, then I get you of course
[17:17] <dandrader> faenil, meaning that the app would no longer get evens from that touch point and that it should undo any changes caused by that touch so far
[17:17] <faenil> sure, sure
[17:17] <faenil> I misunderstood you before
[17:18] <faenil> I didn't see how it could work with the current swipearea, and in fact it wouldn't. Once unity8 starts handling that, swipearea impl will have to be changed as well
[17:18] <faenil> to let events through from the beginning
[17:18] <faenil> and then unity8 will send touchCancel if needed
[17:18] <dandrader> faenil, please file a bug requesting support for gesture cancellation to apps and stating why you need that (eg those touch-operated scrollbars)
[17:18] <faenil> dandrader: right?
[17:18] <dandrader> faenil, so we can properly prioritize that work
[17:19] <dandrader> faenil, or actually, the bug should be simply about complaining that touch events near edges come with a delay
[17:20] <faenil> I have to test that a bit better before filing it, once I'm pretty sure it's swipearea's fault I'll file it
[17:20] <dandrader> faenil, sending gesture cancellation to apps is orthogonal to SwipeArea implementation
[17:20] <dandrader> faenil, those are two separate things
[17:20] <faenil> dandrader: yes, I get that
[17:20] <faenil> dandrader: I'm talking about letting events through from the beginning
[17:21] <dandrader> faenil, in unity8 code, TouchGate in SurfaceContainer.qml is the one withholding the touch events from the app
[17:21] <faenil> once unity8 handles touchCancel, swipearea still needs to be modified to let events though from the beginning, right?
[17:21] <faenil> ah ok
[17:21] <faenil> I'll have a look at that then, thank you
[17:21] <dandrader> faenil, read TouchGate's documentation
[17:21] <faenil> yeah then TouchGate will have to be modified. I thought it was swipearea itself blocking them
[17:21] <faenil> ok
[17:21] <faenil> will do
[17:27] <cimi> pstolowski, hey, can you send me/link me the scope with the filters? (click pkg)
[17:29] <pstolowski> cimi, lp:~stolowski/+junk/scope-filters in click/ folder
[17:30] <dandrader> faenil, no. what has to be done is that SurfaceContainer won't put a TouchGate in front of the app surface if the app surface tells us it support gesture cancellation
[17:31] <dandrader> s/support/supports
[17:31] <faenil> dandrader: yeah, clear now that I've read TouchGate's (short) doc
[17:31] <faenil> :)
[17:31] <faenil> and that explains what I was seeing as well
[17:31] <faenil> all events are stored and replayed
[17:32] <dandrader> faenil, only the ones for which ownership hasn't been solved yet, which are the ones that go through those SwipeAreas that unity8 have near screen edges
[17:32] <faenil> dandrader: yes
[17:32] <faenil> yes
[17:33] <mterry> patriciadavila, can you point me to the spec for how the dash is supposed to look / behave in windowed mode?
[17:34] <faenil> dandrader: so I guess SwipeArea doesn't get ownership until it's sure it's a drag
[17:34] <dandrader> faenil, yes
[17:34] <patriciadavila> mterry: this is the presentation that describes the journeys - https://docs.google.com/presentation/d/1uSTcU-My6VD94BEISs_Y30O-mJG26I_czuXCKI4BzFQ/edit
[17:34] <patriciadavila> mterry, we'll have a session about this tomorrow, you are welcome to join if you have any questions
[17:35] <mterry> patriciadavila, I have one question -- not about the content of the scopes window, but about the window itself -- like close / minimize / maximize buttons
[17:35] <mterry> patriciadavila, which should it have / how should they behave?
[17:37] <patriciadavila> mterry: maybe vesar can help you better with that? The dash window should have/behave like any other window afaik
[17:40] <oSoMoN> dandrader, pardon my ignorance wrt touch even handling, what sort of event/notification do we get when a touch is grabbed by a SwipeArea?
[17:41] <faenil> oSoMoN: I'm pestering him already :D
[17:41] <mterry> patriciadavila, asked him, thanks
[17:43] <oSoMoN> dandrader, faenil: shouldn’t we be getting a TouchCancel event, or something like that?
[17:43] <patriciadavila> mterry: yw
[17:43] <faenil> oSoMoN: if I understood correctly, in the current state of things you won't get events until SwipeArea decides you shall
[17:44] <faenil> and at that point, you'll get all of them at once, in the correct order
[17:44] <faenil> that is because there's TouchGate in unity8 that prevents the touch events from getting to the app
[17:46] <faenil> in the ideal future, the app will signal that it can handle touchCancel (I think this should always happen, not on demand), and unity8 will remove TouchGate
[17:46] <dandrader> oSoMoN, http://doc.qt.io/qt-5/qquickitem.html#touchUngrabEvent
[17:46] <faenil> at that point, both the app and SwipeArea will get the touch events, but if SwipeArea then decides that it has detected a drag, it will send touchCancel to the app
[17:46] <faenil> and the app will behave accordingly
[17:47] <dandrader> faenil, oSoMoN is talking about an in-app SwipeArea, not about a SwipeArea in unity8
[17:47] <dandrader> faenil, those are two different scenarios
[17:47] <faenil> sorry, didn't have context :)
[17:47] <faenil> dandrader: well, it's the same except there's no touchgate already, right?
[17:48] <faenil> because the app doesn't have it
[17:48] <dandrader> oSoMoN, if can also listen to TouchOwnership events if you want to. but that's a ubuntu-ui-toolkit specific event type
[17:48] <dandrader> s/if/you
[18:03] <mterry> oSoMoN, what's the plan for remembering passwords in webbrowser-app?  Either internally or allowing some sort of plugin like lastpass to operate?
[18:05] <oSoMoN> mterry, a while ago a lastpass extension was mentioned, but oxide doesn’t have an extension mechanism, so that didn’t go anywhere, I’m not sure if there’s a concrete plan at all
[18:06] <mterry> oSoMoN, is an extension mechanism a no-go at all, or one of those "we haven't done it yet, but want to" things?
[18:07] <oSoMoN> mterry, I think it’s pretty much a no-go, it would be a huge amount of work for which we simply don’t have resources
[18:07] <mterry> oSoMoN, and we don't plan remembering passwords internally?
[18:08] <oSoMoN> mterry, Chris Coulson should be able to confirm, you can find him on #oxide
[18:08] <mterry> oSoMoN, it's just another pain point for me on the desktop.  Everytime I want to log into my bank or whatever, I jump to Firefox to use lastpass
[18:08] <oSoMoN> mterry, I guess remembering passwords internally is the only way forward, but I don’t think it’s even been planned/scheduled
[18:08] <faenil> dandrader: so SwipeArea gets touch, it signals itself as candidateOwner, at that point touchgate will block those points, because it won't be able to get ownership on that, is that right?
[18:08] <oSoMoN> mterry, I very much understand your frustration
[18:09] <faenil> otherwise, if swipearea ignores, touchgate manages to get ownership, and that means it can send the events through
[18:09] <mterry> oSoMoN, it's fine personally.  But just means I don't test as many websites   :)  Although I believe mint.com at least doesn't work in oxide anyway
[18:09] <dandrader> faenil, pretty much it
[18:09] <faenil> dandrader: had a quick look at both dda and touchgate, but didn't read thoroughly
[18:09] <faenil> but that looks sensible
[18:13] <faenil> dandrader: so all the touch events that have a candidate owner are stored and blocked. At one point SwipeArea either drops itself as candidate owner, or requests full ownership. If it drops itself as candidate owner, touchgate replays all the stored events, otherwise the events are removed from the queue
[18:14] <dandrader> faenil, yes
[18:14] <faenil> dandrader: ok, cool. Thanks for the help!
[18:15]  * faenil leaves the office
[19:54] <mterry> josharenson,  --no-tgz-check