[01:24] sorry i have no extra monitor , just tv and missing a second hdmi cable for reproduce it [01:25] oh that was a while ago :P [10:10] Pwnna, not sure what is extend (am running on Arch). I have no trouble wildly disconnecting my second monitor though. Can try to reproduce xrandr to internal only and then wild disconnect but not sure it'll help. in any case im tempted to say regardless of whether the bug is reproducible, the error handling behaviour in xfsettingsd could be defined better [10:45] i use nvidia driver and disconnect monitors all the time. i also have no idea what extend means [10:48] Pwnna , ali1234 extend dekstop to 2 monitors, instead of having one different desktop on each monitor [10:48] i didn't know there was any other way to do it? [10:48] there is other ways [10:49] its different when you extend it [10:49] i'd call that mirroring, not extending [10:49] you can have a window in half of both monitor at the same time [10:49] do you know what i mean? [10:49] yes, i know what you mean [10:49] this is the default method of doing multimonitor on nvidia, anything else would be pointless [10:49] thats what i understand from "extend monitor" [10:50] why would you specifically choose not to be able to drag windows across monitors? [10:51] you can duplicate the image [10:51] for example [10:51] or just disable one , and enabling the other.. [11:04] * ochosi is back after a long weekend [11:04] anything important i missed? [11:04] did anyone manage to get a hold of xnox? [11:05] nope [12:39] sidi: i just watched your XDC talk [12:42] ali1234, cool, any feedback/thoughts? [12:42] (especially negative :P) [12:43] is there any implementation of WSM that works? for example, i can write a program that requests WSM_SCREENSHOT and libwsm will either allow or deny it, but then what happens? [12:44] i mean, after i get permission to do something, how do i then actually do it? [12:57] We have a prototype that needs to be hooked and implemented by compositor devs who want to try it out [12:57] Martin will make a Weston implementation when he's back from holidays [12:57] the program just uses the normal API and then gets a response based on the policy [12:57] most of the API isnt designed in Wayland actually [12:58] because noone wanted to do it wrong :P [12:58] what is the "normal" API for eg WSM_SCREENSHOT though? [12:58] so i'm currently designing API [12:58] i dont think there is one yet [12:58] basically getting a framebuffer of the entire screen would be that API [12:58] currently it shouldnt be possible in pure Wayland (dunno about XWayland) [12:59] so basically libwsm tells compositor developers "place a hook in this function, and then get a reply from whatever backend is in use" [12:59] in practice, libwsm is just a draft [12:59] it'll change and improve [12:59] was more meant for KDE/GNOME/E19 and Weston devs to poke around and get their requirements written [12:59] for app developers this is irrelevant [12:59] all they need to do is to tell us what permissions they need [13:00] in a separate file, a bit like a .desktop file [13:00] packagers and distros are then free to modify these permission files if they disagree [13:00] i see that as a problem [13:00] why? [13:00] because desktop developers don't need permissions, app developers do [13:00] if you ask GNOME what permissions they want to export, they'll say "none" [13:01] ali thats not what i meant [13:01] what i mean is, desktop compositor developers are responsible for using the library [13:01] to verify that a specific app has permission [13:02] so, if i implement in an hypothetical wayland xfce compositor a method for taking a screenshot [13:02] i would call libwsm with the wayland socket of the requesting client [13:02] libwsm would find the client, find the backend and policy used on the OS, and would return one of several possible recommendations [13:02] and then compositor must decide what to do with this [13:03] app developers provide a file with their source that tells what their app does, and distros verify it when packaging the app [13:03] (which is what windows, ios, os x and android do, virtually) [13:03] so my point is, what's the point of a cross-DE permissions system, if there is no cross-DE API for it to protect? [13:03] then everyone is free to provide GUIs of their liking, the API is flexible and so generic and dumb you can do whatever you want with it [13:03] the API is meant to be cross-DE [13:03] Wayland essentially defines an API, but some bits are not done yet [13:04] that's not what they told me [13:04] for instance Weston has a custom Fullscreen API because people (gnome/weston/kde/tizen) havent standardised it yet [13:04] most API should be X-DE [13:04] wayland developers told me wayland will never implement these things by design [13:04] otherwise theres no point to doing Wayland [13:04] well yeah, that's what i said [13:04] well wayland doesnt implement things, it's just a spec [13:05] ali1234, Martin who was working with me just informed me he pushed libwsm into libwayland [13:05] so yeah i would assume that some of the API will be standardised [13:05] i would also assume some of it will not, because only some DEs implement it [13:05] this is very grey area so far, most of this work has yet to be done... [13:07] ali1234, who is it you talked to? [13:07] jasper mainly [13:13] yeah [13:14] Jasper explicitly stated that he thinks libwsm is stupid and that we dont understand security [13:14] lol [13:14] he also does not seem keen at all on anything being cross-DE [13:14] so you know.. [13:15] so here's a thing, did you think about this situation? say a compositor has one single API to intercept both keyboard and mouse, which permission does it request? can it requests both at once, or do you get two requests sequentially? [13:15] so, in the case it has a single API it does not mean the calls are not separate dwithin this API [13:16] i fail to see how a client can need within an atomic call to modify both mouse and keyboard [13:16] i've never seen such API in my life [13:16] well it might be that the compositor just designed the api that way [13:16] in any case if it were to exist, either the compo dev believes this is really a combined use of both APIs, and it requires both permissions [13:16] or the dev believes the semantics dont match and that API has another purpose (and morei mportantly a different attack surface / threat model) and then a new permission can be made [13:16] and integrated into the backend i wrote [13:17] ali1234, move_keyboard_and_mouse_at_the_same_time (...)? :P [13:17] it was just an example [13:17] well, you're right this situationwill occur [13:17] libwsm is just a prototype, not an injunction [13:18] i think jasper took it as "two idiots who never wrote a compositor are telling me what to do and they have no clue what we actually need". it's partly a fair point and partly the fact that he didnt get a specification or a list of requirements for his security model, yet he is close to feature parity with X [13:19] we've made something dumb and simple and we're essentially asking DEs to identify how this dumb thing fails them, so we can try to develop something that matches requirements for each major DE and has decent flexibility for the future [13:19] i disagree that any wayland compositor has anywhere near close to feature parity with X [13:19] doesnt GNOME Shell have fullscreen, screenshot, clipboard? [13:19] well they probably still use the old X APIs actually [13:20] yeah it has them if you are using the GDK X backend [13:20] but they want to switch this to default in Fedora/GNOME asap dont they? which means "we wont change the APIs" [13:20] in the wayland backend it's all //TODO: implement this [13:20] and there's no way to implement it [13:20] the problem is the clipboard API especially is broken, it allows too many attacks and even worse it doesnt even allow apps to do basic stuff in a secure way (you cant query the type of data in the clipboard to check if your app supports it without pulling the data) [13:21] also fullscreen, screenshot, clipboard is nothing like feature parity anyway [13:21] (errata to what i've said before, my friend didnt push libwsm into libwayland-trunk but into a testing branch of libwayland :p) [13:21] fair enough [13:21] you need things like WSM_RAISE_FOCUS_OTHER, WSM_POSITION_RESIZE(_OTHER) [13:21] good points [13:21] ability to get information about other clients [13:23] even maybe ability to draw into other client's surfaces [13:23] or at least around them :) [13:23] that really should be done via IPC or UI composition [13:23] either the apps collaborate to produce something, or clearly separated UI elements are embedded within one another [13:24] if you have other ideas of capabilities, or issues with the existing ones do ping me ali1234 ! [13:26] also, why is screenshot and screensharing separate? [13:26] if i get screenshot permission, can't i just keep doing it over and over? [13:26] you could ask every time, but that is going to get annoying [13:27] most likely the screenshot tool is just going to be set to "always allow" by the packager [13:27] in which case they've defacto received screensharng permission to [13:28] i suppose something like skype you would want it to ask permission every time [13:30] also worth considering that there are input devices other than keyboard and mouse [13:31] like joysticks for example, or leap motion, or oculus rift head tracker [13:31] or other weird haptic things [13:34] although i suppose the "core pointer" as X calls it is not really tied to any specific hardware, it's an abstraction [13:37] i should subscribe wayland-devel [13:57] folks, i won't make tomorrow's meeting, it's unfortunate, but it's a conflict of appointments :/ [13:57] or: another conflict.... [13:59] that's okay, the meetings are much more pleasant without you whining anyway [13:59] oops ;) [13:59] no seriously, meh, but maybe you're around and available at other times tomorrow if somebody needs something? [14:02] heh [14:02] yeah, i'll try to be [14:02] VV is called Vivid Vervet [14:02] at least during what is my morning [14:02] http://www.markshuttleworth.com/archives/1425 [14:02] oh [14:02] hadnt read that yet [14:03] yeah, just accidentally bumped into that when checking the planet [14:27] respins tomorrow [14:27] hey elfy [14:27] hi ochosi [14:46] the xfce4-weather-plugin is failing, see https://forum.xfce.org/viewtopic.php?id=9163 , fixed version is 0.8.3-5 apparently, trusty ships -1, and utopic will -2, so it will fail [16:40] I guess we're not going to eat anybody's lunch in 15.04 :-( http://www.markshuttleworth.com/archives/1425 [20:16] "Document es/index.xml does not validate" dangit. [20:17] migrating-upgrading.xml:315, settings-preferences.xml:373, media-apps.xml:323. [20:18] Unit193, oi, fail :) [21:12] bluesabre: https://code.launchpad.net/~brunonova/ubuntu/trusty/xubuntu-default-settings/lp1310264/+merge/238935 [21:13] it's a minor UI change, so the fix has not been backported yet [21:13] https://twitter.com/RLUK_Mike/status/517243907193970688 [21:14] knome: Nice. [21:45] who is that? :D [21:46] i should already know right ? xD