[15:54] <G__81> 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] <G__81> is my understanding right ?
[15:57] <G__81> so  which means, the kubuntu distribution and Ubuntu would be completely based on QT and both using QT stuff alone
[15:58] <kklimonda> not really
[16:00] <kklimonda> the problem is, konsole, dolphin and the rest of KDE apps are.. well, KDE
[16:00] <kklimonda> and nothing is stopping them from shipping gnome-terminal & co. with QML Unity8
[16:01] <G__81> kklimonda: so in 14.10 would the default apps undergo change
[16:01] <G__81> ?
[16:02] <G__81> or simply put would Ubuntu ditch everything with gnome and move completely to QT based apps ?
[16:02] <kklimonda> ubuntu doesn't have resources to ditch all the gnome apps and rewrite them in Qt
[16:03] <kklimonda> so I don't think there is going to be a major shuffle in default apps
[16:03] <kklimonda> I'm actually really curious to see how well will they integrate Gtk+ with Qt/QML
[16:03] <G__81> oh ok
[16:04] <G__81> 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] <Saviq> kklimonda, same way we integrate non-gnome compiz/unity7 right now, it doesn't really matter what the shell's written in
[17:40] <Saviq> but no, there's no plan to switch to KDE for default apps
[17:49] <kklimonda> 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] <Saviq> 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] <Saviq> 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] <kklimonda> yeah, really sad about you focusing on the phone :(
[17:53] <Saviq> kklimonda, in that world on the desktop one of those apps could be a file chooser, though
[17:53] <kklimonda> mhm
[17:53] <Saviq> 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] <Saviq> but that's a dying market, consumer devices move towards tablets/phones more and more
[17:53] <kklimonda> well, I don't need a phone os, but there are bugs in unity that are making my life harder than needed
[17:54] <kklimonda> and some of those have basically been declined for fix in unity 7.x
[17:55] <Saviq> 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] <Saviq> kklimonda, other than that, it's open source, really
[17:55] <kklimonda> no, my problem is that unity under compiz is intercepting the super key
[17:55] <kklimonda> and it's messing up with VMs
[17:55] <Saviq> kklimonda, the, unfortunately abrasive, but true, answer is "patches welcome"
[17:56] <Saviq> 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] <kklimonda> cool, it's a bug though - not a new feature
[17:58] <kklimonda> would be nice to know that you are commited to fixing those
[17:58] <kklimonda> 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] <Saviq> kklimonda, yeah, we're definitely going to try and not bring those kind of bugs over to the Mir / Unity8 world
[18:00] <Saviq> 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] <Saviq> gtg
[19:17] <gatox> Saviq, hi, still around?
[19:20] <gatox> mhr3, hi
[19:20] <mhr3> hey
[19:21] <gatox> mhr3, hi, do you have a minute, we were having some problems with the scope regarding the scope api
[19:21] <mhr3> gatox, shoot
[19:22]  * Saviq around, too
[19:23] <mhr3> Saviq, btw latest everything is so pretty ;)
[19:23] <Saviq> mhr3, it wasn't like that yesterday ;D
[19:23] <mhr3> i didn't want to kill myself even after using it for like an hour :)
[19:24] <gatox> 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] <gatox> 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] <gatox> 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] <Saviq> gatox, couldn't you send appid:/// in the last preview?
[19:26] <mhr3> ah, hmmm
[19:26] <gatox> Saviq, what?
[19:26] <Saviq> mhr3, ah that's mapped from the result itself?
[19:26] <gatox> yes
[19:26] <mhr3> yea, scope doesn't really have a chance to change the result for which it is doing a preview
[19:26] <gatox> 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] <gatox> any ideas how to fix that? is it possible to do somethig from the scope?
[19:28] <Saviq> gatox, you could url-dispatch the appid:///
[19:28] <Saviq> mhr3, unless you have some better idea to handle it unity-side
[19:28] <mhr3> gatox, we want to support scope-free actions, much like we had previously
[19:29] <mhr3> so action could specify a uri, and dash would deal with that uri
[19:29] <mhr3> bypassing the standard result uti
[19:29] <mhr3> uri*
[19:29] <gatox> mhr3, but that is not possible now, right?
[19:29] <mhr3> not right away
[19:29] <mhr3> only a patch away though
[19:30] <mhr3> a pretty simple patch for that manner
[19:30] <mhr3> matter
[19:31] <gatox> mhr3, a patch where? unity-scope-api?
[19:31] <mhr3> gatox, no, shell plugin
[19:32] <gatox> mhr3, anyone who could do it today? should i move to Saviq suggestion for now?
[19:32] <mhr3> Saviq, wouldn't doing that loose animations and stuff?
[19:34] <gatox> Saviq, for what you suggest..... should i just: QDesktopServices::openUrl(QUrl("appid:///desktop_file")); ??
[19:35] <Saviq> gatox, yes
[19:35] <Saviq> gatox, well, not desktop_file
[19:35] <Saviq> gatox, for desktop_file you'd do application:///desktop_file
[19:35] <Saviq> gatox, see https://wiki.ubuntu.com/URLDispatcher
[19:35] <Saviq> mhr3, shouldn't
[19:36] <gatox> Saviq, thx!!
[19:36] <Saviq> mhr3, we url-dispatch apps all the time
[19:36] <Saviq> mhr3, and it should be fully supported
[19:36] <mhr3> in that case, that's the easier solution for now
[19:36] <Saviq> I think so, yeah
[19:37] <Saviq> gatox, ugh, that doc is outdated quite a bit
[19:37] <gatox> Saviq, mhr3 thanks both! i'll try that now
[19:40] <mhr3> gatox, another option would be to use for uninstalled apps uris which == installed ones
[19:41] <gatox> 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] <mhr3> isn't it just appid:///app_id ? :)
[19:42] <mhr3> but i can see that doing that would require more changes
[21:06] <Saviq> 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] <mhr3> oooooh
[21:06] <mhr3> i know what is that
[21:06] <gatox> mhr3, really?! :D
[21:07] <mhr3> calling openUrl from non-gui application crashes qt
[21:07] <mhr3> i've seen that in shell plugin tests
[21:08] <gatox> mhr3, that sounds like a reason here
[21:09] <mhr3> Saviq, but otherwise you can just ps aux, look for the scope cmd line, kill it and respawn with gdb
[21:10] <Saviq> mhr3, right, makes sense
[21:11] <mhr3> sorry that i didn't think about that an hour ago
[21:12] <Saviq> mhr3, nw
[21:13] <Saviq> gatox, you could use liburl-dispatcher directly
[21:14] <gatox> Saviq, yap.... i'll try that
[21:14] <gatox> Saviq, mhr3 thx both again!
[21:14] <mhr3> wouldn't it be enough to just invoke `upstart-app-launch ...`?
[21:14] <mhr3> Usage: upstart-app-launch <app id> [uris]
[21:14] <Saviq> gatox, or that ↑
[21:18] <Saviq> mhr3, :/, I get "usage: scoperunner runtime.ini configfile.ini [configfile.ini ...]"
[21:18] <mhr3> Saviq, `scoperunner "" foo.ini`
[21:19] <Saviq> mhr3, ah
[21:19] <mhr3> not easily visible in ps that the second arg is empty :)
[21:20] <Saviq> mhr3, indeed
[21:20] <Saviq> mhr3, gatox, yeah crashes in openUrl
[21:20] <Saviq> so should be that
[21:20] <gatox> good to know
[21:46] <gatox> 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] <Saviq> gatox, qtubuntu most probably, checking
[21:49] <Saviq> crap, it's in qmae
[21:49] <Saviq> qmae
[21:49] <Saviq> qmake
[21:49] <Saviq> ah actually... platform-api?
[21:50]  * Saviq checks
[21:51] <Saviq> gatox, http://bazaar.launchpad.net/~phablet-team/platform-api/trunk/view/head:/src/ubuntu/application/url_dispatcher/CMakeLists.txt
[21:52] <gatox> Saviq, thanks!
[22:05] <mhr3> gatox, why are you complicating your life? QProcess::execute("upstart-app-launch", {"app.id"});
[22:06] <gatox> Saviq, if it's not much trouble, could you check if it works now in the device? same branch
[22:07] <gatox> 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] <Saviq> gatox, on it
[22:11] <gatox> thx
[22:11] <mhr3> gatox, so you're assuming that url-dispatcher is actually thread safe, but i doubt that :P
[22:23] <Saviq> gatox, it's working!
[22:23] <gatox> Saviq, yeyyyyyyyyyyyy
[22:24] <Saviq> gatox, uninstalling doesn't, still, unfortunately
[22:25] <Saviq> gatox, so how do we want to get it to the ppa? are you landing it to distro?
[22:25] <gatox> Saviq, yes.... uninstalling seems that needs more work
[22:26] <gatox> Saviq, i'll try to look at it, but without being able to test it here is hard
[22:28] <gatox> Saviq, are you looking at the messages in #u1-client?