=== rsalveti_ is now known as rsalveti === xnox_ is now known as xnox === OutOfControl is now known as benonsoftware === popey_ is now known as popey === Guest77944 is now known as kklimonda === achiang` is now known as achiang === john-mca` is now known as john-mcaleely [15:54] Hi. I see reports stating that Ubuntu Unity 8 would be QML based so does that mean all default applications (gnome-terminal, Nautlius etc) would be changed to Konsole, dolphin and so on ? [15:56] is my understanding right ? [15:57] so which means, the kubuntu distribution and Ubuntu would be completely based on QT and both using QT stuff alone [15:58] not really [16:00] the problem is, konsole, dolphin and the rest of KDE apps are.. well, KDE [16:00] and nothing is stopping them from shipping gnome-terminal & co. with QML Unity8 [16:01] kklimonda: so in 14.10 would the default apps undergo change [16:01] ? [16:02] or simply put would Ubuntu ditch everything with gnome and move completely to QT based apps ? [16:02] ubuntu doesn't have resources to ditch all the gnome apps and rewrite them in Qt [16:03] so I don't think there is going to be a major shuffle in default apps [16:03] I'm actually really curious to see how well will they integrate Gtk+ with Qt/QML [16:03] oh ok [16:04] i was under the impression that 14.10 will have Konsole instead of gnome-terminal and dolphin instead of Nautilus and so on [17:39] kklimonda, same way we integrate non-gnome compiz/unity7 right now, it doesn't really matter what the shell's written in [17:40] but no, there's no plan to switch to KDE for default apps [17:49] Saviq: what about gvfs? are there plans to get it working well with Qt? last time I checked the open/save dialog in Qt apps behaved slightly differently [17:51] kklimonda, nothing is on the road map right now, but that would probably be one of the things that need happening - depending on the end goal [17:52] kklimonda, right now we're focusing on the phone model, where there's not meant to be a "file" chooser in that sense, rather a "content" chooser, that will be mediated content exchange between two apps, with UIs implemented by the apps themselves [17:52] yeah, really sad about you focusing on the phone :( [17:53] kklimonda, in that world on the desktop one of those apps could be a file chooser, though [17:53] mhm [17:53] kklimonda, why's that, most of the world seems quite happy ;) we've focused on the desktop for quite some time now ;D [17:53] but that's a dying market, consumer devices move towards tablets/phones more and more [17:53] well, I don't need a phone os, but there are bugs in unity that are making my life harder than needed [17:54] and some of those have basically been declined for fix in unity 7.x [17:55] kklimonda, depending on the nature of those bugs, they might be declined from unity 8 too, if they're incoherent with our design vision [17:55] kklimonda, other than that, it's open source, really [17:55] no, my problem is that unity under compiz is intercepting the super key [17:55] and it's messing up with VMs [17:55] kklimonda, the, unfortunately abrasive, but true, answer is "patches welcome" [17:56] kklimonda, we have to focus on some things, VMs isn't a general enough usecase that we'd like to spend time on it [17:57] cool, it's a bug though - not a new feature [17:58] would be nice to know that you are commited to fixing those [17:58] and from what I've read in the bug report, it's a compiz limitation, and may go away once unity 8 is released - but it's been like 2 or 3 years since it got reported, so yeah.. [17:59] kklimonda, yeah, we're definitely going to try and not bring those kind of bugs over to the Mir / Unity8 world [18:00] kklimonda, if it was easy to fix in compiz, it would have been fixed - but since it has not, by neither us nor the community, it must be somewhat difficult (I don't know compiz code, but that's a general thing) [18:01] gtg [19:17] Saviq, hi, still around? [19:20] mhr3, hi [19:20] hey [19:21] mhr3, hi, do you have a minute, we were having some problems with the scope regarding the scope api [19:21] gatox, shoot [19:22] * Saviq around, too [19:23] Saviq, btw latest everything is so pretty ;) [19:23] mhr3, it wasn't like that yesterday ;D [19:23] i didn't want to kill myself even after using it for like an hour :) [19:24] Saviq, mhr3, the list of Results that is created to show apps in the dash has the proper info to launch the app for installed apps..... BUT, when we want to install a new app, we don't go through the dash again to parse the .desktop files, etc..... so, when you open a preview for an uninstalled app and choose to install, you move to the progress preview, and then to installed preview, which shows the OPEN button, but when you press that b [19:24] utton, that RESULT object, still has the uri as the http://search.apps... fromm the server..... we have a function to retrieve the path to to the desktop file parsing the manifest [19:25] Saviq, mhr3 the problem is that we don't have anyway to change the uri in the result object that is received by the perform_action function in the Scope, so it keeps trying to open that url in the browser when you press open [19:25] gatox, couldn't you send appid:/// in the last preview? [19:26] ah, hmmm [19:26] Saviq, what? [19:26] mhr3, ah that's mapped from the result itself? [19:26] yes [19:26] yea, scope doesn't really have a chance to change the result for which it is doing a preview [19:26] for a perform_action creating a ActionResponse with NotHandled, so the app is opened from the Dash it use the result info [19:27] * mhr3 thinks about a workaround [19:27] any ideas how to fix that? is it possible to do somethig from the scope? [19:28] gatox, you could url-dispatch the appid:/// [19:28] mhr3, unless you have some better idea to handle it unity-side [19:28] gatox, we want to support scope-free actions, much like we had previously [19:29] so action could specify a uri, and dash would deal with that uri [19:29] bypassing the standard result uti [19:29] uri* [19:29] mhr3, but that is not possible now, right? [19:29] not right away [19:29] only a patch away though [19:30] a pretty simple patch for that manner [19:30] matter [19:31] mhr3, a patch where? unity-scope-api? [19:31] gatox, no, shell plugin [19:32] mhr3, anyone who could do it today? should i move to Saviq suggestion for now? [19:32] Saviq, wouldn't doing that loose animations and stuff? [19:34] Saviq, for what you suggest..... should i just: QDesktopServices::openUrl(QUrl("appid:///desktop_file")); ?? [19:35] gatox, yes [19:35] gatox, well, not desktop_file [19:35] gatox, for desktop_file you'd do application:///desktop_file [19:35] gatox, see https://wiki.ubuntu.com/URLDispatcher [19:35] mhr3, shouldn't [19:36] Saviq, thx!! [19:36] mhr3, we url-dispatch apps all the time [19:36] mhr3, and it should be fully supported [19:36] in that case, that's the easier solution for now [19:36] I think so, yeah [19:37] gatox, ugh, that doc is outdated quite a bit [19:37] Saviq, mhr3 thanks both! i'll try that now [19:40] gatox, another option would be to use for uninstalled apps uris which == installed ones [19:41] mhr3, maybe..... but that would require LOTS of changes right now, for retrieving the info from the server, etc.... maybe that could be done in a future interation [19:42] isn't it just appid:///app_id ? :) [19:42] but i can see that doing that would require more changes [21:06] mhr3, any pointers on debugging a dying scope? I'm testing gatox's tweak for launching apps, but when I click Open, I get back to dash (which might be correct 'cause he's returning HideDash), but then the scope seems to die (no results until scope-registry restart) [21:06] oooooh [21:06] i know what is that [21:06] mhr3, really?! :D [21:07] calling openUrl from non-gui application crashes qt [21:07] i've seen that in shell plugin tests [21:08] mhr3, that sounds like a reason here [21:09] Saviq, but otherwise you can just ps aux, look for the scope cmd line, kill it and respawn with gdb [21:10] mhr3, right, makes sense [21:11] sorry that i didn't think about that an hour ago [21:12] mhr3, nw [21:13] gatox, you could use liburl-dispatcher directly [21:14] Saviq, yap.... i'll try that [21:14] Saviq, mhr3 thx both again! [21:14] wouldn't it be enough to just invoke `upstart-app-launch ...`? [21:14] Usage: upstart-app-launch [uris] [21:14] gatox, or that ↑ [21:18] mhr3, :/, I get "usage: scoperunner runtime.ini configfile.ini [configfile.ini ...]" [21:18] Saviq, `scoperunner "" foo.ini` [21:19] mhr3, ah [21:19] not easily visible in ps that the second arg is empty :) [21:20] mhr3, indeed [21:20] mhr3, gatox, yeah crashes in openUrl [21:20] so should be that [21:20] good to know [21:46] Saviq, i'm having some issues with cmake (not my area of expertise)... do you know of any projeect using liburl-dispatcher that i can look how they link it? [21:48] gatox, qtubuntu most probably, checking [21:49] crap, it's in qmae [21:49] qmae [21:49] qmake [21:49] ah actually... platform-api? [21:50] * Saviq checks [21:51] gatox, http://bazaar.launchpad.net/~phablet-team/platform-api/trunk/view/head:/src/ubuntu/application/url_dispatcher/CMakeLists.txt [21:52] Saviq, thanks! [22:05] gatox, why are you complicating your life? QProcess::execute("upstart-app-launch", {"app.id"}); [22:06] Saviq, if it's not much trouble, could you check if it works now in the device? same branch [22:07] mhr3, i was trying to avoid qt calls for this, because we need to use some special functions to execute that.... it the dispatcher doesn't work, i'll use qt (believe me, i would like to just use qt functions :P) [22:11] gatox, on it [22:11] thx [22:11] gatox, so you're assuming that url-dispatcher is actually thread safe, but i doubt that :P [22:23] gatox, it's working! [22:23] Saviq, yeyyyyyyyyyyyy [22:24] gatox, uninstalling doesn't, still, unfortunately [22:25] gatox, so how do we want to get it to the ppa? are you landing it to distro? [22:25] Saviq, yes.... uninstalling seems that needs more work [22:26] Saviq, i'll try to look at it, but without being able to test it here is hard [22:28] Saviq, are you looking at the messages in #u1-client? === asac` is now known as asac === Trevinho__ is now known as Trevinho