| === biot` is now known as biot | ||
| davidcalle | Morning o/ | 07:35 |
|---|---|---|
| === _morphis is now known as morphis | ||
| tsdgeos | mzanetti: if i loop test launcher i can get qmltestrunner::Launcher::test_quickListMenuOnRMB to fail | 09:14 |
| tsdgeos | FAIL! : qmltestrunner::Launcher::test_quickListMenuOnRMB() property visible | 09:14 |
| tsdgeos | Actual (): false | 09:14 |
| tsdgeos | Expected (): true | 09:14 |
| tsdgeos | Loc: [/home/tsdgeos_work/phablet/unity8/unity8/tests/qmltests/Launcher/tst_Launcher.qml(730)] | 09:14 |
| tsdgeos | want me to open a bug? try to fix it? | 09:14 |
| mzanetti | tsdgeos, I can look at it, no prob | 09:16 |
| tsdgeos | k, i'll open a bug and assign it to you | 09:17 |
| === larsu_ is now known as larsu | ||
| cimi | pstolowski, did something change recently with scopes dev files? I cannot compile my scope anymore :D missing PreviewQueryBase.h, but the header is still under /usr/include/unity-scopes-3/unity/scopes/ | 10:04 |
| pstolowski | cimi, wily? | 10:05 |
| cimi | pstolowski, vivid + overlay | 10:05 |
| pstolowski | cimi, hmm, try a clean build? we did change some packaging stuff | 10:07 |
| cimi | pstolowski, yeah works after bzr clean-tree, should have done it first | 10:09 |
| cimi | I just removed some cmake cache files it wasn't enough apparently | 10:09 |
| pstolowski | cimi, cool | 10:10 |
| cimi | thanks | 10:10 |
| pstolowski | yw | 10:11 |
| cimi | pstolowski, for this dictionary shareUris, what shall I use? QvariantBuilder? | 10:14 |
| pstolowski | cimi, are you talking about scope impl? | 10:23 |
| cimi | pstolowski, yeah | 10:24 |
| cimi | pstolowski, so far I only added strings to a result | 10:24 |
| cimi | pstolowski, so I was doing like res["myProperty"] = "czesc"; | 10:24 |
| biot | hi all | 10:25 |
| cimi | pstolowski, but i guess we want to assign a dictionary like a QVariantMap now to myProperty | 10:25 |
| biot | I'm having some trouble running a custom built unity: "Settings schema 'org.compiz.unityshell' does not contain a key named 'low-graphics-mode'" | 10:25 |
| biot | is there something I'm forgetting to install? | 10:25 |
| pstolowski | cimi, i thought you were going to add this shareable dict to a preview widget, no? | 10:28 |
| pstolowski | cimi, or were cards meant to be shared? | 10:33 |
| pstolowski | cimi, for cards, just user VariantMap mymap; mymap["prop"]=Variant("ciao"); result["sharable"] = Variant(mymap); | 10:34 |
| cimi | pstolowski, maybe i was doing something wrong: in the query.cpp file of my test scope, I was adding a shareUris property to the categorisedresult | 10:37 |
| cimi | pstolowski, then in preview.cpp I had that property mapped | 10:37 |
| cimi | is there a better way of doing it? | 10:37 |
| pstolowski | cimi, ah, sure, you can totally do this. nothing wrong with it. i was interested where you want this property at the end (where shell expects it, i.e. if it's a new attribute of an 'image' widget etc) | 10:44 |
| cimi | pstolowski, maybe inside the image | 10:46 |
| Saviq | greyback_, hey, you mentioned we have dbus mocking done somewhere, can you point me at the code? | 10:51 |
| pstolowski | cimi, okay. yeah, so either stuff it in the result and then remap in the preview onto respective attribute of 'image' widget, or populate the attribute when you construct the preview. i think VariantBuilder will only make sens if you want an array of dict tuples, such as with 'audio' widget -see http://bazaar.launchpad.net/~unity-team/unity-scopes-api/trunk/view/head:/src/scopes/PreviewWidget.cpp | 10:52 |
| pstolowski | cimi, (see the doxygen doc there) | 10:52 |
| cimi | ok | 10:52 |
| greyback_ | Saviq: hey, I do a tiny bit of it in qtmir, using libqtdbusmock | 10:52 |
| * Saviq has a look | 10:53 | |
| greyback_ | Saviq: petewoods would be able to point you to better users | 10:53 |
| Saviq | tx | 10:54 |
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| === Guest62641 is now known as balloons | ||
| === ralsina_ is now known as ralsina | ||
| mterry | Saviq, is there a bug for the xapps-out-of-lifecycle issue? | 14:54 |
| === dandrader is now known as dandrader|afk | ||
| Saviq | mterry, don't think so, greyback, kgunn ↑? | 14:57 |
| Saviq | if not on the card, likely doesn't exist | 14:57 |
| kgunn | mterry: correct, no bug, just a card | 14:57 |
| greyback | not that I know of | 14:57 |
| kgunn | mterry: we did write down some rationale...need to find that | 14:57 |
| mterry | kgunn, can I have a bit of background for this then? why is qtcreator called out separately? it's an xapp right? | 14:57 |
| kgunn | mterry: https://docs.google.com/document/d/11GWzlGtSzLQcWVnIhwHWjjv5E0KEMtHD4HWkHkhDMrA/edit | 14:59 |
| mterry | What is the upstream project name for Qt in launchpad? | 15:07 |
| Saviq | mterry, don't think there is one? | 15:08 |
| mterry | Saviq, how do we link upstream bugs to LP bugs? | 15:08 |
| Saviq | mterry, we just put them on package bugs and add a link to qt.io | 15:09 |
| mterry | Saviq, so we don't have a separation between upstream resolution and package resolution? odd. But ok, can do | 15:09 |
| Saviq | don't think there's more, Mirv ↑? | 15:09 |
| mterry | Saviq, hrm, package bugs don't let you have external links | 15:10 |
| Saviq | mterry, by "add a link"... I mean in the description... | 15:11 |
| mterry | Saviq, ah... I for sure thought I've seen QTBUG links before | 15:11 |
| Saviq | mterry, don't get me wrong, we could do much better | 15:11 |
| mterry | but will do that for now | 15:11 |
| mterry | tsdgeos, ^ ? | 15:12 |
| Saviq | but somehow we never cared enough to make it work proper with LP's facilities for external projects | 15:12 |
| tsdgeos | mterry: qtbase-opensource-src | 15:12 |
| tsdgeos | https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/ | 15:12 |
| mterry | tsdgeos, that's the package name. What about the upstream "fake project" name we use to link LP bugs and the upstream bugs? | 15:13 |
| mterry | tsdgeos, Saviq, if we don't have one, I'll make one. Super easy :) | 15:13 |
| tsdgeos | i open all my upstream bugs there and just put a link :D | 15:13 |
| tsdgeos | mterry: ask Mirv he's the Qt man | 15:13 |
| mterry | guh | 15:13 |
| mterry | tsdgeos, will do | 15:14 |
| mterry | Mirv, ^ when you get a chance, thanks | 15:14 |
| Saviq | tsdgeos, dednick, can you have another look at bug #1493530 please | 15:28 |
| ubot5 | bug 1493530 in Canonical System Image "/usr/bin/unity8-dash:6:qt_message_print:qt_message:QMessageLogger::fatal:deallocate:~QString" [Critical,Confirmed] https://launchpad.net/bugs/1493530 | 15:28 |
| Saviq | tsdgeos, it seems as if the stacktrace changed after your comment (at least I can't see the line you commented about) | 15:29 |
| tsdgeos | Saviq: yeah different stacktrace | 15:32 |
| tsdgeos | or i commented on the wrong bug | 15:32 |
| tsdgeos | it could also be :D | 15:32 |
| tsdgeos | i mean there's still a 0x2 | 15:33 |
| tsdgeos | data (this=0x2) at /usr/include/arm-linux-gnueabihf/qt5/QtCore/qbytearray.h:451 | 15:33 |
| tsdgeos | in #7 | 15:33 |
| tsdgeos | so maybe the stacktrace was bogus and recreated? | 15:33 |
| Saviq | could be | 15:34 |
| Saviq | now it just looks like something bassed a 0x0 to UbuntuClipboard | 15:34 |
| Saviq | but yeah, 0x2... | 15:35 |
| tsdgeos | well passing a 0x0 to QByteArray UbuntuClipboard::serializeMimeData(QMimeData *mimeData) const | 15:37 |
| tsdgeos | means instant crash | 15:37 |
| tsdgeos | const QStringList formats = mimeData->formats(); | 15:37 |
| tsdgeos | is the first thing | 15:37 |
| tsdgeos | so yeah | 15:37 |
| dednick | the this is the bytearray | 15:37 |
| tsdgeos | it'd be cool to know who called serializeMimeData with a nullptr | 15:37 |
| dednick | i think the byte array from toLatin1() may have gone out of scope? | 15:37 |
| tsdgeos | and probably that needs a nice if to not crash | 15:37 |
| tsdgeos | nah can't be deleted until the memcpy ends | 15:38 |
| tsdgeos | it's just that this formats comes from calling formats() on a 0x0 mimedata | 15:39 |
| tsdgeos | so yeah | 15:39 |
| dednick | tsdgeos: you wanna add the check? | 15:41 |
| dednick | or want me to? | 15:41 |
| tsdgeos | i mean the empty data is "valid" | 15:41 |
| tsdgeos | all the other platforms check for it | 15:41 |
| tsdgeos | if (data == 0) { | 15:41 |
| tsdgeos | emitChanged(QClipboard::Clipboard); | 15:41 |
| tsdgeos | return; | 15:41 |
| tsdgeos | } | 15:41 |
| tsdgeos | inthe qnx one | 15:42 |
| tsdgeos | xcb has the same | 15:42 |
| tsdgeos | dednick: whatever you prefer | 15:42 |
| dednick | tsdgeos: meh. i can add it quick. | 15:42 |
| tsdgeos | dednick: yours then :) | 15:42 |
| === dandrader|afk is now known as dandrader | ||
| mhall119 | kgunn: so I went and bought myself a bluetooth mouse. It connects easily to my Nexus 4, but it doesn't kick it into windowed mode nor does it show a mouse cursor. I can enabled windowed mode manually with a tweak tool, but is there any way to get the cursor? | 16:26 |
| * mhall119 is on rc-proposed channel with mir 0.16 | 16:26 | |
| greyback | mhall119: mouse cursor not done yet. silo15 should make it visible for you at least | 16:40 |
| mterry | greyback, so how does qtmir handle xapps today? | 16:44 |
| greyback | mterry: currently, qtmir doesn't distinguish xmir for any other mir client | 16:44 |
| mterry | greyback, I see. Does mir expose the difference and qtmir doesn't do anything with that info, or do they look the same even to Mir? | 16:45 |
| greyback | mterry: they look the same, even to mir | 16:45 |
| mterry | hmph | 16:45 |
| greyback | so I had a chat with ted about this, and here was his suggestion: | 16:45 |
| greyback | an application's id (appId) is always of the form: app_containerName_versionString | 16:46 |
| greyback | For legacy app, check it finishes with "0.0" version string. | 16:46 |
| greyback | Then using liblibertine, check the containerName matches a container. | 16:46 |
| greyback | Then can assume it a legacy app. | 16:46 |
| mterry | greyback, OK that's helpful. Thank you | 16:47 |
| * mterry goes and plays with some code | 16:47 | |
| greyback | mterry: thing is, I really dislike that approach | 16:47 |
| mterry | greyback, heh | 16:47 |
| mhall119 | greyback: thanks | 16:47 |
| mterry | greyback, relying on heuristics rather than a clear metadata tag? | 16:48 |
| greyback | mterry: I think ubuntu-app-launch library should have a way to tell qtmir (this app is legacy) | 16:48 |
| greyback | mterry: well UAL launched the xmir app, so presumably it knows the app is an xmir app. It could just tell us that, without us resrting to guesswork | 16:49 |
| mterry | greyback, yeah. that feels less magic | 16:49 |
| greyback | tedg: what say you? | 16:50 |
| greyback | please read up | 16:50 |
| * tedg reads backlog | 16:51 | |
| tedg | mterry: greyback: Why do we care wheter it is an X app or not? | 16:52 |
| mterry | tedg, we want different app lifecycle policies | 16:52 |
| mterry | tedg, i.e. we want to let X apps run in the background | 16:52 |
| tedg | So what about apps that use the GTK Mir background but are desktop apps? | 16:52 |
| mhall119 | mterry: are we not going to allow confined apps to run in the background on desktops? | 16:52 |
| mterry | mhall119, I don't know about that specifically -- I imagine we could allow that just fine. But the upper layer would know if we're on desktop or not and apply different policies | 16:53 |
| mterry | mhall119, I'm looking at pocket desktop right now | 16:53 |
| greyback | tedg: would be good to know things like: is an app click/confined, confined mir native, confined xmir, unconfined.. | 16:54 |
| tedg | mterry: I guess my feeling is that we don't care whether it's "an X app" specifically. We should have a better metric. | 16:54 |
| tedg | Exactly, we should figure out the types we care about. | 16:55 |
| tedg | And I'd have no problem putting that funciton into UAL. | 16:55 |
| greyback | tedg: yeah, I agree just xmir is not a good enough metric | 16:55 |
| mterry | tedg, I guess by xapps we mean containerized apps, right? | 16:55 |
| tedg | I guess, I'm curious if we mean that or not. We could, for instance, care about Click apps that are marked for desktop? | 16:56 |
| greyback | tedg: by xmir we're really meaning desktop apps - irrespective of if they are native mir (like GTK/Qt on Mir) or on XMir | 16:57 |
| tedg | Not sure if such a thing does/will exist. | 16:57 |
| mterry | greyback, tedg: so anything that's not a click? | 16:57 |
| tedg | Well, that would then be browser and system settings as well :-) | 16:57 |
| greyback | mterry: let's not tie packaging format in to the application type | 16:58 |
| mterry | tedg, greyback: anything without X-Ubuntu-Touch=true in its desktop file? | 16:58 |
| mhall119 | so non-convergence, non-mobile | 16:59 |
| mterry | mhall119, right -- both those categories should expect lifecycle management in pocket desktop | 16:59 |
| mhall119 | greyback: well....I may have bricked my phone :( | 17:00 |
| tedg | mterry: I think this might be worth a mail to a mailing list. I'm guessing more people are gonna weigh in on it. | 17:00 |
| greyback | mterry: main thing I'm concerned with: if OOM killer kills the app, could it be resumed? We have to assume anything built with our UITK can support that. | 17:01 |
| tedg | mterry: But, generally, I'm fine putting a function or parameter on a signal for helping Unity make a destinction, we just need to decide what that is. | 17:01 |
| greyback | tedg: what sort of info can you give us? | 17:02 |
| tedg | We'd probably also make kenvandine happy if that list of "types" included a scope. For recognizing their appids as well. | 17:02 |
| tedg | greyback: Depends on requirements. We throw away a lot of metadata right now, but we could keep more if we wanted to. | 17:03 |
| mterry | tedg, greyback: I assumed that X-Ubuntu-Touch=true was the flag that opts-into our platform -- accepting lifecycle constraints and state saving and all that. Do you know the origins of that flag and/or if my understanding is wrong? | 17:03 |
| === dandrader is now known as dandrader|lunch | ||
| === alan_g is now known as alan_g|EOD | ||
| tedg | greyback: For instance when running we only know click/legacy, but that's just because we never need more data. We could track click/legacy/libertine for instance if that was useful. | 17:03 |
| greyback | mhall119: because of silo15? | 17:03 |
| tedg | mterry: It was more that we'd list it in the phone scope at first. Not sure why a ShowIn wasn't used. | 17:04 |
| tedg | mterry: I think it was "has Mir" :-P | 17:04 |
| mhall119 | greyback: likely, I ran the citrain tool to install silo 15, and when it rebooted it wouldn't get past the google splash | 17:04 |
| greyback | mhall119: ok, silo probably needs rebuild. Sorry about that | 17:05 |
| mterry | tedg, well if we could trigger off that flag, this test would be easy -- and qtmir would already have the info it needs... though interpreting that flag that way definitely deserves a mailing list thread to confirm that makes sense | 17:06 |
| greyback | mterry: on pondering a bit, we may need more granularity than just native mir vs xmir. The term "curated" is in the doc. That sounds more like whitelisting to me | 17:08 |
| mterry | greyback, well for a pocket desktop focus, there is a curated list of apps that we allow on the image, yes. But I think the feature is more general -- knowing which apps expect a Touch lifecycle and which don't isn't restricted to a curated list | 17:10 |
| mterry | We could whitelist and call it a day | 17:10 |
| mterry | But I imagine scope will grow in future | 17:10 |
| greyback | mterry: sure, I did say "more granularity" :) The more info the shell gets, the better a decision it can make. | 17:11 |
| greyback | odds are we'll need to go through all the X apps, and say which is good to be lifecycled, and which is not | 17:12 |
| mterry | greyback, what's your opinion on interpreting X-Ubuntu-Touch=true as "expects Touch lifecycle"? | 17:12 |
| greyback | mterry: that's not what it was originally for. It was for filtering the desktop files for ones pointing to touch-supported apps | 17:12 |
| mterry | greyback, isn't that exactly the test we want? Touch-supported apps? | 17:13 |
| mterry | greyback, or are you saying that you expect the desktop files for libreoffice on pocket desktop will have that flag so that they show up? | 17:14 |
| mterry | i.e. it's a hack to emulate OnlyShowIn | 17:15 |
| greyback | mterry: well there is that yeah | 17:15 |
| greyback | but frankly, nothing right now is terribly clear to me | 17:15 |
| greyback | let's start from the top. We want to exclude certain desktop apps (which may, and may not run via xmir) from lifecycle | 17:16 |
| greyback | so we need shell to distinguish those | 17:16 |
| greyback | UAL can probably tell us if app is xmir or not | 17:17 |
| greyback | and if confined or not | 17:17 |
| greyback | but that leaves us unable to detect native mir desktop apps (using gtk-mir or qtubuntu_ | 17:18 |
| mterry | Yeah | 17:18 |
| greyback | and I see no way of doing so, as things currently stand | 17:18 |
| mterry | Plus, there's the issue of protocol vs platform | 17:19 |
| mterry | I *could* imagine an app that is Mir-native, but not written for the Ubuntu phone platform | 17:19 |
| greyback | right | 17:19 |
| mterry | So I'm back to the need for a piece of metadata that opts into the Ubuntu phone platform | 17:20 |
| greyback | right | 17:20 |
| greyback | flag in desktop file, plus UAL reporting xmir or not, is probably all we can do | 17:20 |
| mterry | greyback, if we have a flag, do we even need xmir detection? | 17:21 |
| greyback | mterry: I thought of it only to avoid having to edit all desktop files in the world | 17:21 |
| greyback | but maybe it can be simple opt-in | 17:22 |
| mterry | greyback, well depends on which flag we pick | 17:22 |
| mterry | greyback, if we *can* re-use X-Ubuntu-Touch, we get all the desktop edits for free | 17:22 |
| greyback | mterry: yeah. Who reads that? apps scope? | 17:22 |
| greyback | would be good to be clear on what it's purpose is | 17:23 |
| mterry | greyback, I don't know who consumes it or expects it. I bet the apps scope does. I can dig a little bit. And maybe send an email out to ubuntu-phone to ask as well | 17:23 |
| greyback | that's a plan, yeah | 17:23 |
| greyback | if we just use desktop file, this task won't take too long | 17:23 |
| mterry | greyback, yeah that would be nice -- qtmir already reads desktop file right? | 17:24 |
| greyback | yep | 17:24 |
| === dandrader|lunch is now known as dandrader | ||
| mterry | sweet | 17:24 |
| greyback | I guess I'd just prefer all x apps being opted in to lifecycle, and we selectively exclude | 17:24 |
| mterry | greyback, oh weird. I wouldn't expect that preference :) Why? | 17:25 |
| mterry | Battery savings I guess? And you expect breakages to be less common? | 17:26 |
| greyback | mterry: it's not a well defined opinion yet. But for CPU/responsiveness | 17:26 |
| greyback | perhaps I'm being too strict tho | 17:26 |
| greyback | most likely we'll build it and see | 17:26 |
| mterry | greyback, I guess I just worry that state-saving is not at all standard in X apps like we want | 17:26 |
| greyback | mterry: sure, but they'll be killed either way :) | 17:27 |
| mterry | greyback, well I guess a bool flag in the desktop file gives us the choice of being more explicit down the road | 17:27 |
| mterry | and swapping the default for X apps | 17:27 |
| greyback | mterry: yeah. We'll expose that info up into unity8, and let it make the call | 17:27 |
| mterry | greyback, I think we plan to warn in such cases? | 17:27 |
| mterry | anyway. First have to see about current flag options | 17:28 |
| greyback | mterry: one side thing: in UAL, suspend/resume and setting of the OOM score are one operation | 17:28 |
| mterry | Right. We were talking in hangout this morning about maybe wanting to separate them | 17:29 |
| greyback | I would like it | 17:29 |
| mterry | I don't see any mention in this x-apps-for-pocket-desktop doc about OOM. Just lifecycle | 17:29 |
| greyback | so shell could let an app run, but be the first one to die if memory runs low | 17:29 |
| mterry | I feel like it assumes they are the same and it wants to opt out of OOM too | 17:30 |
| greyback | mterry: in my book, they're related. You can clarify/make new card if you prefer | 17:30 |
| greyback | but yeah, one at a time | 17:30 |
| mterry | I'm all for killing them via OOM too, but I think design would want an opinion on how that's presented to user | 17:30 |
| greyback | mterry: giant skull & cross-bones on top of the sucker | 17:32 |
| mhall119 | yay, restored my phone, going to use a demo phone for silo experimenting from now on :) | 17:32 |
| mterry | mhall119, :) | 17:32 |
| mterry | Maybe just kill Touch apps preferentially, and display a dialog about killing x-apps if it must | 17:33 |
| greyback | mterry: we can't stop the kernel killing apps | 17:34 |
| greyback | well, we can influence it's decision with OOM score | 17:34 |
| mterry | greyback, oh, we can't set a fine-grained policy? | 17:34 |
| mterry | that's something | 17:34 |
| greyback | but if it strikes, we can only fix up things afterwards | 17:34 |
| mterry | I see | 17:35 |
| mterry | Then yeah, opting out of OOM makes sense for legacy apps | 17:35 |
| greyback | OOM score is a weighting that the kernel takes into consideration when deciding which process to kill. | 17:35 |
| greyback | if your app has a high score (i.e. avoid killing it) but is sucking up all memory, the kernel may kill it anyway | 17:36 |
| greyback | we won't totally opt out processes from OOM (if kernel can't free memory when there's none free, then it'll hang), it's just something we need to try deal with. | 17:37 |
| greyback | so OOM score is most influence we have on it | 17:37 |
| mterry | greyback, sure. "opt out as much as possible" :) | 17:38 |
| greyback | yep | 17:38 |
| mhall119 | greyback: yeah, silo15 is pretty busted | 17:47 |
| mhall119 | The following packages will be REMOVED: ubuntu-touch ubuntu-touch-session unity8 unity8-common | 17:47 |
| greyback | mhall119: ok, thanks. Will try rebuild | 17:48 |
| mterry | kgunn, bug 1500444 is a data loss bug with patch. I'd like to squeeze it into OTA7 if possible. Just saw that freeze got a little delayed. Wanted to put this on your radar | 18:14 |
| ubot5 | bug 1500444 in qtbase-opensource-src (Ubuntu RTM) "QLockFile won't notice if the lock pid is re-used by an unrelated process" [Undecided,New] https://launchpad.net/bugs/1500444 | 18:14 |
| mterry | kgunn, (data loss in the sense that you can lose your webbrowser-app session) | 18:14 |
| mterry | I don't know if that's really data or not... But I believe it saves form content, so I think it would count | 18:15 |
| mhall119 | greyback: strange, my personal phone won't switch to window mode when connected to a mouse, but another Nexus4 with teh same channel and build # does... | 18:23 |
| greyback | mhall119: oh joy :) Well, let us land the proper mouse support first, then we can investigate | 18:25 |
| mhall119 | greyback: thanks | 18:27 |
| mhall119 | greyback: my first guess would be that it has something to do with the tweak app I used on my personal phone to force it into windowed/staged mode | 18:27 |
| mhall119 | greyback_: I was right, got it working on my personal device with: | 18:31 |
| mhall119 | phablet@ubuntu-phablet:~$ gsettings set com.canonical.Unity8 usage-mode 'Automatic' | 18:31 |
| greyback_ | mhall119: ah, you had it at non-automatic? | 18:32 |
| mhall119 | greyback_: it seems TweakGeek/Ubuntu Touch Tweak Tool will set it to 'Staged' or 'Windowed', and not back to 'Automatic' | 18:34 |
| mhall119 | so anybody who's forced it manually into windowed mode, either using one of those apps or gsettings directly, will need to change it back | 18:34 |
| * greyback_ shakes fist at mzanetti | 18:34 | |
| greyback_ | mhall119: sounds wrong, can you log bug please? | 18:35 |
| mhall119 | anyway, now all I need is that cursor, and I will be a happy camper :) | 18:35 |
| mhall119 | greyback_: log where? | 18:35 |
| greyback_ | mhall119: against qtmir, we'll blame mzanetti and he'll fix his stuff | 18:36 |
| mhall119 | greyback_: it seems like qtmir is just doing what it's told | 18:36 |
| greyback_ | mhall119: sure, but where else can we log it? | 18:37 |
| greyback_ | does tweakgeek have a bugzilla of some kind? | 18:37 |
| mhall119 | greyback_: I'm not sure it's actually a bug, just the fact that I used unsupported methods ot set it to "always be staged" | 18:37 |
| greyback_ | mhall119: you're not wrong, but I'd rather get it fixed than say "unsupported" | 18:38 |
| mhall119 | greyback_: ok, I'm happy to file it as a bug somewhere, just tell me where | 18:38 |
| greyback_ | mhall119: qtmir, and I can follow up | 18:38 |
| mhall119 | greyback_: https://bugs.launchpad.net/ubuntu/+source/qtmir/+bug/1500561 | 18:43 |
| ubot5 | Ubuntu bug 1500561 in qtmir (Ubuntu) "Mode switching not automatic if previously set" [Undecided,New] | 18:43 |
| === pixel_ is now known as Guest53123 | ||
| greyback_ | mhall119: thanks | 18:45 |
| === Guest53123 is now known as pixel_ | ||
| greyback_ | mhall119: I think I misunderstood you, it sounded like tweakgeek was setting that gsetting behind your back. Since you set it yourself, then you're right, there's not much we can do | 18:47 |
| mhall119 | greyback_: that's not true, we can still blame mzanetti | 18:53 |
| greyback_ | oh I fully intend to | 18:53 |
| === dandrader is now known as dandrader|afk | ||
| kgunn | mterry: is there a patch against vivid+stablephone ppa for that same bug ? | 19:28 |
| kgunn | the Qlockfile | 19:28 |
| mterry | kgunn, the wily one should apply | 19:30 |
| mterry | kgunn, but both wily and overlay have qtbase updates in flight already. I emailed Mirv to find out the situation | 19:31 |
| kgunn | mterry: k, i actually assigned to mirv | 19:31 |
| mterry | kgunn, I filled out a silo request for it (with QA steps), but didn't actually apply for the silo yet | 19:31 |
| mterry | kgunn, sounds good | 19:31 |
| mterry | kgunn, I don't know how common it is in practice. But I hit it today on desktop which made me investigate | 19:32 |
| mterry | kgunn, and I've felt like I've lost sessions on phone in past | 19:32 |
| mterry | kgunn, which maybe were this bug | 19:32 |
| kgunn | yep, annoying enough | 19:32 |
| * pixel_ ping facebook o_O | 19:34 | |
| * pixel_ he dead? | 19:34 | |
| mterry | pixel_, dead for me too | 19:37 |
| pixel_ | yeah :/ | 19:37 |
| tedg | popey: Facebook is down! | 20:01 |
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!