[00:01] RAOF, Given we know the dimensions of the output, we want to know our logical position within that box. Where we are on screen is actually up to the shell, a client just wants its windows to be logically layed out inside that bo [00:01] x [00:02] In a multi-window app, the windows are not relative to eachother, but we probably want to place them in a particular space [00:04] What do you mean by a particular space? [00:05] Oh, by “surface relative” I *don't* mean “moves with the parent surface” (except for special types, like popovers). [00:06] I mean I have two windows in my app (both toplevel) which are rectangles in some particular space (i.e. the monitor size). They should be placed so they relate to eachother in some way (one on the left, one on the right perhaps) [00:06] It would be arbitrary to say place window B relative to A [00:06] They are really placed more based on the monitor than each other [00:07] Decorations of course make this a bit impossible [00:09] But people are going to be able to move those windows freely around? [00:09] yeah, the shell can do what it likes [00:10] It feels like relative positioning where the windows aren't linked in movement (i.e. useful for things like tooltips) doesn't give us any advantages [00:12] Well, I can easily give you an abstract coordinate space to work in, as long as you don't mind that it doesn't map to an output. [00:12] RAOF, that seems appropriate to me [00:13] But this also seems like an API that's there because that's how it's currently done; will an app ever care that the window is 10 units to the right rather than 20 units to the right? [00:13] ie: Would it perhaps make more sense for the API to allow the application to say “put this window to the right of that one” [00:14] But do we have a good definition of what "to the right of" means? Won't that be shell dependent [00:14] Yes. [00:14] But that's the case with a coordinate space, too. [00:15] And, in your example, the user can move the windows around themselves, so it's clearly not critical that the A be to the left of B. [00:16] And if the API has _explicit_ semantics, rather than the implicit semantics of a coordinate space, shells have a better chance of doing the right thing. [00:17] eg: I'm a tiling shell; I care not at all for your pesky coordinates! But “please put A left of B” still makes sense in the tiled world. [00:17] I'd like to see the list of logical positioning [00:18] RAOF, ok, but subwindows (i.e. tooltip/menus) they do use a co-ordinate space relative to their parent window? [00:18] Right. [00:19] so when can I have that :) [00:19] After you get eventloopyness :) [00:19] That bit shouldn't be terribly hard to do. [00:20] Although it means fiddling with IPC, which I find endlessly awkward. [00:20] RAOF, and grabs - are they just "this child surface receives all events for its relatives"? [00:21] Of course, that's the Mir bit that you can get; Unity8 will get support for that on its own timeline. [00:21] Urgh, grabs. [00:21] yes [00:21] Yeah, need to work out exactly what we mean by them. [00:21] Client level grabs seem fairly sound to me, I can't think of another method to do them [00:22] Obviously anything higher than that is not allowed [00:22] You could almost implement client level grabs entirely in libmirclient I guess [00:22] Yes. [00:22] Is that what we want, though? [00:23] That means we'll have different behaviour for eg: menus to what we currently have. [00:24] Actually, you could implement client-level grabs in the toolkit. [00:25] But is that just a hangover of the "X way to doing things"? As I can see all we want for menus is to get the motion events and click events inside the menu surface, and just handle clicks outside them (to dismiss them). Any other clients surface that gets an event should give some sort of focus out event which is sufficient to dismiss the menus [00:27] That does mean that you need to click on the owner's surface in order to dismiss menus without doing something else. [00:27] I'm not sure to what extent that's a problem. [00:28] What I was thinking of doing is handling the dismissal for you - when clicking outside a surface of type popover (or whatever) we kill the popover. [00:28] (And don't otherwise deliver the event) [00:28] I was also wondering if that's sufficient (I think it might be) [00:34] food for thought. Speaking of food... bye! [00:34] Lunch! [06:48] mvo: hey! tell me when you get some time to have a look at this "done" callback which is called [06:49] didrocks: now? [06:50] mvo: sure!, so git clone git@github.com:didrocks/ubuntu-developer-tools-center.git [06:50] then, the easiest is to create a virtualenv I guess (as per README.md): [06:50] $ virtualenv --python=python3 env [06:50] $ env/bin/pip install -r requirements.txt [06:50] $ source env/bin/activate [06:50] and finally, to get a test which pass, but with all debug infos: [06:50] didrocks: hm, ubuntu-.*-center is taken ;) and is has to be centre and its a bad omen :P [06:51] * mvo hugs didrocks - just kidding of course [06:51] nosetests -c log-confs/debug_test.cfg tests/small/test_requirements_handler.py:TestRequirementsHandler.test_error_in_dpkg [06:51] mvo: ahah, really true! Totally forgot about that discussion [06:51] * didrocks hugs mvo back [06:52] tell me if you see the test_error_in_dpkg test running (and passing) with all debug logs printed [06:58] didrocks: its building [07:00] didrocks: ok, tests is there now and runs and passes, what should be different :) ? [07:01] mvo: so, you should have as debug message: [07:01] 2014-06-12 09:01:05,002 [udtc.network.requirements_handler] DEBUG: ['testpackage'] install update: 0.0 [07:01] 2014-06-12 09:01:05,114 [udtc.network.requirements_handler] DEBUG: Install for ['testpackage'] ended. [07:01] I wouldn't expect the last one (the install ended) [07:01] look at udtc/network/requirements_handler.py [07:02] logger.debug("Install for {} ended.".format(self._bucket['bucket'])) [07:02] line 161 [07:02] in finish_update() [07:02] from class _InstallProgress(apt.progress.base.InstallProgress): [07:02] which is the install progress handler I installed on commit() === Saviq is now known as Saviq|QtCS [07:07] didrocks: ok, give me a sec to read over the test etc [07:28] didrocks: sorry, took a while to read through this stuff (and I was distracted for a sec) [07:28] didrocks: so, why should finish_update() not be called? its done, even thought there is a error [07:29] didrocks: don't get me wrong, I'm asking so that I can improve the docstrings :) [07:29] didrocks: not to blame you that you use it wrong :) [07:29] * mvo creates a feature/didrocks branch [07:30] :) [07:30] mvo: yeah, and you told error() were for errors outside of dpkg, right? [07:30] (and I should add that the name "finish_update" really sucks [07:30] didrocks: yeah, error() is called for error message that dpkg --status-fd generates [07:30] (sounds like a method naming chosen by a French :p) [07:31] didrocks: its terrible, sometimes I whish I could have a timemachine [07:31] to talk to my former self about certain decisions :/ [07:31] hum, so the only way is the exception that is raised… which is fine I guess, but the docstring should mention finish_update is always called unless error() is called, and that error is only for errors in… [07:32] mvo: but that would create some time corruption! [07:32] don't do it, please ;) [07:32] at most, leave a paper on your former desk :p [07:33] didrocks: hm, finish_update should be always called, is that different from what you see? [07:34] hum, let me try to see if I can raise an error() [07:38] didrocks: how does http://paste.ubuntu.com/7632429/ look? [07:38] mvo: sounds good! [07:38] didrocks: I will look into the other issues you raised too (i.e. returning boolean states for the mark_install and friends) and provide a installprogress that logs or some file etc but one step at a time :) [07:38] I can't reproduce the error though [07:38] didrocks: so keep the feedback coming [07:39] mvo: will do! thanks for fixing those :) [07:39] didrocks: you can't reproduce that finish_updates() is not always called? [07:39] no, I thought I would raise an error first for my current test case [07:39] like testpackage and testpackage2 [07:39] trying to install them together [07:39] with testpackage2 breaks (I tried conflicts as well) testpackage [07:40] didrocks: it seems like the (few) people using python-apt are so used to its warts that they don't see those (obvious) problems, so your feedback is very valuable [07:40] didrocks: best is to have a breaking maintainer script [07:40] didrocks: i.e. postinst with exit 1 [07:40] didrocks: to trigger the error() method [07:40] mvo: will create a package like that in a sec [07:41] mvo: on the other one, shouldn't I get any feedback when I try to ask for something I can't? [07:41] like this testpackage and testpackage2 [07:41] it's installing happily testpackage2, unmarking testpackage for install [07:41] before commit() [07:41] didrocks: the resolver will not allow it [07:42] didrocks: yeah, it will "fix" it for you unless you use "auto_fix=False" in mark_install() [07:42] didrocks: in which case iirc commit() will raise a exception if you try to commit a broken cache (might be worth double checking though and is probably a good test-case for python-apt itself) [07:42] ah ok, it's not on of my use case I guess (handling that manually), but as I was trying to get some more testing… :) [07:42] let me check with auto_fix=False [07:42] just to see :) [07:43] mvo: yeah, so it sent error() [07:44] as I tried to commit a broken cache() [07:44] (so not only broken maintainer script) [07:44] no exception though [07:44] ah, sorry, one exception as well [07:44] so: [07:44] 1. calling error() [07:45] 2. raising SystemError [07:50] ok [08:05] hey hey [08:05] good morning desktopers [08:05] hey Laney! [08:05] how are you? [08:06] I got told off in #ubuntu-ci-eng overnight! [08:06] other than that good ;-) [08:06] lol [08:06] what did you do this time? [08:06] it's quite fine today 22° [08:06] same here, nice to be back to less hot weather [08:06] "broke the rules by doing an upload without using ci train in the first place. [08:06] " [08:06] lol [08:07] tell them than french train are not working this week (which is true, they are unhappy about changes being discussed) [08:07] grrrr [08:07] what source did you upload? [08:07] I think it was dbus-test-runner like months ago [08:07] I even did a merge proposal ... [08:08] oh [08:08] * Laney grump [08:08] right, they landed that this night [08:08] ignore them, they like to complain [08:14] hey seb128, Laney! [08:14] lut didrocks, wie gehts? [08:14] seb128: don't start speaking about french train… [08:14] * didrocks will have to suffer from this in few hours :) [08:14] otherwise, good! [08:14] heh [08:15] did you go for morning exercice today? [08:15] not yet, was planning to go in 15 minutes [08:15] hey didrocks [08:15] finishing up as many tests as possible before :) [08:15] how's being an apt client treating you? [08:17] for testing, I'm getting a lot of questions ;) [08:17] but nicely, mvo is fixing up the documentation on my feedbacks :) [08:17] so I should be done in a couple of hours to finish those tests (already at 70%) [08:18] Laney: I'm looking at the aptdaemon adt issue right now [08:18] mvo: awesome, thanks! [08:19] did you fix the apt issue too? ;-) [08:19] Laney: almost! [08:19] Laney: apart from being grumpy to be layed off the train, everything's good? :) [08:20] Laney: for some reason my adt-run behaves differently from the jenkins one for the apt tests, but I'm close [08:21] mvo: I meant bug #1328838 [08:21] bug 1328838 in apt (Ubuntu) "Can't x-build ubuntu-system-settings with 1.0.4ubuntu1: /usr/lib/arm-linux-gnueabihf/libapt-pkg.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'" [Undecided,New] https://launchpad.net/bugs/1328838 [08:21] are you running adt in the proper VM-y way? [08:22] or is it lxc? [08:22] I forgot what the proper way is currently. :( [08:22] Laney: I guess not, schroot or lxc [08:22] mvo, Laney: slangasek reverted to gcc-4.8 default because of an ABI change in c++ in 4.9 it seems ... maybe that's what hit libapt there? [08:23] gcc-defaults (1.128ubuntu4) utopic; urgency=medium [08:23] * Revert default to 4.8, due to as-yet-undiagnosed C++ ABI breakage [08:23] (LP: #1329089). [08:23] Launchpad bug 1329089 in location-service (Ubuntu) "g++-4.9 binary incompatibilties with libraries built with g++-4.8" [Critical,New] https://launchpad.net/bugs/1329089 [08:23] just mentioning it in case [08:23] oh, could be [08:23] yeah, that sounds more like it [08:23] can you do a uss cross-build to see? [08:23] that apt went to release so it should happen there too [08:23] now [08:24] * seb128 tries [08:27] Laney, do I need to do anything to update my chroot or just run the sbuild command and see if that success? [08:27] it updates itself before building, so you should be fine [08:28] k, seems it's doing that [08:28] you can do sbuild-update -udcar every now and again to update in the base chroot which means it has to do less each time [08:28] it's upgrading gcc and installing 4.9 [08:28] ok, thanks [08:29] actually, I was really pessimistic telling a couple of hours. All tested now :) [08:30] (creating the framework is always soooo long compared to add tests once it's done) [08:31] ;-) [08:38] and https://travis-ci.org/didrocks/ubuntu-developer-tools-center/builds/27384556 \o/ [08:38] I should try to disable fsync() for dpkg, I guess it's what are making the tests long… [08:39] hum, --force-unsafe-io [08:41] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613428 -> seems raphaël doesn't really agree to use that though [08:41] Debian bug 613428 in dpkg "dpkg --force-unsafe-io still calls fsync()" [Normal,Open] [08:49] seb128: Still breaks here [08:49] arr, tiheum just left. anyhow, hi everyone! wanted to ask whether there were plans for moving to the new icon theme in 14.10 [08:49] hmm I didn't get apt 3 yet though [08:49] Laney, where does it stop? it's 45% built here [08:49] same [08:49] ochosi, wait for tiheum to be back [08:49] we don't know [08:49] ochosi, ^ [08:49] lol [08:49] or not [08:50] oh crap :) [08:50] * seb128 is afaik for a bit [08:50] * ochosi has the feeling he's being ducked [08:51] tiheum: hi there! quickly wanted to ask whether there were any plans yet for the new icon theme in 14.10 (we talked about it during the 14.04 cycle, i'd be interested to add support for xubuntu to it) [08:51] :/ [08:51] haha [08:51] someone has an unstable connection there [08:52] ok, the win is 9s with eatmydata, let's keep it [09:00] mvo: waah, indeed it does build again with apt ubuntu3 [09:00] which used 4.8 ... [09:00] Laney: cool [09:01] uncool! [09:01] hm? at least we know the issue now [09:01] no? [09:01] well we know it's not apt's fault [09:01] still don't like toolchain bugs :) [09:01] we know its a subtle abi break in 4.8 vs 4.9 [09:03] and we even have a bugnumber [09:03] * Laney throws this hot potato to doko [09:15] mvo, my ears prick up at "4.8", "4.9" and "subtle abi break" [09:15] what's this? :) [09:17] chrisccoulson: https://bugs.launchpad.net/ubuntu/+source/gcc-4.9/+bug/1329089 [09:17] Ubuntu bug 1329089 in location-service (Ubuntu) "g++-4.9 binary incompatibilties with libraries built with g++-4.8" [Critical,Confirmed] [09:18] mvo, ah, interesting. I wonder if it contributes to bug 1328697? [09:18] bug 1328697 in Oxide "utopic build crashes at startup" [High,Triaged] https://launchpad.net/bugs/1328697 === vrruiz_ is now known as rvr [09:48] didrocks: https://github.com/mvo5/python-apt/compare/feature;didrocks?expand=1 [09:49] didrocks: more after lunch [10:38] Laney, I've a silo with u-s-s, https://launchpad.net/~ci-train-ppa-service/+archive/landing-001/ [10:38] Laney, do you want me to include lp:~laney/ubuntu-system-settings/timedate-tests-wait in it? [10:38] might be a good idea [10:38] let's wait for CI [10:38] k [10:39] the silo is a bit stucked atm anyway, so no hurry [10:39] need to wait mterry [10:39] he added depends on libunity-mir [10:39] which is not available on all archs and restricted our set [10:40] what's that for? [10:42] Laney, http://irclogs.ubuntu.com/2014/05/13/%23ubuntu-touch.html#t18:48 [10:42] is the reply I got back then when I asked [10:42] I see [10:57] Laney, u-s-s crossbuild worked for me btw, though dpkg-shlibdeps displayed some weird unresolved symbol errors for c++ atexit symbols [10:57] yeah don't know what that is [10:57] did you try with proposed? [10:57] apt only migrated 33 minutes ago [10:57] no [10:57] you might have had the old one then [10:58] I think I got confused by the versions and thought it had gone in earlier [10:58] well, it migrated now? [10:58] still, this new one works [10:58] great [11:03] * Laney looks at colord/gtk transition === MacSlow is now known as MacSlow|lunch [11:22] hey seb128, Laney [11:23] larsu: it failed again :( [11:23] colorchooser [11:24] hey darkxst [11:24] what up homie [11:24] Laney: impossible! [11:24] have had a pretty bad cold this week, so not a whole lot really [11:24] * larsu wonders why it works for him [11:25] am liking the cool weather though! [11:26] hah [11:26] I bet it's still warmer than here [11:27] larsu: http://paste.ubuntu.com/7633244/ [11:27] 10149 [11:27] sorry for the huge log [11:27] seb128, Larsu so CSD's etc are fixed in the gtk+ 3.12 upload? i.e. ok to upload things that use GtkHeaderBar once gtk propagates? [11:28] Laney, aren't you guys having a heat wave? we have winter so a somewhat mild 10-15C most days [11:28] it's about what you'd expect for june [11:28] 20-ish [11:29] darkxst: there are no fixes for header bars on windows in those patches [11:29] and there won't be [11:30] larsu, so what is happening with headerbars then? [11:30] apart from the usual Ubuntu GNOME wants them, and Ubuntu doesnt.... [11:31] we're keeping the old apps afaik [11:31] and make header bars work on compiz if people want to use an app without a title bar [11:31] you can do patches to make them conditional [11:31] Trevinho is fixing compiz to at least make them work properly [11:32] so for non-Ubuntu-default apps you can update them I think [11:32] I'd wait until this compiz work goes in though [11:32] Laney, I don't think its possible to patch the apps, that properly use the GtkHeaderBar API [11:33] in that case gtk needs to be patched [11:34] hey, csd apps are not ok, no [11:34] compiz/unity still don't handle them [11:34] darkxst: I looked into that and came the conclusion that it's not feasible without a big amount of work [11:34] even when they do, we need to see how much UI regression it creates [11:35] well, that's only about things used by default on Ubuntu desktop, universe apps ... it's up to app writers to let their users down, we can't fix the universe [11:36] * larsu remembers that quote. "We can't fix the universe" [11:36] darn, what good are MOTUs if they can't ^ ? [11:37] quite a few of our core apps are in main, since you guys stole them ;) [11:37] sure you can patch things to not set a headerbar [11:37] "stole" them [11:37] it's rather that GNOME took over things just because they happen to be hosted on their infrastructure [11:38] can't headerbars be shown conditionally, depending on the environment/desktop? [11:38] but let's not start arguing over that, it's not going to be constructive [11:38] ochosi, they can, it's "just" extra code for upstreams [11:38] but they need to get used that they don't get and UI working on GNOME and other desktops for free [11:38] sounds like a snippet that should be provided upstream, i guess that's always going to be the same code, no? [11:38] they have to do work to support the different envs [11:39] which most don't like, because it used to not be this way [11:39] no, it's modifying part of your UI [11:39] you have to put the stuff in the header somewhere else instead [11:39] which is going to be different per app [11:39] simple: toolbar [11:39] iit would be weird to have a toolbar with a cog icon only in it [11:40] i actually patched our theme in xubuntu (as a test) and when you hide the "close" button (we had the double-window-border issue) it looks just like a toolbar [11:40] seb128, I was being somewhat sarcastic with that comment, but it is a real problem! [11:40] right, that would be weird, but often headerbars have >1 item [11:40] darkxst, I know it is :/ [11:40] let's please not talk about this again [11:40] changing application's UI under their feet is not a good idea [11:40] so yeah, we are making unity handle those [11:40] if they want to support different desktops, it's pretty easy to do so [11:40] then we need to sort out the core apps issue [11:40] *how* it is done depends on the app [11:41] the default is "do not update, we need to sort them on the case by case" [11:41] the solutions can be [11:41] like seb128 said, it's not just a matter of converting a headerbar to a toolbar [11:41] - changing the app/patching it [11:41] - using a different one for Ubuntu [11:41] - doing a fork of the current version to use in Ubuntu [11:41] - other ideas? [11:42] seb128, headerbar dropping window controls and traditional titlebar (for unity etc) === ara is now known as Guest77001 [11:42] dropping control is not enough [11:42] you end up with having the app title in the wm decoration and then under it in a weird bar [11:43] aaaaaaaaaanyway! [11:44] do we have a list of the apps that people want to update and are blocked on that? [11:44] gedit is likely on that list [11:44] nautilus [11:45] we should have a blueprint with the list, so we can take notes for each case [11:45] seb128, nearly all the 3.12 apps are using headbars [11:46] I tried eog this week and it didn't seem to have those [11:46] terminal is the only one I can think of that isnt, but that is blocked by other stuff [11:46] right, eog might not, sushi doesnt but thats not in main [11:47] well, so [11:47] step 1 is to land the unity support [11:47] then we can start testing and see how things look [11:48] and step 2, UG runs of time again! [11:49] better suggestion? [11:49] "let's update, screw Ubuntu Desktop users, and see what we can do to sort it out" is not a better option [11:50] i know flavors maybe aren't as important as unity, but it'd also screw over xfce-based flavors [11:51] right [11:51] seb128, no that is not an option, and you know good well, we (well mostly I) have spent a good deal of time, making things compatible [11:51] likely some other less-used desktops as well [11:52] it's not just you [11:52] larsu did some patches last cycle [11:52] Trevinho is adding support to unity [11:52] so we are working on it [11:53] Laney, I meant from the ubuntu GNOME side [11:53] but yes, it's likely to take some time and put Ubuntu GNOME in a difficult position again [11:53] the easiest way to avoid that is to just fork the apps that you really want to update [11:53] the forks could be on our side [11:53] urgh [11:53] but just have a source for the old version and one for the new one [11:53] seb128, it totally makes no sense for us to for upstream code [11:54] ^fork [11:54] well, we have choise between, screw users, fork, patch, find other apps to use [11:54] decide we like headerbars [11:56] that's the "screw users" option [11:56] they are never going to be consistent with things using wm decorations [11:57] nor they fit our design [11:58] yes I get that but there needs to be a solution [11:59] well, I listed the options I see [11:59] neither are great [11:59] * larsu votes for "screw users" [11:59] not sure how much patching having different UIs required [12:00] seb128: a lot. If we want the newest apps in the gnome flavor, we should think about forking [12:00] but that's probably a lot of work as well [12:02] I don't know how fair it is to call it screwing users [12:02] it's not like we have a massive amount of consistency currently === alan_g is now known as alan_g|lunch [12:02] right there are already apps in main using psuedo-headerbars like nautilus [12:03] anyway I think patching to work without headerbars is most desirable and forking would be very sad [12:03] they're like opposite ends of the spectrum to me [12:03] darkxst: nautilus uses a pseudo-headerbar? How so? [12:04] Laney: also the most work [12:04] Laney: I agree though, that would be the best outcome [12:04] larsu, like the top toolbar minus window controls etc [12:04] Laney, we are mostly consistent on things like menus and windows behaviours [12:05] darkxst: but it has a titlebar and a proper window menu [12:05] but yeah, this is where the line between headerbars and toolbars gets blurry [12:06] like did we screw users by including the webbrowser-app? [12:06] I think it's not very good to use that kind of term [12:07] but yeah, first we need to get the support in compiz [12:08] Laney, yeah, I don't think the new webbrowser-app fits well on desktop atm [12:08] sorry for the wording :/ [12:08] would "user experience regression" be betteR? [12:09] firefox -> webbrowser app is quite a UX regression [12:09] webbrowser-app is a user experience regression yes, and I'm not happy about it either [12:11] I'd rather you avoid trying to label it at all :) [12:11] You present a list of options and each has different positives and negatives [12:11] eventually we take a decision [12:11] that's fair enough [12:12] It's clear that the csd fix is a prerequisite to anything which involves using that stuff though [12:13] now, /me moves on to fixing stuff :P [12:13] there's a weird problem with dbus-activation of whoopsie-preferences in u-s-s [12:14] Laney, I have hit a couple of wierd dbus-activation bugs since mid-way through trusy [12:14] trusty [12:14] I blame Qt or my own shitty code :) [12:14] what problems? [12:15] actually it's evan's code, not mine ;) [12:15]