| === ChanServ changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/client-2/ - http://irclogs.ubuntu.com/2013/11/21/%23ubuntu-uds-client-2.html | ||
| === tvoss_ is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| === ChanServ changed the topic of #ubuntu-uds-client-2 to: Track: Core | Make click apps runnable from the Unity7 dash | Url: http://summit.ubuntu.com/uds-1311/meeting/22035/core-1311-clicks-in-unity7/ | ||
| dholbach | hey hey | 13:55 |
|---|---|---|
| dholbach | so who wants to join in on this one? | 13:55 |
| cjwatson | I'll be along soon, but you should just paste the hangout URL in here :-) | 13:55 |
| cjwatson | (still having lunch) | 13:56 |
| dholbach | https://plus.google.com/hangouts/_/7ecpjgq5mep8il0idsc30qv9eo | 13:56 |
| dholbach | alecu, are you going to join as well? ^ | 13:59 |
| mdeslaur | o/ | 14:01 |
| dholbach | anyone else who wants to join in? | 14:02 |
| beuno | dholbach, I'm around in case I'm needed, but I think this doesn't concern the store atm | 14:02 |
| beuno | I'll listen in and feel free to drag me in if needed | 14:03 |
| beuno | dholbach, you look cold | 14:04 |
| tedg | beuno, It seems everyone in Germany wares scarfs. Not sure I'm comfortable visiting anymore. | 14:06 |
| beuno | +1 | 14:07 |
| mdeslaur | hehe | 14:07 |
| Saviq | lol | 14:07 |
| dholbach | notes are here: http://pad.ubuntu.com/uds-1311-core-1311-clicks-in-unity7 | 14:07 |
| dholbach | beuno, yep, got a cold :) | 14:07 |
| dholbach | but it's all right | 14:08 |
| asac | yes, we should not risk our "click store reputation" on security | 14:11 |
| tedg | We should run through XVnc and then back through a VNC client. | 14:15 |
| tedg | Most of the integrations are via DBus, so aa-exec-click would secure those. | 14:16 |
| dobey | tedg: under an xvfb that's 480x960 px to match common phone res? | 14:16 |
| tedg | dobey, On it! | 14:18 |
| tedg | Sounds like a command line only GSettings key | 14:19 |
| dobey | alecu, dholbach: also there's the work on the emulator, for developers to use | 14:21 |
| dholbach | dobey, yep, that's right | 14:21 |
| tedg | bregma, No, not really. Clicks are per-user, so we won't put the desktop files in. | 14:22 |
| tedg | bregma, They binaries are there, but no desktop file. | 14:22 |
| dholbach | can somebody help a bit with taking notes? http://pad.ubuntu.com/uds-1311-core-1311-clicks-in-unity7 | 14:22 |
| tedg | Is the nested X stuff driver dependent? | 14:23 |
| tedg | I thought there was some issues on nvidia? | 14:23 |
| dobey | glx inside nested X can be a problem | 14:26 |
| tedg | My thoughts are that it's interesting, but probably not worth the time. | 14:26 |
| dobey | driver doesn't matter | 14:26 |
| jdstrand | glx in nested X was a problem the last time I looked | 14:26 |
| tedg | dobey, It's X, drivers are tied to everything :-) | 14:26 |
| jdstrand | xpra has bugs open to make it better, but back then, they were already open for a long time | 14:27 |
| dobey | tedg: doesn't matter which driver you are using though. glx in nested X is a problem with all of them :) | 14:27 |
| jdstrand | I am not up to date | 14:27 |
| Saviq | ~/.local/share/applications | 14:27 |
| Saviq | ↑↑ | 14:27 |
| Saviq | unity7 does pick those up | 14:28 |
| tedg | Wait, so where do we want to put the click package desktop file? | 14:29 |
| tedg | It seems to me it either needs to be in ~/.local/share/applications or not exist. | 14:30 |
| dobey | nowhere different to where we put them now | 14:30 |
| cjwatson | Sounds like the consensus was leave them in the same place but add X-Only-Show-In or whatever it is | 14:31 |
| dobey | OnlyShowIn/NotShowIn | 14:31 |
| tedg | What would that OnlyShowIn be for? Unity 8? | 14:32 |
| dobey | yes, presuming "Unity8" is a different valid name, from "Unity" | 14:32 |
| tedg | Then why don't we just not create it? It seems like Unity8 could just put the data in a small cache better than building a desktop file. | 14:33 |
| dobey | which would be a bit weird when we get to the point of not having unity7 any more | 14:33 |
| dholbach | can somebody please help with summarising of what Colin just said? I was a bit busy taking some other notes: http://pad.ubuntu.com/uds-1311-core-1311-clicks-in-unity7 | 14:35 |
| cjwatson | doing so | 14:38 |
| alecu | cjwatson, dobey: there's a X-Ubuntu-Touch=true in apps installed from the click store. Perhaps we should just ignore those in the unity7 app scope? | 14:39 |
| cjwatson | alecu: there are other desktops to consider too | 14:40 |
| cjwatson | it seems that it might be safer to use something affirmative rather than negative | 14:40 |
| tedg | I'm confused why we want desktop files at all if they're OnlyShowIn=Unity8 | 14:40 |
| dobey | i don't think NotShowIn/OnlyShowIn will be usable here | 14:41 |
| cjwatson | we still use them for unity8, don't we? | 14:41 |
| cjwatson | even if they mostly shunt through to upstart-app-launch | 14:41 |
| tedg | cjwatson, Kinda, but we coudl just move the desktop hook to build the cache for the apps scope instead of the desktop file. | 14:41 |
| cjwatson | dobey: why not OnlyShowIn? | 14:41 |
| tedg | The desktop file itself is an inefficient connection point. | 14:42 |
| cjwatson | well, if we aren't using desktop files the whole thing's moot; but I'm unclear as to whether we should couple this work to that? | 14:42 |
| dobey | cjwatson: because there's no difference between "Unity" and "Unity8" and it would probably be a lot of work to add it. | 14:42 |
| dobey | cjwatson: currently there is only "Unity" as an option there | 14:42 |
| tedg | cjwatson, It seems like the WI's could be "drop desktop hook from UAL" and then "put desktop hook to build cache for Unity8" | 14:43 |
| dobey | i don't see why we should bother hiding the click apps at all though. if they're installed, they should be discoverable | 14:43 |
| dobey | tedg: i'd really not want to do that. it means rewriting a large portion of the click scope | 14:44 |
| dobey | jdstrand: +1 on keeping desktop files | 14:45 |
| tedg | dobey, The first step could be writing the desktop files to ~/.local/click-scope/applications and then migrating to something more sophisticated over time. | 14:45 |
| jdstrand | what about other DEs that move to mir? | 14:46 |
| tedg | Not sure. It's an interesting question. | 14:46 |
| jdstrand | they need to then adjust for this click path too | 14:46 |
| tedg | We'd need a way to know that they're running Mir. | 14:46 |
| tedg | Otherwise we get back to the "nobody trusts us anymore" problem. | 14:46 |
| mdeslaur | in our fallback wrapper that is being used in the desktop file, we detect X and print a warning dialog if it's running | 14:47 |
| alecu | mdeslaur: so, that would be if we don't move them out of ~/.local/click-scope/applications, right? | 14:48 |
| dobey | mdeslaur: only because X is insecure in the context of confining click apps? | 14:48 |
| mdeslaur | dobey: yes | 14:49 |
| tedg | Security: It'll never catch on. | 14:49 |
| tedg | No, but I'm kinda unclear what we decided. | 14:50 |
| alecu | "This app may be insecure. You may run it slowly under xephyr. [don't run it] [run under xephyr] [run it normally anyway]" | 14:50 |
| dobey | can we make the click scope just not be used by unity7, too? | 14:52 |
| tedg | Basically allow them to comment out the block in aa-exec-click. | 14:52 |
| alecu | dobey: it's currently being used on unity7, remember that most of unity-lens-app was merged into it. | 14:52 |
| tedg | # Comment out this line if you want to give all your data to everyone | 14:53 |
| cjwatson | Or similar :-) | 14:53 |
| dobey | alecu: only if you install it, will it be used by unity7 currently | 14:53 |
| dobey | alecu: the switch to use it exclusively for apps was only on the touch image for saucy at least | 14:53 |
| tedg | mdeslaur, If we don't, askubuntu will. | 14:54 |
| alecu | dobey: ah, right | 14:54 |
| cjwatson | it's in universe right now so I'm pretty sure it isn't being used in unity7 by default :) | 14:54 |
| tedg | mdeslaur, Better to give them with appropriate scariness included. | 14:54 |
| dobey | also, what about click apps that are just links to web sites? should those be confied to requiring Mir or the touch browser? | 14:54 |
| dobey | or should they work and run firefox/chrome/whatever | 14:54 |
| mdeslaur | dobey: links to web sites? | 14:55 |
| dobey | mdeslaur: the click "web apps" | 14:55 |
| alecu | dobey: there's no way of telling web apps from standard apps as far as the scope is concerned | 14:55 |
| mdeslaur | dobey: oh, those run confined too | 14:55 |
| dobey | mdeslaur: so they'd require the touch browser? | 14:56 |
| Saviq | cjwatson, but then if you install unity8, that would pull the click scope - and it would then show in unity7 as well | 14:56 |
| cjwatson | Saviq: oh, I see | 14:56 |
| cjwatson | Yeah, via Recommends, hmm | 14:57 |
| cjwatson | What would you suggest then? | 14:57 |
| Saviq | cjwatson, or wait | 14:57 |
| Saviq | cjwatson, we're re-doing the scope backend for unity8 | 14:57 |
| Saviq | cjwatson, so if there's no click scope for the old backend, it's just not there | 14:57 |
| Saviq | cjwatson, so we should actually be fine here | 14:58 |
| cjwatson | What's the timeline on that? | 14:58 |
| * cjwatson switches to IRC to avoid lag | 14:58 | |
| dobey | mdeslaur: all the webapp APIs are just dbus calls exposed via JS right? so the dbus confinement should be enough? | 14:58 |
| Saviq | cjwatson, 14.04 | 14:58 |
| jdstrand | dobey: they will use a 'webapp container' which is based on the touch browser | 14:58 |
| mdeslaur | dobey: I can't answer that question without thinking about the implications of running it under x | 14:59 |
| jdstrand | right | 14:59 |
| jdstrand | it might be acceptable. it might not | 14:59 |
| dobey | mdeslaur: sure. just trying to raise the question and help clarify it :) | 14:59 |
| Saviq | o/ | 15:00 |
| jdstrand | mdeslaur: I wonder if it makes a difference on if it is stuff we ship (ie, the Canonical webapps) vs arbitrary webapps in the store | 15:00 |
| === ChanServ changed the topic of #ubuntu-uds-client-2 to: Track: Client | Design and implement a media service for Ubuntu | Url: http://summit.ubuntu.com/uds-1311/meeting/22088/client-1311-media-service/ | ||
| jdstrand | mdeslaur: because, as it is, there is no confinement at all for webapps when running under chromium or firefox | 15:00 |
| dobey | and there's obvious duplication between click webapps and webapps as packaged in the webapps deb | 15:01 |
| jdstrand | so this could improve the situation there, even if there are some potential gaps. but yeah, would want to think about it cause there is also the reputation of click at stake | 15:01 |
| jdstrand | anyhoo, food for thought :) | 15:02 |
| dobey | yep | 15:02 |
| dobey | and on to the next session :) | 15:02 |
| dobey | thanks | 15:02 |
| diwic | hangout link for the media service session? | 15:02 |
| didrocks | diwic: https://plus.google.com/hangouts/_/7acpjrath88ccmnne2ldam7qog?authuser=0 | 15:03 |
| jhodapp | diwic, feel free to speak up as much as you want since you helped with the music-hub implementation | 15:04 |
| tvoss | hello :) | 15:05 |
| jdstrand | may I join the fishbowl? | 15:08 |
| rsalveti | sure | 15:08 |
| jdstrand | what is the url? I just joined so missed it if it was pasted | 15:09 |
| rsalveti | https://plus.google.com/hangouts/_/7acpjrath88ccmnne2ldam7qog?authuser=0 | 15:09 |
| jdstrand | thanks | 15:09 |
| sergiusens | tvoss, jhodapp by playlist I think he means, hey, play this list of songs while I'm suspended | 15:24 |
| tvoss | sergiusens, that will be supported for sure | 15:24 |
| tvoss | sergiusens, we have a play queue right now that the app can fill | 15:24 |
| vthompson | sergiusens, that's implemented in the trackList | 15:24 |
| vthompson | I assume | 15:24 |
| tvoss | thompson, yup, tracklist/playqueue, cannot remember how I called it :) | 15:25 |
| sergiusens | sorry, joined late :-) | 15:25 |
| sergiusens | shuffling between two sessions | 15:25 |
| ricmm | vthompson: I think you meant mediascanner looking up for "playlists" on the fs | 15:27 |
| ricmm | however I dont know how the mediascanner could have a concept of a playlist if it hasnt been user created in a predefined format thats storable to disk | 15:27 |
| vthompson | ricmm, correct | 15:27 |
| thostr | don't think that common format of playlist makes a lot of sense as 3rd party players usually already have their own format | 15:28 |
| vthompson | I was only asking the question as to have a reason for the the mediascanner and media service to be a single component | 15:28 |
| Elleo | tvoss: presumably whitelisting still needs to be available in general, as there are some apps that can't use the media service (e.g. my spotify clients) | 15:29 |
| ricmm | rsalveti: for a QML application its a matter of updating your play status when you go from Qt.application.inactive -> active | 15:30 |
| ricmm | so a state transition handler | 15:31 |
| ricmm | theres no concept of being resurrected or what not at that high level | 15:31 |
| tvoss | Elleo, sure, not talking about general whitelisting | 15:31 |
| Elleo | tvoss: okay, cool | 15:31 |
| rsalveti | ricmm: right, I was just thinking about the user experience for that | 15:32 |
| ricmm | rsalveti: got it | 15:32 |
| rsalveti | but guess that depends on how the app is done | 15:32 |
| tvoss | Elleo, although we are discouraging whitelisting :) | 15:32 |
| Elleo | tvoss: yeah, I don't really have much choice though; I don't have any sort of stream I can pass off to other services | 15:33 |
| Elleo | I'm tied to the way libspotify does things | 15:33 |
| ricmm | jhodapp: rsalveti tvoss will we be sandwiching this with the platform-API before hitting the client (QtMultimedia) plugin? | 15:35 |
| jhodapp | ricmm, in what way? | 15:36 |
| ricmm | or is it expected to be direct from QtMultimedia to the service over dbus | 15:36 |
| tvoss | ricmm, direct so far | 15:36 |
| jhodapp | ricmm, to my understanding, direct | 15:36 |
| ricmm | ok | 15:36 |
| ricmm | weshould still have a long standing item to integrate it at the p-api level imo | 15:36 |
| ricmm | for native apps centralization, but later on of course | 15:37 |
| ricmm | not right away | 15:37 |
| jhodapp | ricmm, can you give an example? | 15:37 |
| rsalveti | right | 15:37 |
| rsalveti | in this case we're saying that our media service is kind of our platform-api | 15:37 |
| rsalveti | over dbus | 15:37 |
| rsalveti | but yeah, would be nice to abstract that properly | 15:37 |
| tvoss | ricmm, ideally, we would model it in the papi and expose openmax profiles | 15:38 |
| rsalveti | openmax profiles? | 15:38 |
| jdstrand | vthompson: btw, music-app needs to move to use mediascanner too, correct? if so, when you are done with that you can ping me to test it under apparmor policy so I can adjust it | 15:43 |
| vthompson | jdstrand, we'd use the current mediascanner... we'd need to use the new mediascanner API that will be made for 14.04 | 15:44 |
| jdstrand | vthompson: if you track your work in bugs, then just add an apparmor-easyprof-ubuntu task for both the mediascanner and media service | 15:44 |
| vthompson | jdstrand, *we currently use the existing API | 15:44 |
| jdstrand | right | 15:44 |
| jdstrand | I mean, when you change, ping me and I can get the apparmor policy together | 15:44 |
| jdstrand | since I think music-app is the only to-be-confined consumer of these things right now :) | 15:45 |
| vthompson | Sounds good. I'll do so. | 15:46 |
| jdstrand | awesome, thanks! :) | 15:46 |
| ricmm | jhodapp: what about development practices? considering this is very hardware specific (for the gstreamer backend) there are things that will work differently across devices | 15:46 |
| sergiusens | you can't top approve or HApprove ;-) | 15:46 |
| jhodapp | lol | 15:46 |
| jhodapp | ricmm, good question, sorry I missed it | 15:47 |
| tvoss | rsalveti, support openmax ;) | 15:47 |
| ogra_ | thanks | 15:47 |
| jhodapp | ricmm, there are, but if I do my job with the plugins and the media hybris layer, this shouldn't matter | 15:47 |
| tvoss | Elleo, just looking at the spotify api: How do you output the frames that are coming via the callback? | 15:47 |
| rsalveti | tvoss: right, but why would that be a platform-api thing? | 15:48 |
| rsalveti | if we want to abstract the media service itself | 15:48 |
| ricmm | why the C api to then abstract another C api | 15:48 |
| ricmm | is rsalveti's question I think | 15:48 |
| rsalveti | my question is why our api needs to have anything specific to openmax :-) | 15:49 |
| ricmm | whats the benefit of an openmax profile instead of direct usage of the platform-api natively | 15:49 |
| tvoss | ricmm, rsalveti what I'm trying to say is: let's have the platform API, clean C, easily reusable. And over time, if/when we support openmax, we can use the papi to provide an implementation | 15:49 |
| tvoss | rsalveti, it does not have to, that's what I'm saying, too. We are in violent agreement | 15:49 |
| rsalveti | but don't we want to the platform-api to use the service? | 15:49 |
| rsalveti | which in this case would be dbus | 15:50 |
| ricmm | platform-api will use the service and expose itself | 15:50 |
| rsalveti | so app -> platform-api -> dbus -> media-service? | 15:50 |
| ricmm | I think what tvoss is saying is an example analogue to SDL for example | 15:50 |
| ricmm | yes | 15:50 |
| tvoss | ricmm, +1 | 15:50 |
| rsalveti | or app -> qtmultimedia -> qtubuntu-media -> platform-api ->... | 15:50 |
| tvoss | rsalveti, yup | 15:50 |
| tvoss | rsalveti, that's what I'm saying, too :) | 15:50 |
| rsalveti | right, ok :-) | 15:50 |
| ricmm | well native its direct, the Qt model if course goes through the chain | 15:51 |
| rsalveti | so many abstractions | 15:51 |
| rsalveti | ricmm: direct how? | 15:51 |
| ricmm | direct to platform-api for native | 15:51 |
| ricmm | not direct to service | 15:51 |
| rsalveti | right, sure | 15:51 |
| ricmm | sorry, miswording | 15:51 |
| rsalveti | but no one, besides the platform-api, should be using the service api | 15:51 |
| rsalveti | right? | 15:51 |
| rsalveti | otherwise we end up supporting 2 different apis for the same thing | 15:52 |
| ricmm | indeed | 15:52 |
| ricmm | no one but the platform api should know the service implementation | 15:52 |
| ricmm | which then allows us to change behind scenes for all types of apps | 15:52 |
| ricmm | anyways, DONE with this session, next | 15:53 |
| rsalveti | jhodapp: ^ | 15:54 |
| rsalveti | right | 15:54 |
| jhodapp | rsalveti, sorry, had to run quickly | 15:58 |
| === ChanServ changed the topic of #ubuntu-uds-client-2 to: Track: Client | Need to find alternatives for the SRU process | Url: http://summit.ubuntu.com/uds-1311/meeting/22100/client-1311-webapps-sru-alternatives/ | ||
| dbarth | hi | 16:04 |
| dbarth | didrocks: are your running this one? | 16:04 |
| greyback | o/ | 16:04 |
| didrocks | dbarth: robru is going to | 16:05 |
| didrocks | dbarth: https://plus.google.com/hangouts/_/76cpiqsrkccej2hpsej2g4bim0?authuser=0 | 16:05 |
| dbarth | cool | 16:06 |
| dbarth | we're on | 16:06 |
| cjwatson | https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-March/000550.html | 16:22 |
| cjwatson | found it at last | 16:22 |
| cjwatson | the phrasing was for things that come from upstream, but ... | 16:23 |
| cjwatson | my example of a currently-outstanding failure is bug 1097833, which I appreciate was for quantal | 16:27 |
| udsbotu | Ubuntu bug 1097833 in webapps-applications (Ubuntu Raring) "GooglePlus.js test fails" [Undecided,New] https://launchpad.net/bugs/1097833 | 16:27 |
| cjwatson | (in fact, that one has failed twice) | 16:28 |
| Laney | The process should apply to all webapps, not just the ones that Canonical provides support for | 16:47 |
| Laney | yeah, that | 16:47 |
| robru | didrocks, we are wrapping up soon | 16:53 |
| didrocks | robru: ok | 16:53 |
| Laney | you already covered that | 16:54 |
| Laney | don't know how much lag I have | 16:54 |
| robru | Laney, there's usually a couple minutes lag I think. was just trying to be responsive to IRC ;-) | 16:54 |
| dbarth | i am incorrigible, i know... | 16:54 |
| === ChanServ changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/client-2/ - http://irclogs.ubuntu.com/2013/11/21/%23ubuntu-uds-client-2.html | ||
| === ChanServ changed the topic of #ubuntu-uds-client-2 to: Track: Client | Desktop Web Apps | Url: http://summit.ubuntu.com/uds-1311/meeting/22074/client-1311-desktop-webapps/ | ||
| dbarth | https://docs.google.com/a/canonical.com/presentation/d/10vetdx3_muY4MCneztuKYD55RtifkryNNmfxwMVObXc/edit#slide=id.g1246cfde2_07 | 18:01 |
| qengho | hi, D. | 18:07 |
| oSoMoN | didrocks, can you send me the link to the hangout? | 18:07 |
| alex-abreu | qengho, hey ! | 18:07 |
| alex-abreu | oSoMoN, https://plus.google.com/hangouts/_/7acpimdnnn05mhnr489us6bccc?authuser=0 | 18:08 |
| didrocks | alex is so fast! | 18:08 |
| alex-abreu | oSoMoN, hoefully that's the right one | 18:08 |
| alex-abreu | oSoMoN, yeah efficiency is the key for T ! :) | 18:08 |
| alex-abreu | oops | 18:08 |
| alex-abreu | didrocks, ^ | 18:08 |
| oSoMoN | alex-abreu, thanks | 18:09 |
| didrocks | yep ;) | 18:09 |
| qengho | YAY | 18:27 |
| chrisccoulson | hah :) | 18:27 |
| qengho | It dies in Cr32, I am pretty sure. | 18:29 |
| qengho | NPAPI^ | 18:29 |
| qengho | Or 33? Something. | 18:30 |
| qengho | Yes, soon. The current Dev channel, I think. | 18:30 |
| qengho | Now +2 | 18:30 |
| qengho | I do not think that we didn't say would stop Phoronix from reporting it. | 18:41 |
| chrisccoulson | in that case, we're switching to w3m | 18:41 |
| alex-abreu | qengho, now it is mentioned in the irc logs at least ! ... | 18:42 |
| qengho | I heard the DEFAULT WEB BROWSER is going to be XEMACS. | 18:42 |
| chrisccoulson | lol | 18:42 |
| robru | dbarth, yep, i can review | 18:55 |
| dbarth | robru: cool | 19:00 |
| dbarth | thanks everyone | 19:00 |
| alex-abreu | thx | 19:00 |
| === ChanServ changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/client-2/ - http://irclogs.ubuntu.com/2013/11/21/%23ubuntu-uds-client-2.html | ||
| === bfiller is now known as bfiller_afk | ||
| === bfiller_ is now known as bfiller | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!