| mhall119 | mas: you might be interested in http://design.canonical.com/2012/01/launcher-reveal-prototype/ and leaving your preferences in the comments | 00:00 |
|---|---|---|
| mhall119 | jono: shell or django? | 00:00 |
| jono | mhall119, django | 00:00 |
| mas | i've been contemplating it myself, i was thinking moving it to the bottom might help but shuttleworth keeps has some obsession with everything having to be to the left. it would also be nice to see some sort of feedback from the buttons in the launcher, like when the mouse is over them they glow or hover. they feel so "static" | 00:00 |
| mhall119 | jono: sure, give me a minute | 00:01 |
| jono | mhall119, thanks! | 00:01 |
| mas | oh thanks mhall, i'll leave some comments | 00:02 |
| mhall119 | mas: it's not so much wanting it on the left, it's wanting it to use up the dimension you have the most space in | 00:03 |
| bgois | mas, some hover or glow might be really good for button feedback. | 00:03 |
| mhall119 | I'd rather lose 48px of 1024, than 48px of 786 | 00:03 |
| bgois | If my opinion and experience with unity on corporate machines. The launcher hidding and revealing it self on left side confuses people. | 00:05 |
| bgois | I wonder my self, if the launcher be moved to bottom it could looks a lot like the win7 bar. But it would be a lot easier to switch betwen tasks. | 00:06 |
| mas | hmm, i've heard that argument before about losing in the horizontal versus the vertical. not to say i disagree...however i never hear anybody talk about symmetry. it can sometimes be visually unpleasant. also the space argument doesn't really matter when you maximize as the launcher disappears anyway | 00:06 |
| bgois | mhall119, your observation makes sense in the logical point of view. But, from a usability vision, users are used to look at the bottom bar and find its running apps and menu. i think. | 00:08 |
| mas | what has confused me about the entire argument is why the option of not being able to move it around to any side the user wants is not desired. that was something i always admired about *nix desktop environments. i rarely deviate from the default desktop, but sometimes one or two tweeks depending on the end user's workflow can make a world of difference | 00:09 |
| mas | i mean even mac, the ultimate in controlling the end user's experience let you move the dock around | 00:11 |
| htorque | i wonder how RTL language users feel about it | 00:12 |
| === htorque_ is now known as htorque | ||
| w3r3wolv3s | quit | 00:22 |
| mhall119 | bgois: it doesn't take that long to learn to look on the left | 00:23 |
| mhall119 | we shouldn't treat users as if they are incapable of learning a better experience | 00:23 |
| mhall119 | htorque: that's an interesting question | 00:24 |
| thumper | hi mhall119 | 00:42 |
| thumper | are we moving all ayatana chatter here?\ | 00:43 |
| thumper | what else what talked about on ayatana? | 00:44 |
| thumper | htorque: I'd love to see some research on RTL languages and launcher expectations | 00:45 |
| mhall119 | thumper: moving it here | 00:45 |
| mhall119 | we'll put in a redirect on #ayatana in about a week | 00:45 |
| thumper | mhall119: we should have a call next week | 00:45 |
| thumper | I'm not actually working today | 00:45 |
| mhall119 | thumper: yes please | 00:45 |
| thumper | 62 hours travelling home | 00:45 |
| thumper | just back this morning | 00:45 |
| mhall119 | eeew | 00:45 |
| mhall119 | sure, I'm pretty flexible, so whenever is good for you | 00:45 |
| thumper | mhall119: where are you based? | 00:46 |
| mhall119 | USA, east-coast | 00:46 |
| thumper | ah cool | 00:46 |
| thumper | just 3 hours different then | 00:46 |
| thumper | perhaps Monday afternoon your time | 00:46 |
| mhall119 | I assume you're west-coast then | 00:46 |
| thumper | that matches up with after lunch tuesday for me | 00:46 |
| mhall119 | or the middle of the atlantic | 00:46 |
| thumper | Nope | 00:46 |
| thumper | NZ | 00:46 |
| mhall119 | wait... | 00:46 |
| thumper | well three hours + one day | 00:47 |
| thumper | three hours ahead and a day behind | 00:47 |
| mhall119 | that still doesn't sound quite right, what time is it there now? | 00:47 |
| thumper | 13:47 | 00:47 |
| thumper | damn | 00:47 |
| mhall119 | ok, so 6 hours different | 00:48 |
| thumper | east and west mix up again | 00:48 |
| mhall119 | that sounds better | 00:48 |
| thumper | I do that all the time | 00:48 |
| mhall119 | no problem | 00:48 |
| thumper | you are in the same tz as lamalex, DBO, and jay | 00:48 |
| mhall119 | and I don't know any of them.... :( | 00:49 |
| thumper | you were ISD before? | 00:49 |
| mhall119 | yup, until the end of December | 00:49 |
| thumper | just looked you up on the directory | 00:50 |
| mhall119 | thumper: give me a ping monday morning (your time) and we'll setup a time for a call | 00:50 |
| thumper | I don't think we've met have we? | 00:50 |
| mhall119 | maybe in passing at UDS | 00:50 |
| thumper | I've not been to a UDS since Boston | 00:51 |
| mhall119 | ok,then not in passing at UDS | 00:51 |
| thumper | even then, it was a co-located launchpad sprint | 00:51 |
| mhall119 | you were in the launchpad team? | 00:52 |
| thumper | for 4.5 years | 00:52 |
| thumper | switched last April to DX | 00:52 |
| mhall119 | then it's very possible that I've bugged you about something before ;) | 00:52 |
| thumper | which is now product strategy | 00:52 |
| thumper | maybe | 00:52 |
| mhall119 | summit or loco-directory perhaps | 00:52 |
| * thumper has to head off for stuff | 00:53 | |
| thumper | we'll chat next week | 00:53 |
| === Justin____ is now known as Justinba1010 | ||
| Justinba1010 | hello | 01:41 |
| Justinba1010 | anyone here? | 01:42 |
| === JoseeAntonioR is now known as JoseeAntonioR1 | ||
| === JoseeAntonioR1 is now known as JoseeAntonioR | ||
| Caio | Hello. Is here the best place to give suggestions about Unity? | 02:50 |
| === nick is now known as Guest94462 | ||
| marcosroriz | Hi guys | 03:28 |
| marcosroriz | I'm running natty here, I think I found a 'security' bug in Unity | 03:28 |
| marcosroriz | Can someone confirme me if it happens on oneiric?? | 03:28 |
| vadi2 | Sure. | 03:28 |
| marcosroriz | The bug is the following: | 03:29 |
| marcosroriz | 1 - Press the super key (will launch unity 'default' view) | 03:29 |
| marcosroriz | 2 - Wait to computer to block | 03:29 |
| vadi2 | block? | 03:30 |
| marcosroriz | As in session block | 03:30 |
| marcosroriz | As you can see, you can still do a one time usage of unity. | 03:30 |
| vadi2 | Ah so the lock screen? | 03:30 |
| marcosroriz | yep | 03:30 |
| marcosroriz | the lock screen dont appear directly, you can 'use' unity for a command | 03:30 |
| marcosroriz | I think what happen is that the unity launcher stays on top of the gnome-lock-screen | 03:30 |
| marcosroriz | and you can use unity one time, once it dissapears (the unity windows) it goes to the password of the lock screen | 03:31 |
| vadi2 | I'll see | 03:31 |
| marcosroriz | Try it :) | 03:31 |
| marcosroriz | Put your comp session lock < 2 min | 03:31 |
| marcosroriz | and press the super :) | 03:32 |
| marcosroriz | wait, and profit | 03:32 |
| marcosroriz | you'll get the chance to explore unity hehe, once you get out of the unity screen the computer goes to the lock screen (session) | 03:32 |
| marcosroriz | :~ | 03:32 |
| marcosroriz | I don't know if this is a security bug, but IMO after the period that you specified (for instance, 2min) your computer should go automatically to the gnome-session screen with the pass. | 03:34 |
| vadi2 | Did you hold the super key, or press and let go? | 03:37 |
| vadi2 | my screen turned off and locked, it came back to the lock screen though, not unity | 03:38 |
| marcosroriz | press and let it go | 03:38 |
| vadi2 | Yeah that's what I did, didn't happen here | 03:39 |
| marcosroriz | Strange :~ | 03:39 |
| === IdleOne is now known as pangolin | ||
| guest____ | hi all | 06:32 |
| guest____ | anybody here? | 06:33 |
| guest____ | whois JanC JanC | 06:34 |
| vadi2 | hello | 06:39 |
| vadi2 | bye | 06:39 |
| aslamckra | hello | 06:52 |
| kamstrup | does anyone know how we sort the lenses in the lensbar in the dash? | 08:31 |
| Saviq | kamstrup, preliminary look at 2d code says that we do whatever you guys give us | 08:34 |
| kamstrup | Saviq: yeah, and u3d also seems to take whatever comes out of the FilesystemLenses class | 08:35 |
| Saviq | kamstrup, yup, same here it seems | 08:35 |
| kamstrup | but the sorting order in the dash seems to be stable, so there must be something sorting it | 08:35 |
| Saviq | kamstrup, "m_unityLenses = new unity::dash::FilesystemLenses("/usr/share/unity/lenses"); for (unsigned int i=0; i<m_unityLenses->count(); i++) [...]" | 08:35 |
| kamstrup | maybe it's really just sorting on inode accurence within the /usr/share/unity/lenses dir... | 08:35 |
| kamstrup | Saviq: which order are your lenses in? | 08:36 |
| kamstrup | i have home, apps, files, music | 08:36 |
| Saviq | same here | 08:36 |
| Saviq | any additional get added later | 08:36 |
| kamstrup | hmmm, so something is likely to sort it | 08:36 |
| kamstrup | s/likely/certain | 08:36 |
| Saviq | yup | 08:37 |
| kamstrup | Saviq: AHA! vvvv | 08:37 |
| kamstrup | /FIXME: We don't have a strict order, but alphabetical serves us wonderfully for | 08:37 |
| kamstrup | // Oneiric. When we have an order/policy, please replace this. | 08:37 |
| Saviq | ookies | 08:37 |
| kamstrup | in FilesystemLenses | 08:38 |
| Saviq | yup, was just going there | 08:38 |
| Saviq | except the app lens seems to be forced first | 08:39 |
| kamstrup | ok, I am actually implementing that policy in my home-lenses branch, so I'll put it on my todo | 08:39 |
| kamstrup | right | 08:39 |
| Saviq | and we probably want the home lens to be first in Precise | 08:39 |
| Atem18 | Hi | 09:05 |
| Saviq | hey greyback | 09:22 |
| gord | mhr3, so your icon loading branch is great, but i think it needs tests - just one that loads a bunch of icons and makes sure they all come in | 09:27 |
| greyback | Saviq: morning | 09:27 |
| mhr3 | gord, i knew you'd said that | 09:28 |
| Saviq | frck! | 09:28 |
| nerochiaro | Saviq: I think I have addressed all your concerns in the shape tests branch. just pushed the last changes now | 09:36 |
| Saviq | greyback, we need to set locale to en_something in the tests.. | 09:36 |
| Saviq | otherwise I'll waste many more hours wondering what the frck | 09:37 |
| Saviq | or at least require a "en_*" locale for the tests | 09:37 |
| nerochiaro | Saviq: yep. but then we should also have some localization tests | 09:38 |
| greyback | Saviq: yeah. Getting tests running on every developers machine correctly is a pain. Why I want to use VBox | 09:38 |
| greyback | nerochiaro: agreed, and also needed for RTL tests | 09:38 |
| Saviq | greyback, still, I've changed the locale on my vbox to check out RTL yesterday | 09:38 |
| nerochiaro | greyback: Saviq: i'm also worried about some tests that will require resolution changes (for example to test the min size of the dash) | 09:39 |
| Saviq | and since then I couldn't, for the life of mine, understand why the tests failed | 09:39 |
| nerochiaro | (min size before it goes fullscreen by default) | 09:39 |
| greyback | Saviq: yep, my idea was to have a VBox Snapshot that everyone just uses and won't be changed | 09:39 |
| Saviq | greyback, that's not safe | 09:39 |
| Saviq | greyback, tests should work on virtually every machine | 09:39 |
| nerochiaro | greyback: yeah, but what do you do for tests where a certain feature is for a configuration that is impossible to obtain on a certain machine ? | 09:40 |
| Saviq | if we just have a snapshot that noone changes, the tests won't get enough coverage, tbh | 09:40 |
| nerochiaro | Saviq: ^ | 09:40 |
| Saviq | nerochiaro, example? | 09:40 |
| greyback | nerochiaro: you'll have to add checks to ensure the resolution is big enough for the dash not to be full-screen, and bypass the test with a warning maybe | 09:40 |
| nerochiaro | Saviq: multimonitor tests ? | 09:40 |
| Saviq | nerochiaro, true, what greyback said - just check whether the env is ready for the test | 09:41 |
| Saviq | and bypass it | 09:41 |
| Saviq | exactly what I want to do for locale | 09:41 |
| Saviq | check if it's en_whateveryouguysuse.UTF-8 | 09:41 |
| Saviq | and drop out of the test suite | 09:41 |
| Saviq | or change the locale for the duration of the tests | 09:41 |
| dyams | nerochiaro: saviq: In the shape-tests branch i checked move the dash bit away from launcher | 09:44 |
| dyams | nerochiaro: saviq:actually to the second screen | 09:44 |
| dyams | nerochiaro: saviq: the dash is no more visible there | 09:44 |
| Saviq | dyams, meaning multimonitor? | 09:44 |
| dyams | saviq: yes | 09:45 |
| Saviq | dyams, we didn't yet do anything re multimonitor in -shell | 09:45 |
| Saviq | dyams, but you need to remember there is no "dash" and "launcher" anymore | 09:45 |
| nerochiaro | yep, no multimonitor support in shell for now | 09:45 |
| Saviq | there's just a single window | 09:45 |
| Saviq | which has both the dash and the launcher | 09:45 |
| Saviq | so if you've moved the dash over screen, it will just go overscreen, not to the next screen | 09:46 |
| dyams | saviq: sure, but if i move the window bit away from launcher, then any portion of the dash falling outside the current screen is cut off | 09:46 |
| dyams | nerochiaro: saviq: Yes, I didn't expect it will work perfectly by just reposition it | 09:48 |
| dyams | nerochiaro: saviq: yet i didn't expect it will be clipped either. | 09:48 |
| Saviq | dyams, what are you repositioning? the whole shell window or just the dash inside? | 09:48 |
| Saviq | dyams, yes it will be clipped | 09:48 |
| Saviq | our window is the size of your current screen's available geometry | 09:48 |
| dyams | saviq: I reposition dash only | 09:48 |
| Saviq | if you go over that, it will get clipped, yes | 09:49 |
| Saviq | dyams, there's simply no support gone into -shell yet | 09:49 |
| dyams | saviq: i see , height: screen.availableGeometry.height | 09:49 |
| dyams | width: screen.availableGeometry.width | 09:49 |
| dyams | saviq: Ok | 09:50 |
| Saviq | nerochiaro, that fits into the merge-todo, do we have that there yet? | 09:50 |
| Saviq | nerochiaro, at least getting on-par with trunk | 09:50 |
| Saviq | nerochiaro, so you didn't manage to work with _NET_WORKAREA in the end? | 09:51 |
| nerochiaro | Saviq: i don't think we have it yet | 09:51 |
| Saviq | nerochiaro, ok I'll add it | 09:51 |
| nerochiaro | Saviq: i decided not to, it was quicker this way and i'll also be forcing the panel to be there for the dash button tests, so i thought might as well do the same in that case | 09:52 |
| Saviq | lazies :P | 09:53 |
| Saviq | ok | 09:53 |
| nerochiaro | Saviq: i'll add the test to verify the correct shape in absence of the dash when i add the ability for the shell window to correctly adjust in case the panel appears and disappears | 09:53 |
| Saviq | k | 09:53 |
| dyams | nerochiaro: saviq: 1) Invoke dash, 2) invoke spread, | 09:55 |
| dyams | 3) Cancel the spread | 09:55 |
| dyams | Now dash is reappearing | 09:55 |
| dyams | moreover now dash is not closing either | 09:56 |
| greyback | didrocks: welcome ;) | 09:56 |
| Saviq | hey didrocks | 09:56 |
| nerochiaro | dyams: sounds like a bug in shell. let's add to the TODO in the wiki please | 09:56 |
| didrocks | greyback: hey ;) Seems I need to add the autojoin here ;) the super + keynum seems to not work with the numpad in 2d, do you have a bug report on that? :) | 09:56 |
| greyback | didrocks: designers say it's not supposed to | 09:57 |
| greyback | dyams: ^^ | 09:57 |
| didrocks | hum? | 09:57 |
| didrocks | a lot of people marks the tests are failed because they try to use it | 09:57 |
| dyams | didrocks: greyback is correct | 09:57 |
| dyams | greyback: didrocks: actually super + numpad with launcher? Or with windows? | 09:58 |
| didrocks | dyams: launcher | 09:58 |
| didrocks | oh that will be the shortcut for maximinizing the window now | 09:59 |
| didrocks | forgot about it | 09:59 |
| Saviq | dyams, you need to run the spread from the shell branch | 09:59 |
| Saviq | nerochiaro, ^^ | 09:59 |
| greyback | didrocks: https://bugs.launchpad.net/unity-2d/+bug/750514 | 09:59 |
| dyams | didrocks: Super + Numpad [1] [2]....[0] Is not supported by launcher | 09:59 |
| didrocks | hey Saviq ;) | 09:59 |
| Saviq | nerochiaro, dyams: works fine for me, but you need to run the spread from the shell branch | 09:59 |
| nerochiaro | Saviq: oh, right, forgot that might be the issue | 09:59 |
| Saviq | not the installed one | 09:59 |
| dyams | saviq: trying again.. | 09:59 |
| didrocks | dyams: well, it was for Natty, but the design changed :) | 09:59 |
| greyback | didrocks: so no Super+numpad does same as Super+num ? | 10:00 |
| greyback | s/no/now | 10:00 |
| didrocks | greyback: in 3D right | 10:00 |
| dyams | didrocks: oh they changed it..? Or is it a bug in 3D? | 10:01 |
| nerochiaro | Saviq: let me know when you are done with the review, so i can pull it into another branch if it's ok, or fix what's wrong if not. thanks. | 10:01 |
| didrocks | dyams: I can tell for sure it's not a bug in 3D and they ask for it as I spent time to support it :) | 10:01 |
| gord | stop assuming things are bugs in 3d you guys :P | 10:01 |
| didrocks | anyway, there is this new shortcut stuff where it should maximize/semi-maximize window now | 10:01 |
| Saviq | nerochiaro, seems right already, I'm just verifying that the tests fail without the shell being shaped | 10:01 |
| dyams | didrocks: lemme crosscheck with the shortcuts gdocs once | 10:02 |
| greyback | didrocks: am consulting with design now :) | 10:03 |
| didrocks | thanks :) | 10:03 |
| didrocks | dyams: John showed me this gdocs, but I can't find it anymore | 10:04 |
| dyams | didrocks: hrer https://docs.google.com/a/canonical.com/document/d/1jqeKtIJwqLtl58Wk_fqjr9Rrgxn9zsouCYOo-cZsLSE/edit?authkey=CLGG9NkJ&hl=en_GB | 10:04 |
| didrocks | dyams: thanks | 10:05 |
| didrocks | dyams: hum, no, it's ctrl + alt in fact | 10:06 |
| didrocks | so nothing on super + numpad | 10:06 |
| didrocks | seems a lot of people expect it to do the same than super + keynum | 10:06 |
| greyback | didrocks: see the other channel :) | 10:06 |
| greyback | dyams: dust off that Super+keypad branch, it's going in :) | 10:08 |
| dyams | greyback: :) sure, I can do it... :) | 10:09 |
| dyams | greyback: should we wait for shell work or we merge it current trunk already? | 10:11 |
| greyback | dyams: as ultimately we'll be using shell, there's little point in merging it to trunk only. | 10:13 |
| greyback | dyams: see how easy it ports to shell | 10:13 |
| dyams | greyback: Ok, I'll work on shell branch | 10:14 |
| greyback | Saviq: I think adding features should be done to shell, if they don't apply cleanly to both branches. Otherwise we're making more work for ourselves | 10:15 |
| dyams | saviq: Yes, Spread works better if I launch it from shell itself | 10:15 |
| Saviq | dyams, "better"? not "correct"? | 10:15 |
| dyams | saviq: but that didn't solve the issue either | 10:16 |
| Saviq | greyback, true | 10:16 |
| Saviq | greyback, if they fit nicely in both - then both | 10:16 |
| Saviq | otherwise - shell it is | 10:16 |
| dyams | saviq: two issues i noticed. | 10:16 |
| greyback | Saviq: agreed | 10:16 |
| dyams | saviq: 1) Launcher won't stay open when spread is active, it disappears after a few seconds | 10:17 |
| Saviq | weirds, should be forcedVisible, add to the wiki please | 10:17 |
| dyams | 2) after 3-4 attemps dash stays open and won't go away | 10:18 |
| dyams | saviq: sure | 10:18 |
| dyams | nerochiaro: You already added the Dash clipping issue in wiki? | 10:35 |
| dyams | nerochiaro: Or is it not required? | 10:35 |
| Saviq | dyams, there's no "dash clipping" | 10:36 |
| Saviq | that is not an issue | 10:36 |
| dyams | saviq: Ok | 10:37 |
| Saviq | dyams, why would you move the dash itself anyway? | 10:37 |
| Saviq | the dash is supposed to be stuck to the launcher, and proper multimonitor support will come later | 10:38 |
| dyams | Saviq: multi-monitor | 10:38 |
| Saviq | dyams, we won't be moving it | 10:38 |
| Saviq | we will have a dash per-screen | 10:38 |
| Saviq | just as we will a launcher per-screen | 10:38 |
| dyams | Saviq: no | 10:38 |
| Saviq | dyams, I know, it will just be shown on one screen | 10:39 |
| Saviq | current screen | 10:39 |
| Saviq | but that doesn't mean we will necessarily move the window around | 10:39 |
| dyams | saviq: Ok | 10:39 |
| dyams | saviq: then it is like shell per monitor. no? | 10:40 |
| Saviq | dyams, yes | 10:40 |
| dyams | saviq: i got it :) | 10:40 |
| kamstrup | booyacacha mhr3, gord! nailed the home-lenses despite njpatel trying to trip me up with his tricks! :-D | 10:45 |
| gord | woohoo | 10:45 |
| gord | he's trixy | 10:45 |
| kamstrup | just adding some tests | 10:45 |
| kamstrup | then mp | 10:45 |
| gord | kamstrup, you know omg already wrote about this stuff right? can't disappoint them now ;) | 10:46 |
| kamstrup | gord: indeed :-) that kinda upped the pressure a bit... | 10:46 |
| kamstrup | gord: as you'll learn soon enough, this was not exactly trivial to get right | 10:46 |
| kamstrup | I basically wrote an in-memory relational db :-) | 10:46 |
| gord | oh dear, /me gets his finger over the rejected button | 10:47 |
| kamstrup | lol | 10:47 |
| gord | comment: stop re-writing mysql every six months | 10:47 |
| kamstrup | boring | 10:47 |
| kamstrup | it would actually be interesting to rewrite the internal lens handling by using in-mem sqlite tables. Will be quite fast, and actually not too ugly | 10:48 |
| mhr3 | kamstrup, so... i suppose the the merge diff in counted in dozen thousands lines? | 10:49 |
| mhr3 | is counted in*? | 10:49 |
| kamstrup | indeed | 10:52 |
| Saviq | nerochiaro, I'm pushing just the input shaping tests to lp:~saviq/+junk/shell-shapetests | 10:53 |
| Saviq | nerochiaro, can you try them? I can't seem to be able to fail them even without input shaping.. | 10:53 |
| nerochiaro | Saviq: how do you remove input shaping ? | 10:53 |
| Saviq | nerochiaro, still pushing, though | 10:53 |
| Saviq | nerochiaro, I just merged the commits that did the tests | 10:54 |
| Saviq | not those that actually implemented the feature | 10:54 |
| Saviq | nerochiaro, pushed | 10:54 |
| nerochiaro | Saviq: on top of unity-2d-shell ? | 10:54 |
| Saviq | nerochiaro, yes | 10:54 |
| Saviq | nerochiaro, btw, -shell has stuff merged from trunk again this morning | 10:54 |
| nerochiaro | i saw that | 10:55 |
| nerochiaro | let me try | 10:55 |
| Saviq | I freakin' can't fail those tests... wth | 10:55 |
| nerochiaro | Saviq: checking. might be something wrong with waht i do | 10:56 |
| Saviq | nerochiaro, btw that's why it's good to write the tests first, too ;) | 10:56 |
| Saviq | otherwise you never know if they actually fail :] | 10:56 |
| Saviq | or at least make it easy to only merge the tests and not the fix itself | 10:57 |
| Saviq | brb | 10:57 |
| nerochiaro | Saviq: you have a point | 10:57 |
| nerochiaro | Saviq: they don't seem to fail here neither. i'm looking into why | 11:04 |
| nerochiaro | Saviq: are you sure you picked up all my changes ? in your branch there's some commits missing it seems. i'm double checking i pushed all | 11:05 |
| nerochiaro | Saviq: revision 934 (which i added this morning) is the one that should make the tests properly fail | 11:06 |
| Saviq | nerochiaro, oh | 11:07 |
| Saviq | nerochiaro, will check out again in a bit | 11:07 |
| nerochiaro | Saviq: okies | 11:07 |
| nerochiaro | Saviq: i double check and i pushed all of them. the last on top of my branch should be 935 now | 11:07 |
| nerochiaro | greyback: Saviq: or anyone: panel buttons for dash submitted as an MR, for whoever wants to take it: https://code.launchpad.net/~unity-2d-team/unity-2d/unity-2d-shell-dash-panel-buttons/+merge/89414 | 11:19 |
| nerochiaro | i'll bbiab | 11:19 |
| davidcalle | kamstrup, about matching the sorting of lenses in the Home Dash to the lens bar. Would it mean that the lens bar wouldn't be sorted alphabetically on the lens name anymore? | 11:40 |
| kamstrup | davidcalle: depends... :-) | 11:41 |
| kamstrup | davidcalle: it could be, but not if we let users override | 11:41 |
| mhr3 | i can imagine that in some languages the ordering isn't what we want | 11:43 |
| mhr3 | unless it's being sorted on non-localized name | 11:44 |
| mhr3 | kamstrup, anyway so what was the thing you wanted me to look at yesterday? | 11:44 |
| kamstrup | mhr3: some tweaks to the music lens | 11:44 |
| davidcalle | kamstrup, ok. I'm just going to make an Aardwark lens to mess with you guys. ;-) | 11:44 |
| davidcalle | Aardvark* | 11:45 |
| mhr3 | kamstrup, oh dear :P | 11:45 |
| mhr3 | is there a bug opened? | 11:45 |
| kamstrup | mhr3: when doing global search, we need to collate the Songs and Albums categories into one Music category (with albums first) | 11:45 |
| kamstrup | mhr3: it's in relation to the new homescreen, it's mentioned briefly there | 11:46 |
| kamstrup | mhr3: I talked with JohnLea about it | 11:46 |
| kamstrup | mhr3: I have a partial branch ready... hold on I'll upload it | 11:46 |
| mhr3 | Dee.Transaction comes to rescue us :) | 11:46 |
| kamstrup | mhr3: you can save yourself a bit of time if you start from lp:~kamstrup/unity-lens-music/home-lenses | 11:49 |
| Saviq | nerochiaro, so here's what I'm doing: `bzr branch lp:~unity-2d-team/unity-2d/unity-2d-shell-shaped-testability-shapetests` | 11:59 |
| Saviq | nerochiaro, `bzr merge -r 913..907 .` | 11:59 |
| Saviq | there are two small conflicts | 11:59 |
| Saviq | but that gets rid of the actual shaping code | 11:59 |
| nerochiaro | Saviq: I don't understand why you do that merge | 11:59 |
| Saviq | nerochiaro, I want to get rid of the actual shaping | 12:00 |
| nerochiaro | Saviq: to test that the tests fail ? | 12:00 |
| Saviq | I want to have shell with shape tests on top | 12:00 |
| Saviq | yes | 12:00 |
| Saviq | and they don't | 12:00 |
| nerochiaro | Saviq: ok | 12:00 |
| Saviq | nerochiaro, http://pastebin.ubuntu.com/ | 12:00 |
| Saviq | facepalm | 12:00 |
| Saviq | nerochiaro, http://pastebin.ubuntu.com/810617/ | 12:00 |
| nerochiaro | Saviq: only one fails | 12:01 |
| nerochiaro | hmm | 12:01 |
| nerochiaro | Saviq: can you check that the function to compare window shape in the input_shaping.rb tests don't compare the sizes of the windows anymore ? | 12:01 |
| nerochiaro | Saviq: if it does, then something is messed up again and the branch is not current | 12:02 |
| nerochiaro | Saviq: but honestly to test that the tests fail if the shaping isn't there, i'd just remove the call for XShapeCombine... | 12:02 |
| nerochiaro | even though i understand why you're doing it that way | 12:03 |
| Saviq | standup | 12:03 |
| nerochiaro | sure | 12:03 |
| nerochiaro | i'm there already | 12:03 |
| Saviq | Kaleo, you comin'? | 12:03 |
| Saviq | nerochiaro, lp:~saviq/+junk/shell-shapetests | 12:14 |
| nerochiaro | Saviq: looking into it now | 12:15 |
| nerochiaro | Saviq: it looks like on my machine it actually hangs when comparing the images in one case, i'm trying to find out why | 12:27 |
| nerochiaro | Saviq: hangs as in IM compare takes 100% cpu seemingly forever | 12:28 |
| Mart_ini | hi all | 12:29 |
| Saviq | nerochiaro, isn't that why you were comparing the dimensions of the images? | 12:29 |
| Saviq | that imagick hanged when they were different? | 12:30 |
| Saviq | and also, they shouldn't ever be different, should they? | 12:30 |
| Mart_ini | I have a problem with Windows Theme.... Here is a screen shot with current look:http://imageshack.us/photo/my-images/209/zrzutekranu201201201327.png/ ... is there any posibility to change it?:/ | 12:30 |
| nerochiaro | Saviq: no, i was comparing the sizes because IM returned 0 difference when the sizes were different, and instead i should've checked the error code. but i guess it's a good thing to have both the size check and the error code check | 12:31 |
| nerochiaro | Saviq: they should be different in the case when you want the tests to fail: without shaping applied the size of the window is not fullscreen | 12:31 |
| Saviq | Mart_ini, looks like your gnome-settings-daemon crashed, did you try to log out and back in? | 12:32 |
| Mart_ini | yeah:/ | 12:32 |
| Mart_ini | and didnt help:/ | 12:32 |
| Mart_ini | even restart of whole system | 12:33 |
| Saviq | Mart_ini, you can change the theme in gnome-control-cente | 12:33 |
| Saviq | r | 12:33 |
| Mart_ini | yes I can but it didnt work | 12:33 |
| Saviq | Mart_ini, try in #ubuntu, here isn't really the place for that | 12:34 |
| Mart_ini | There I have few options like Ambiance , radiance, high contrast but even one of it changes nothing | 12:34 |
| Mart_ini | ok | 12:34 |
| Saviq | there's more people there that will be able to help | 12:34 |
| Mart_ini | no problem, thanks:) | 12:35 |
| Saviq | nerochiaro, sure, but the test should only pass if the images are the same size _and_ the input shapes are correct, right? | 12:35 |
| Saviq | nerochiaro, I removed the unlinks, the masks you generate look ok | 12:36 |
| Saviq | except | 12:37 |
| Saviq | let me just have one at a time | 12:37 |
| Saviq | ah no, ok - there's four | 12:37 |
| Saviq | launcher, launcher + dash, launcher + collapsed dash, fullscreen | 12:37 |
| nerochiaro | Saviq: to your first question, yes | 12:38 |
| nerochiaro | and yes 4 tests | 12:38 |
| Saviq | nerochiaro, they're not the same size, though | 12:38 |
| Saviq | only the fullscreen one is | 12:38 |
| Saviq | the rest are only bounding-box sized | 12:39 |
| nerochiaro | Saviq: let's mumble a moment please | 12:39 |
| Saviq | i.e. launcher is only the size of the launcher, shouldn't it be a white rectangle with a black rectangle on the left? | 12:39 |
| Saviq | sec | 12:39 |
| mhall119 | didrocks: will you have time today to talk about singlet and quickly, or early next week perhaps? | 12:46 |
| didrocks | mhall119: early next week | 12:47 |
| mhall119 | ok | 12:47 |
| mhall119 | I'll ping you Monday then? | 12:47 |
| nerochiaro | Saviq: i'm a moron,i was using verify() { somevalue } instead of verify_equal('true') { somevalue } | 13:01 |
| Saviq | or verify_true() {} ? | 13:01 |
| nerochiaro | or that | 13:01 |
| Saviq | nerochiaro, okies, good thing we caught that | 13:01 |
| Saviq | that would be a non-useful test | 13:01 |
| nerochiaro | Saviq: yeah. so i'll fix that and put back the size check | 13:02 |
| nerochiaro | Saviq: push and let you know | 13:02 |
| Saviq | nerochiaro, thanks | 13:02 |
| nerochiaro | Saviq: thanks to you | 13:02 |
| Saviq | sometimes I'm being an a$$ for a reason :] | 13:03 |
| Saviq | good | 13:03 |
| nerochiaro | Saviq: generally you aren't one | 13:03 |
| Saviq | yeah, generally | 13:03 |
| Saviq | ;) | 13:03 |
| nerochiaro | well we all have our moments of assitude ;) | 13:03 |
| nerochiaro | Saviq: pushed fixes. hopefully for the last time ;) | 13:11 |
| Saviq | nerochiaro, cool, checking now | 13:11 |
| Saviq | nerochiaro, yup, much better! | 13:16 |
| nerochiaro | Saviq: awesome | 13:17 |
| mhall119 | kamstrup: https://launchpad.net/unity-lens-sample contains some very old code, what's the plan for that project? | 13:17 |
| Saviq | nerochiaro, http://pastebin.ubuntu.com/810671/ | 13:19 |
| Saviq | launcher+dash failed | 13:19 |
| Saviq | that's with shaping | 13:19 |
| nerochiaro | wtf, everything worked here | 13:22 |
| nerochiaro | Saviq: ^ | 13:22 |
| nerochiaro | Saviq: can you post the pngs somewhere, like imgur.com ? | 13:23 |
| Saviq | nerochiaro, yup | 13:27 |
| Saviq | nerochiaro, looks like it's comparing launcher against launcher+dash | 13:27 |
| Saviq | might be it's trying to get the shape too fast | 13:27 |
| Saviq | nerochiaro, yup | 13:28 |
| nerochiaro | Saviq: sleep in the middle ? | 13:28 |
| Saviq | nerochiaro, ye | 13:28 |
| Saviq | s | 13:28 |
| nerochiaro | Saviq: are you pushing that one yourself ? | 13:28 |
| Saviq | nerochiaro, no, push | 13:28 |
| Saviq | I need to straighten up my branches here first | 13:29 |
| Saviq | don't want to push something weird | 13:29 |
| nerochiaro | Saviq: 2 secs sleep ok ? | 13:30 |
| Saviq | nerochiaro, 0.5 was fine here | 13:30 |
| Saviq | nerochiaro, but 2 is fine | 13:30 |
| nerochiaro | i'll do 1 then, if 0.5 was fine | 13:31 |
| Saviq | I wonder if we can actually use the verify()s timeout here somehow | 13:31 |
| Saviq | no idea how that works, though | 13:31 |
| nerochiaro | Saviq: better not risk for now | 13:31 |
| Saviq | but yeah that won't help either | 13:31 |
| Saviq | since what will we verify | 13:31 |
| Saviq | the image is there | 13:31 |
| Saviq | just not up to date yet | 13:31 |
| * Saviq needs to read about the verifies and stuff | 13:33 | |
| nerochiaro | Saviq: in any case it's a bit weird to do these kinds of tests because ultimately you're still bound by the speed of the machine | 13:33 |
| Saviq | nerochiaro, sure, that's why the verify_ stuff helps | 13:33 |
| Saviq | I'm not sure how it works, though - will it check every second or? | 13:33 |
| nerochiaro | Saviq: yeah, but it works only for things you do in the SUT IIRC | 13:33 |
| Saviq | ok | 13:33 |
| nerochiaro | it's syncronized somehow | 13:33 |
| nerochiaro | Saviq: pushed the sleeps for now | 13:34 |
| Saviq | that's why I said /me needs to reda about that | 13:34 |
| Saviq | nerochiaro, cool, checkinf | 13:34 |
| Saviq | -f | 13:34 |
| Saviq | +g | 13:34 |
| snadge | :D | 13:36 |
| Saviq | nerochiaro, "4 tests, 8 assertions, 0 failures, 0 errors" yay | 13:36 |
| snadge | im running precise on a few systems.. including this one which i installed from a daily build | 13:36 |
| Saviq | approving | 13:36 |
| snadge | anyway.. on this system.. i cant visually tell the difference between a focussed window and a non focussed one | 13:37 |
| snadge | they all appear to have focus even if they dont | 13:37 |
| snadge | is there a ccsm setting for that? | 13:37 |
| Saviq | nerochiaro, on a related note, did you get an answer about the actual input shape of the dash? should it incorporate the shadow or not? | 13:38 |
| Saviq | nerochiaro, as the images now very clearly show it's wrong how it is now :) | 13:38 |
| nerochiaro | Saviq: i don't think i did. and i didn't go check unity3d yet | 13:40 |
| Saviq | let me | 13:40 |
| nerochiaro | Saviq: but this is what we had in unity-2d | 13:40 |
| nerochiaro | Saviq: so please let's commit this, then fix it in another MR | 13:40 |
| Saviq | nerochiaro, already merged | 13:41 |
| Saviq | I was curious.. | 13:41 |
| Saviq | nerochiaro, aaand anyway... | 13:41 |
| Saviq | 3d behaves completely different - it takes the whole screen when dash is active | 13:41 |
| nerochiaro | Saviq: it's always fullscreen ? | 13:42 |
| Saviq | nerochiaro, when the dash is open there's no interaction with the windows below | 13:42 |
| * snadge cries | 13:42 | |
| nerochiaro | Saviq: eww | 13:43 |
| nerochiaro | Saviq: well, we're not going back | 13:43 |
| Saviq | nerochiaro, not going back, but we might need to revisit our shapes later | 13:43 |
| nerochiaro | Saviq: but how do they exit ? clicking outside of the dash area should close it | 13:43 |
| Saviq | like have a fullscreen mousearea behind the dash | 13:43 |
| Saviq | nerochiaro, yes, the lighter border already does that | 13:43 |
| nerochiaro | does what ? | 13:44 |
| Saviq | exits the dash | 13:44 |
| Saviq | clicking on the lighter border around the dash will exit it, as will clicking anywhere outside | 13:44 |
| nerochiaro | Saviq: but that border doesn't have a drop shadow ? | 13:44 |
| Saviq | nerochiaro, it does | 13:44 |
| snadge | http://askubuntu.com/questions/70071/wrong-window-focus-behaviour-in-unity-but-not-gnome-shell | 13:44 |
| Saviq | snadge, sounds compiz-related | 13:45 |
| nerochiaro | Saviq: so clicking on the shadow exits. then it's what we need to do in unity-2d too | 13:45 |
| snadge | yeah .. only one of my systems does it | 13:45 |
| Saviq | greyback, -qt's dash corner has much bigger radius than unity's does, do you know which is correct? | 13:45 |
| nerochiaro | regardless of the shaep | 13:45 |
| Saviq | nerochiaro, yeah we need a mousarea covering the whole thing | 13:45 |
| snadge | but im trying to figure out which ccsm option would be related to window focus appearance | 13:45 |
| htorque | didrocks: hi! can you please make sure the old test case in bug 913569 works for you (reveal launcher bar, click on the ubuntu/dash launcher, don't move the mouse outside of the launcher bar area, press alt+f1 → launcher bar should be saturated)? it's not working here. | 13:45 |
| Saviq | snadge, I'm not saying it's an option | 13:45 |
| htorque | no ubot? well: https://bugs.launchpad.net/unity/+bug/913569 | 13:46 |
| snadge | looks like its an fglrx problem | 13:46 |
| nerochiaro | Saviq: that's two separate issues: one is the non-interaction with the stuff below, the other is what part of the dash should trigger the dash to close | 13:46 |
| Saviq | nerochiaro, yes | 13:46 |
| nerochiaro | Saviq: i'm focusing only on the latter question | 13:46 |
| Saviq | nerochiaro, both minor issues for later | 13:46 |
| nerochiaro | Saviq: indeed | 13:46 |
| snadge | i need to enable unity switcher apparently | 13:46 |
| didrocks | htorque: oh interesting, I found another case then | 13:46 |
| Saviq | snadge, tried `unity -reset` to reset your environment? | 13:46 |
| didrocks | htorque: try right-click on bfb -> dash home | 13:46 |
| didrocks | htorque: alt + F1 | 13:46 |
| didrocks | it saturated then, isn't it? | 13:47 |
| Saviq | greyback, dyams, Kaleo, tiagosh: input shaping merged, yay :) | 13:47 |
| Saviq | nerochiaro, can you resubmit the buttons branch so that tarmac won't die? | 13:48 |
| nerochiaro | Saviq: will do shortly | 13:49 |
| snadge | hmm.. actually that bug seems to describe the fix | 13:49 |
| dyams | saviq: very nice | 13:49 |
| nerochiaro | Saviq: https://code.launchpad.net/~unity-2d-team/unity-2d/unity-2d-shell-dash-panel-buttons/+merge/89436 | 13:50 |
| Saviq | nerochiaro, thanks | 13:50 |
| Saviq | greyback, one thing I noticed - press super, alt+f1 - dash goes away | 13:53 |
| Saviq | bug? feature? | 13:54 |
| dyams | saviq: Atleast I can say its not reported as bug so far :) | 13:55 |
| Saviq | dyams, checking with unity | 13:55 |
| dyams | saviq: Ok | 13:55 |
| Saviq | dyams, unity does not do that | 13:58 |
| Saviq | dyams, I say we fix along with the shell work | 13:59 |
| dyams | dyams: Ok, sure | 13:59 |
| dyams | saviq:^^ | 14:00 |
| Saviq | dyams, trying to talk to someone smart here? ;) | 14:01 |
| dyams | saviq: ;) | 14:01 |
| Saviq | dyams, do you confirm that bug, though? | 14:02 |
| greyback | Saviq: dyams: nice find, but I'd like to check with design what is the right thing to do. | 14:03 |
| Saviq | greyback, sure, another thing is keyboard nav between the dash and the launcher | 14:04 |
| * dyams greyback is right | 14:04 | |
| * greyback only learns now that nick changes have to be done for each server | 14:04 | |
| Saviq | greyback, ? | 14:04 |
| greyback | Saviq: example? | 14:05 |
| Saviq | greyback, go left from search entry | 14:05 |
| snadge | ok unity --reset doesnt help.. deleting my .compiz .config and .gnome2 dirs didnt help | 14:05 |
| greyback | Saviq: maybe it's xchat | 14:05 |
| Saviq | greyback, I don't think it is, you can have different nicks per server | 14:05 |
| Kaleo | Saviq: rock | 14:05 |
| Saviq | ...and a hard place | 14:06 |
| greyback | paper scissors | 14:06 |
| greyback | lizard spock? | 14:06 |
| Saviq | greyback, you can't have two | 14:06 |
| Saviq | paper _or_ scissors | 14:06 |
| Saviq | but hey, you lost with yourself :D | 14:06 |
| greyback | Saviq: hmm, again I'd like to check. If you're editing text in that box, going left too many times to focus BFB might be confusing too | 14:06 |
| greyback | or won :P | 14:07 |
| Saviq | greyback, depends how you look on it ;) | 14:07 |
| greyback | Saviq: yep, hence asking design ;) | 14:07 |
| Saviq | greyback, that was re paper scissors | 14:07 |
| Saviq | greyback, but sure, for tv we have going left from dash content | 14:07 |
| greyback | that's my answer to everything :) | 14:08 |
| Saviq | lol | 14:08 |
| Saviq | a good one, too | 14:08 |
| greyback | Saviq: yeah that consistency would be nice alright | 14:08 |
| Saviq | greyback, except I hate it that I can't go left from search entry to launcher ;) | 14:08 |
| Saviq | so yes, that needs design | 14:08 |
| Saviq | JohnLea, we need you here :D | 14:08 |
| JohnLea | Saviq; where are you? | 14:09 |
| Saviq | here | 14:09 |
| JohnLea | ;-) | 14:09 |
| Saviq | JohnLea, like, on IRC ;) | 14:09 |
| Saviq | JohnLea, two things: open dash, press alt+f1 | 14:09 |
| Saviq | right now the launcher gets focus | 14:09 |
| Saviq | but the dash disappears | 14:09 |
| Saviq | (in unity other weird things happen, but dash does not disappear) | 14:09 |
| Saviq | (that's just the first thing) | 14:10 |
| Saviq | I have a bug ready that I can affect to ayatana-design, if you'd like | 14:10 |
| JohnLea | bug #? | 14:10 |
| Saviq | none, right now | 14:10 |
| Saviq | 'cause we weren't sure it's a bug | 14:10 |
| Saviq | I can file and affect you guys | 14:10 |
| JohnLea | yup, ping me the bug number when you have filed it | 14:11 |
| JohnLea | thx | 14:11 |
| Saviq | JohnLea, bug #919209 | 14:11 |
| Saviq | I said I have it ready | 14:11 |
| greyback | Saviq: ooh you're kidding! https://bugs.launchpad.net/ayatana-design/+bug/919211 | 14:13 |
| greyback | Saviq: grrr, you & your efficiency | 14:13 |
| Saviq | greyback, no that's fine | 14:13 |
| Saviq | I only filed the dash, alt+f1 one | 14:13 |
| greyback | Saviq: yep just saw that, pfew | 14:14 |
| Saviq | greyback, we need one the other way around, too | 14:14 |
| greyback | Saviq: yep | 14:14 |
| Saviq | except that going right from the launcher gives you the menu | 14:14 |
| greyback | which is pointless | 14:14 |
| Saviq | so it might be that we shouldn't have any keynav between launcher and dash | 14:14 |
| Saviq | to have it consistent | 14:14 |
| Saviq | just use super / alt+f1 to be sure where you'll end up | 14:15 |
| greyback | Saviq: yep, hence asking design ;) | 14:15 |
| Saviq | yeyp | 14:15 |
| JohnLea | Saviq; the dash should hide, current behaviour in Unity2d is correct (but this needs fixing in unity3d) | 14:16 |
| snadge | gah... all my windows look like they have focus | 14:17 |
| Saviq | JohnLea, ok, so that kind of solves part of #919211 | 14:17 |
| greyback | JohnLea: woo :) | 14:17 |
| Saviq | greyback, I'll cook up a test for that :) | 14:17 |
| snadge | probably an fglrx issue.. sigh | 14:17 |
| Saviq | snadge, try with radeon | 14:18 |
| Saviq | if you can, that is | 14:18 |
| JohnLea | Saviq, greyback; take a look at bug #919209 now ;-) | 14:19 |
| Saviq | take that! | 14:19 |
| Saviq | mwahahahaha | 14:19 |
| snadge | ok | 14:19 |
| htorque | didrocks: yeah, but again: not when the mouse doesn't leave the launcher bar area | 14:21 |
| Saviq | greyback, we do have a bug there, though - go super, alt+f1, then try to dismiss the launcher | 14:22 |
| didrocks | htorque: yeah, I misread that part, I edited it, sorry :) | 14:22 |
| htorque | didrocks: thanks, and no problem! :-) | 14:22 |
| greyback | Saviq: Alt+F1 again, or Escape. You want to click away? | 14:23 |
| Saviq | greyback, mine doesn't hide | 14:23 |
| greyback | Saviq: hmm, you running shell? | 14:23 |
| Saviq | I have to alt+tab / click away to get out of the launcher | 14:23 |
| Saviq | greyback, nope, oneiric | 14:23 |
| Saviq | wrong | 14:23 |
| Saviq | staging | 14:23 |
| Saviq | greyback, it works if I just go alt+f1, alt+f1 or alt+f1, esc | 14:24 |
| Saviq | but not if I go super, alt+f1, [esc,alt+f1] | 14:24 |
| greyback | Saviq: yep, confirmed. I can click away though | 14:24 |
| greyback | Saviq: logging bug | 14:25 |
| Saviq | greyback, do you think that belongs to launcher or dash tests? | 14:25 |
| dyams | greyback: while testing { Super+Num_Key }, I assume that application launched successfully if the tile has atleast one pip | 14:25 |
| JohnLea | Saviq, grayback; also see bug https://bugs.launchpad.net/ayatana-design/+bug/869122 | 14:26 |
| snadge | ok getting somewhere now.. fglrx has the window focus bug.. but radeon does not | 14:26 |
| dyams | greyback: i.e to check the application is running status | 14:26 |
| greyback | Saviq: yep I know the cause. A bad bit of code from me :( | 14:26 |
| greyback | Saviq: launcher I'd say. Other apps can cause it | 14:27 |
| Saviq | greyback, oks | 14:27 |
| Saviq | JohnLea, apart from point 3. looks fixed in unity-qt | 14:29 |
| Saviq | (see how I've sneaked the non-2d name there? ;>) | 14:29 |
| greyback | Saviq: oO | 14:29 |
| smspillaz | njpatel: comments on https://code.launchpad.net/~vanvugt/unity/fix-742544-alt-trunk/+merge/86779 | 14:34 |
| smspillaz | snadge: dri drivers do not have the no-damage-events-on-non-window-pixmaps bug anymore | 14:34 |
| snadge | dammit.. its an fglrx problem | 14:34 |
| njpatel | smspillaz, jasons' work will fix this | 14:34 |
| snadge | smspillaz: Im using the latest drivers from amd :| | 14:35 |
| njpatel | we can't just revert without having a proper fix | 14:35 |
| smspillaz | njpatel: for 4.0 ? | 14:35 |
| smspillaz | njpatel: ok, can you leave comment then ? | 14:35 |
| njpatel | not for 4.0, we don't need this in 4.0 | 14:35 |
| smspillaz | the fix seems to make sense, always picking the "primary" monitor. unless I missed something | 14:35 |
| snadge | fglrx_8.920 aka catalyst 11.12 | 14:36 |
| snadge | installed with --buildpkg Unity/precise | 14:36 |
| Saviq | greyback, so I'm thinking separate tests - one that verifies that the launcher behaves correctly when the dash is open (not caring about what the dash does) | 14:36 |
| Saviq | and the other just for the dash | 14:36 |
| Saviq | (two for the first case) | 14:37 |
| greyback | Saviq: yeah that's more comprehensive | 14:37 |
| Saviq | - one for alt+f1, one for esc to dismiss | 14:37 |
| snadge | smspillaz: i cant find any references to that bug on google | 14:38 |
| njpatel | smspillaz, you can't open the launcher when it's hidden on 4.0 if it's not on the left screen easily | 14:38 |
| njpatel | that's why it picks 0 (it used to always pick primary) | 14:38 |
| njpatel | jason's multimonitor work fixes that | 14:38 |
| Saviq | greyback, hmm we actually don't have a test to just check whether launcher shows after dash has been invoked | 14:39 |
| Saviq | I'll have one for that, too | 14:39 |
| greyback | Saviq: not yet, lots of things to test :( | 14:39 |
| Saviq | greyback, yup | 14:39 |
| mhall119 | does http://blogs.gnome.org/carlosg/2012/01/20/multitouch-is-near/ use any uTouch technology? | 14:40 |
| greyback | Saviq: shell in a usable condition now? | 14:40 |
| Saviq | greyback, yup | 14:40 |
| Saviq | cnd, ^ | 14:40 |
| greyback | Saviq: ok, I'll focus more on that for tests in future | 14:40 |
| Saviq | greyback, I'll do the four I mentioned | 14:40 |
| smspillaz | njpatel: ok, can you comment on the merge then ? | 14:41 |
| Saviq | mhall119, cnd will be best to answer that, but he's hard asleep now, I'm afraid | 14:43 |
| mhall119 | when he wakes up, will it be Friday or Saturday? | 14:44 |
| Saviq | Friday | 14:44 |
| Saviq | mhall119, but from what I can see there won't be any utouch happening behind that | 14:47 |
| Saviq | mhall119, all the work that's gone into X re multitouch while utouch was in the works will, of course | 14:47 |
| mhall119 | ok, so some of the work that Canonical did for uTouch is helping enable GTK+ touch | 14:48 |
| mhall119 | that was really my question | 14:48 |
| njpatel | smspillaz, i did | 14:53 |
| smspillaz | njpatel: yep, saw, thanks | 14:58 |
| smspillaz | just so it didn't look dodge when I abstain for no reason XD | 14:59 |
| smspillaz | mhall119: cnd works upstream with XInput2 - some of XInput2 is used for the Gtk+ touch stack. you'll have to ask him on the specifics | 15:00 |
| Saviq | greyback, do we want any tests that we know will fail in trunk submitted there? | 15:08 |
| Saviq | greyback, the actual question is whether we want _any_ tests that fail in the suite? or do we keep them somewhere in a branch and only merge with the fix? | 15:08 |
| Saviq | 'cause I can easily imagine (and not only imagine) people writing tests not being those that actually fix the issues | 15:09 |
| greyback | Saviq: can add tests that are skipped by defining them as "xtest something" instead of "test something" | 15:18 |
| greyback | so they can be enabled later | 15:18 |
| Saviq | greyback, oh cool | 15:18 |
| Saviq | greyback, is there a way to actually run them, too? | 15:18 |
| nerochiaro | greyback: Saviq: any idea on how to test that the dash will go fullscreen when the resolution changes to resolution that's too small ? | 15:18 |
| Saviq | nerochiaro, you could test the dash mode and its height / width? | 15:19 |
| greyback | Saviq: no unfortunately, it's just a little bit of syntactic sugar | 15:19 |
| Saviq | greyback, ok nvm | 15:19 |
| nerochiaro | Saviq: yes but how do i change the resolution in the test ? | 15:19 |
| Saviq | nerochiaro, xrandr? | 15:19 |
| nerochiaro | Saviq: to what resolution ? each system is different in what it does allow ;) | 15:20 |
| nerochiaro | Saviq: and actually on my machine for some reason just right now xrandr isn't working | 15:20 |
| nerochiaro | also, do we want to fuck around with resolution on people's machiens ? | 15:20 |
| Saviq | nerochiaro, as greyback mentioned earlier - skip the test with a warning | 15:20 |
| Saviq | nerochiaro, we can have them separate | 15:20 |
| Saviq | greyback, what do you think? | 15:20 |
| greyback | I think fucking about with people's resolution is dodgy | 15:21 |
| nerochiaro | my suggestion here is to test at whatever resolution we are right now and check the dash in the correct shape | 15:21 |
| greyback | Best detect in the test what resolution they have, and just return if it's not suitable | 15:21 |
| greyback | nerochiaro: yeah, I think that's ok | 15:21 |
| nerochiaro | greyback: or test that we do the right thing at that resolution, knowing that maybe at another resolution we will fail | 15:22 |
| Saviq | nerochiaro, btw, it doesn't, not in my VBOX at least | 15:22 |
| nerochiaro | Saviq: doesn't what ? | 15:22 |
| Saviq | nerochiaro, doesn't adapt | 15:22 |
| nerochiaro | Saviq: no it doesn't, i'm working on it now :) | 15:23 |
| greyback | nerochiaro: exactly. I don't see how to change resolution safely | 15:23 |
| Saviq | at 640x480 the launcher is resized, but the dash doesn't change modes | 15:23 |
| Saviq | nerochiaro, ok | 15:23 |
| Saviq | greyback, nerochiaro: maybe we could have an env var | 15:23 |
| Saviq | that says "RUN_DISRUPTIVE_TESTS" | 15:23 |
| nerochiaro | greyback: it would be great to be able to run the tests in an instrumented environment where ScreenInfo returns whatever we want it to return | 15:23 |
| nerochiaro | Saviq: ^ | 15:23 |
| Saviq | nerochiaro, that might make sense | 15:24 |
| nerochiaro | so we would be able to fake changes in the resolution | 15:24 |
| Saviq | nerochiaro, can't we hack ScreenInfo already? | 15:24 |
| Saviq | nerochiaro, from testability | 15:24 |
| Saviq | nerochiaro, just write to the properties | 15:24 |
| nerochiaro | Saviq: hmm, it's a singleton class, not part of the object tree | 15:24 |
| nerochiaro | doubt it can reach it | 15:24 |
| Saviq | nerochiaro, oh :/ | 15:24 |
| nerochiaro | Saviq: but aren't we running unity-2d-shell with -testability ? | 15:25 |
| Saviq | nerochiaro, yes, we are | 15:25 |
| nerochiaro | we can check that and use the fake ScreenInfo in that case | 15:25 |
| Saviq | yup, we probably coudl | 15:25 |
| Saviq | *could | 15:26 |
| nerochiaro | but i'm not sure it's a great idea from another standpoint because it's just adding an extra code path _in_ the app under test | 15:26 |
| * nerochiaro got an idea | 15:26 | |
| * greyback pondering how evil Xephyr would be for this | 15:27 | |
| Saviq | greyback, too evil | 15:27 |
| nerochiaro | why ? | 15:27 |
| Saviq | unless we decide to run everything under xephyr, that i | 15:28 |
| Saviq | s | 15:28 |
| greyback | Saviq: just for resolution tests, why so evil | 15:28 |
| greyback | ? | 15:28 |
| Saviq | dunno, I kind of hate xephyr for some reasony | 15:28 |
| Saviq | -y | 15:28 |
| Saviq | might have had issues with it before or something | 15:28 |
| Saviq | nigthmares maybe | 15:28 |
| Saviq | and simply unsure if we really need that | 15:29 |
| nerochiaro | Saviq: i guess it's the same feeling i have for vbox ;) | 15:29 |
| Saviq | nerochiaro, true, true | 15:29 |
| greyback | I think it's an option, but not a great one. It means installing more crap on the machine under test | 15:29 |
| nerochiaro | surely running the tests under xephyr will be closer to the real system than vbox | 15:29 |
| Saviq | nerochiaro, how so? | 15:30 |
| Saviq | nerochiaro, as far as the system knows, vbox is just different hardware | 15:31 |
| Saviq | as far as an application knows, xephyr is just a different X server/client/whatever | 15:31 |
| Saviq | so the difference is just at a different level | 15:31 |
| Saviq | can't we just skip the tests that are disruptive unless there's an env var set? | 15:32 |
| Saviq | and those that we can't run (like when Ugo's xrandr is broken) | 15:32 |
| nerochiaro | Saviq: sure, if you know xrandr is broken ;) | 15:33 |
| greyback | Saviq: yep, do-able | 15:33 |
| Saviq | nerochiaro, how does your broken xrandr show it's broken? | 15:33 |
| nerochiaro | Saviq: in general i agree, in this particular case i dunno even if xrandr works, how do we know which resolution to change to ? | 15:33 |
| Saviq | it probably doesn't display the res or something? | 15:33 |
| nerochiaro | Saviq: it just say it faield to change the res | 15:33 |
| nerochiaro | might be i'm using nvidia drivers or something | 15:33 |
| Saviq | nerochiaro, I'm on nvidia too | 15:34 |
| Saviq | nerochiaro, just run xrandr, find one that fits, change | 15:34 |
| Saviq | change back | 15:34 |
| Saviq | +test in between | 15:34 |
| greyback | nerochiaro: this is the reason why VBox is good idea IMO. If something core is broken on your machine, then test will fail because of it . At least in a VBox instance, it should be a clean install & everything working | 15:34 |
| nerochiaro | Saviq: "find one that fits" ? | 15:34 |
| Saviq | nerochiaro, it will list you available resolutions | 15:34 |
| Saviq | just find one that's low enough that the change will happen | 15:34 |
| Saviq | if any of that fails, the test failed, but will tell you why | 15:35 |
| Saviq | it | 15:35 |
| Saviq | shit will happen, yes - tests will sometimes fail due to <input_your_favourite_reason_here> | 15:35 |
| nerochiaro | greyback: Saviq: what i'm really thinking is that we should take a step back and define who are the tests meant for. if they are meant for any random user to run,it's one thing, if they are meant to be run on jenkins for verification before release,it's another | 15:35 |
| Saviq | nerochiaro, they're primarily based for automated testing | 15:35 |
| Saviq | but if we can make them work for user x then cool | 15:36 |
| Saviq | greyback, unless I'm mistaken with that? | 15:36 |
| greyback | that's my priority list, yeah | 15:36 |
| greyback | nerochiaro: I do want test to run on your machine, without VBox. But there's only so much time I can spend thinking of every possiblt thing your machine might have different to work around | 15:37 |
| nerochiaro | greyback: i agree. i'm not necessarily against vbox or xephyr | 15:37 |
| nerochiaro | bbiab | 15:37 |
| greyback | nerochiaro: in fact, I prefer when they can run inside some virtualised thing, so I can do other stuff as they run | 15:38 |
| greyback | VBox has a headless mode too, which I want to play with in future | 15:38 |
| Saviq | greyback, yeah I do the same, they just run away, I'm doing other things, when I get back I have a result ready | 15:38 |
| greyback | Saviq: yep, perfect, that's what I'm trying to get going | 15:39 |
| greyback | Amazing all the little things that can get in the way | 15:39 |
| Saviq | yup | 15:40 |
| greyback | Saviq: nerochiaro: But I have to say, this week with you all using Testability, your comments about problems, stuff that's missing, etc, have been bloody useful | 15:40 |
| greyback | Great to get proper feeedback | 15:40 |
| greyback | feeeedback | 15:40 |
| Saviq | greyback, for me it's awesome to see that we can actually test stuff | 15:41 |
| Saviq | before your Testability talk I was scared as hell | 15:41 |
| Saviq | easy peasy now | 15:41 |
| greyback | Saviq: it is nice, with a few painful exceptions. XDotool stuff needs a lotta loving (in progress) | 15:42 |
| Saviq | sure, but we can already do a lot | 15:42 |
| greyback | and we're really pushing what the tool can do. It wasn't meant for testing a desktop environment | 15:42 |
| greyback | Yep, I'm pretty pleased with it | 15:42 |
| Saviq | I love it how we can hack a test up, make it fail (well, error at this point :P) and the fix it, pass the test | 15:42 |
| Saviq | done! | 15:42 |
| Saviq | no f*cking about | 15:42 |
| greyback | Yep. It's a good way to work | 15:43 |
| Saviq | that's what Ugo failed to do with the shaping work - he built tests on top of a working feature | 15:46 |
| Saviq | it was difficult to actually see whether the tests fail when the feature was broken (or not there) | 15:46 |
| Saviq | greyback, you sir need to settle on a nick, too :P | 15:48 |
| greyback | Saviq: eh? | 15:48 |
| Saviq | you're greyback here, gerboland on LP | 15:48 |
| Saviq | greyback, you got a MR waiting, sorry | 15:48 |
| greyback | Yeah, always meaning to get that changed | 15:48 |
| greyback | Saviq: np, looking | 15:49 |
| Saviq | greyback, we (by we I mean you with a little help from your friends) need to define a process for working with tests | 15:50 |
| Saviq | like whether we want separate branches for tests | 15:50 |
| didrocks | Saviq: bug #919209 is a duplicate | 15:50 |
| Saviq | submitted with xtest to disable them initially | 15:50 |
| Saviq | didrocks, couldn't find one, sorry | 15:51 |
| didrocks | bug #885304 | 15:52 |
| greyback | Saviq: I see. My concern is someone writing a disabled test will then forget to do the fix and enable the test. | 15:52 |
| greyback | So I want fix+test | 15:52 |
| Saviq | greyback, well, the bug will be open all the time | 15:52 |
| Saviq | so as long as someone is assigned to the bug... | 15:53 |
| Saviq | greyback, fix+test has the added issue of not being able to test the test | 15:53 |
| Saviq | or making it difficukt | 15:53 |
| Saviq | s/k/l/ | 15:53 |
| greyback | Saviq: sure | 15:53 |
| Saviq | exactly our issue with Ugo today | 15:53 |
| greyback | Yeah, that I saw | 15:53 |
| Saviq | I spent several hours to verify that the tests actually fail without the fix | 15:53 |
| Saviq | that should be easy as pie | 15:54 |
| greyback | True | 15:54 |
| Saviq | I'm not requiring for people to go TDD | 15:54 |
| Saviq | but a separate test / fix branch might be useful | 15:55 |
| Saviq | and easy to work with, really | 15:55 |
| Saviq | since they're separate enough, merging the tests into your fix branch to test would be very easy | 15:56 |
| Saviq | problems arise when you need to fix your tests | 15:56 |
| Saviq | but they're even bigger when you only have one branch where the history gets intertwined | 15:56 |
| greyback | Let me recap. You have a bug to fix. You first write a test for the fix in one branch | 15:57 |
| greyback | In second branch you do the fix. | 15:57 |
| greyback | You try to have both merged into trunk simultaneously | 15:57 |
| greyback | Test-only branch will cause Jenkins to lockout, unless test is disabled. | 15:59 |
| Saviq | that's TDD, I'm not set on whether you should write the test first or the fix | 15:59 |
| greyback | Yeah, I'm pondering out loud ;) | 15:59 |
| Saviq | that's irrelevant, really | 15:59 |
| Saviq | but there are two approaches here | 16:00 |
| Saviq | 1) you merge xtests and not tests | 16:00 |
| Saviq | then you merge the fix, actually enabling the tests | 16:00 |
| nerochiaro | Saviq: greyback: re | 16:00 |
| Saviq | 2) merge the fix and the test before merging into trunk | 16:01 |
| Saviq | 2) has issues with MRs | 16:01 |
| Saviq | 1) does not | 16:01 |
| greyback | Yeah option 1 is what I'm thinking is good | 16:01 |
| Saviq | two separate MRs - one for the test, the other for the fix - only thing we need to remember is that the test one needs to be merged first | 16:02 |
| nerochiaro | at this point i'm actually starting to think that TDD might be a better option (not mandatory, just saying for me for some cases) | 16:02 |
| Saviq | nerochiaro, !!!!! | 16:02 |
| Saviq | D: | 16:02 |
| Saviq | :D | 16:02 |
| Saviq | ;) | 16:02 |
| greyback | Saviq: yep | 16:02 |
| greyback | nerochiaro: omg! | 16:02 |
| greyback | :) | 16:02 |
| nerochiaro | yeah, shocking i know | 16:02 |
| Saviq | I think he's been bitten by me being an a$$ today | 16:03 |
| Saviq | and even more by me being an a$$ rightly so | 16:03 |
| nerochiaro | by you being very rigorous, sir. that's differnet | 16:03 |
| greyback | nerochiaro: you have opinion on what we're discussing above. A test-driven workflow process | 16:03 |
| greyback | ? | 16:03 |
| mhr3 | gord, question about the views that displays stuff from lenses | 16:03 |
| mhr3 | gord, it seems like they just append the results, no matter the position in the model | 16:03 |
| mhr3 | gord, do they support inserting at proper position? | 16:04 |
| greyback | Saviq: nerochiaro whatever you two get up to in private has no business on this channel ;) | 16:04 |
| mhr3 | gord, like i have 5 results in the view already and then i want to insert something at pos 0 | 16:04 |
| nerochiaro | greyback: i'm not much in favor of a tests branch and a feature branch, MR'd separately. adds lots of overhead imho | 16:04 |
| Saviq | greyback, right, we should take that to #unity-qt | 16:04 |
| Saviq | nerochiaro, yes, the overhead is definitely an issue | 16:05 |
| Saviq | nerochiaro, but how else do you think we can make sure it's easy to verify the test itself? | 16:06 |
| nerochiaro | i've gotta think about it a bit | 16:06 |
| greyback | Saviq: LP can have one branch depend on another. Might help prevent fix being merged before test | 16:07 |
| gord | mhr3, are you talking about per category views? | 16:07 |
| Saviq | greyback, yeah, but tarmac pukes with that | 16:07 |
| greyback | Saviq: ahh, I didn't know | 16:07 |
| nerochiaro | if bzr made it easier to reorder the history i would suggest that when you commit you move them as the first commit of your MR | 16:07 |
| mhr3 | gord, yea | 16:07 |
| Saviq | sure, if we were using git I would just rebase my fix on the test | 16:07 |
| Saviq | but we're not :P | 16:08 |
| nerochiaro | yeah, a man can dream right ;) | 16:08 |
| mhr3 | gord, oh right the model is then split to categories... so no straight mapping from the model positions... | 16:08 |
| gord | mhr3, yeah, we go in order iirc, but the only signals the views get are row_added/row_removed so any changes are appended/removed | 16:09 |
| nerochiaro | Saviq: if the commits about the tests are not mixed with the commits about the feature one can just revert the block of commits about the feature when reviewing,no ? | 16:09 |
| nerochiaro | Saviq: what you did in my case | 16:10 |
| mhr3 | gord, ok then, i'll pre-sort it in the lens, that will surely be easier... | 16:10 |
| nerochiaro | Saviq: so maybe we can either do the 2 branches thing or the grouping thing, and each dev choose which one they prefer | 16:10 |
| Saviq | nerochiaro, meeting, will get back to you | 16:12 |
| greyback | nerochiaro: sorry, grouping thing? You mean merge test into fix before MR? | 16:12 |
| nerochiaro | greyback: i mean that all commits that are not tests should not be mixed with the commits (or hopefully, single commit) that are tests | 16:13 |
| davidcalle | mhr3, wouldn't that hurt lenses with scopes with different latencies? As the result would have to wait for the slowest scope to pass results before being displayed? | 16:13 |
| nerochiaro | greyback: so one can do "bzr merge -r X..Y ." where X and Y are the non-test commits, to revert the feature but keep the tests | 16:13 |
| nerochiaro | greyback: i think it works well for small bugfixes | 16:14 |
| nerochiaro | greyback: larger bugfixes might want the split branches | 16:14 |
| greyback | nerochiaro: true. I think it's valuable to keep them separate | 16:14 |
| greyback | nerochiaro: just trying to figure out best way so there's not too much overhead | 16:14 |
| nerochiaro | greyback: yeah, and i think the overhead of splitting is ok with a large branch (like -shaped) but not ok with a small fix | 16:15 |
| greyback | say if a fix is bad, but the test is good, having them separate in trunk is great | 16:15 |
| nerochiaro | greyback: so for the small fix we can just have one single branch with feature commits and test commits cleanly separated | 16:15 |
| mhr3 | davidcalle, well, yes, in some way | 16:16 |
| nerochiaro | greyback: well, if the commits are not mixed, it's easy to merge just a part of them,as if they were from 2 separate branches | 16:16 |
| greyback | nerochiaro: I dunno, then we've got 2 policies which adds confusion | 16:16 |
| greyback | nerochiaro: sure | 16:16 |
| nerochiaro | greyback: right. i just feel neither works well for all commits | 16:16 |
| nerochiaro | greyback: for all MRs, sorry | 16:16 |
| mhr3 | davidcalle, i'll be actually sorting the results within one scope, so no big deal | 16:17 |
| greyback | nerochiaro: Yeah, I'm torn myself. I'd rather not the pain for every little bugfix | 16:17 |
| greyback | nerochiaro: but I don't like there being 2 policies either | 16:17 |
| mhr3 | davidcalle, but now that i think about it, the merge strategy might actually not work at all | 16:17 |
| nerochiaro | greyback: frankly i wouldn't want to make any of these policies mandatory either | 16:18 |
| mhr3 | and kamstrup's gone already :/ | 16:18 |
| davidcalle | mhr3, why? | 16:18 |
| greyback | nerochiaro: it wouldn't be a policy if it's not enforced :) | 16:18 |
| greyback | nerochiaro: guidelines are a nicer term | 16:19 |
| mhr3 | davidcalle, cause you are sorting the model, but the dash won't care about the order of the model | 16:19 |
| nerochiaro | greyback: right | 16:19 |
| mhr3 | it's appending latest results at the end | 16:19 |
| davidcalle | mhr3, indeed... | 16:19 |
| davidcalle | mhr3, can the Dash be changed in time for Precise? | 16:21 |
| mhr3 | that's a topic for next week's discussions :) | 16:21 |
| mhr3 | i suppose 2d has the same issue? | 16:22 |
| mhr3 | greyback, ^^? | 16:22 |
| didrocks | greyback: bug #919226 is another duplicate you just opened of bug #919209 ? (which I signaled as a duplicate of bug #885304 ? | 16:22 |
| greyback | mhr3: yes I believe so | 16:23 |
| greyback | didrocks: 919226 != 919209 - it's a different bug | 16:25 |
| didrocks | urgh, yeah | 16:26 |
| didrocks | 919226 is the duplicate of bug #885304 | 16:26 |
| didrocks | not 919209 | 16:27 |
| didrocks | isn't it? | 16:27 |
| greyback | didrocks: in the code, it's actually a different issue | 16:27 |
| mhr3 | greyback, one can totally tell that you studied maths ;) | 16:27 |
| mhr3 | (919226 != 919209) | 16:27 |
| greyback | mhr3: 8 years of university baby! | 16:28 |
| didrocks | greyback: can you please dup 919226 to 885304? | 16:28 |
| didrocks | greyback: I'll undup 919209 and say "sorry" to Saviq :) | 16:28 |
| didrocks | or are those you mean, "it's different bugs?" | 16:29 |
| greyback | didrocks: yep, 919226 != 885304 | 16:29 |
| greyback | didrocks: it's a problem determining which window to give focus back to | 16:29 |
| didrocks | hum, weird ;) | 16:29 |
| didrocks | ah ok | 16:29 |
| Saviq | guys, straighten your maths up and let me know ;) | 16:29 |
| mhr3 | greyback, i'm just waiting while you get to a dupe and type 9098 == 9172 | 16:30 |
| greyback | didrocks: tho there should be a different bug it is a dup of, am searching | 16:30 |
| didrocks | anyway 919209 is a different one as well, undupping | 16:30 |
| greyback | mhr3: I... just ... can't gaah | 16:30 |
| Saviq | nerochiaro, problem with "grouping" is that after review you will fix the test, then you will fix the feature... and then you're not grouped anymore | 16:31 |
| mhr3 | greyback, so it'll be "~=" ? | 16:31 |
| nerochiaro | greyback: do you mind if i rename tests/places to tests/dash ? we can finally get rid of that old name now | 16:31 |
| Saviq | that's never gonna work | 16:31 |
| nerochiaro | Saviq: ah, good point. keep thinking in terms of git | 16:31 |
| nerochiaro | Saviq: feh | 16:31 |
| greyback | nerochiaro: please do! | 16:31 |
| greyback | awww | 16:31 |
| nerochiaro | Saviq: but i really hate forcing separate branches even for small bugfixes | 16:32 |
| nerochiaro | grrr | 16:32 |
| nerochiaro | and bzr support for in-place branches ain't that great either so i have to keep them in two dirs, and rebuild all two times | 16:33 |
| nerochiaro | bleh | 16:33 |
| Saviq | nerochiaro, well, colo-branches work ~fine for me | 16:33 |
| nerochiaro | it's the ~ that bites me at the wrong moments | 16:34 |
| Saviq | unless I move the whole repo around, when it dies completely <headdesk> | 16:34 |
| nerochiaro | or rather, bit me | 16:34 |
| Saviq | well, ok, the only real issue I've had is moving the repo around | 16:34 |
| Saviq | it's got absolute paths saved in there | 16:34 |
| greyback | Saviq: I am thinking for a bug fix, the overhead of 2 branches is too much. As long as test and fix are separate commits, it should be ok | 16:34 |
| Saviq | which is :O | 16:34 |
| nerochiaro | i dunno, it might have been me being stupid, but sometimes switching between branches confused it immensely | 16:35 |
| greyback | Saviq: problem is defining "just a bugfix" :) | 16:35 |
| nerochiaro | i'll give it another go i guess | 16:35 |
| nerochiaro | or just suck up the overhead | 16:35 |
| Saviq | greyback, ok so maybe the guideline would be: every MR needs to have a clear way to get rid of the fix to be able to test the test | 16:35 |
| Saviq | how you achieve that is the dev's responsibility | 16:36 |
| greyback | Saviq: yeah, that's my thinking | 16:36 |
| Saviq | nerochiaro, yeah I can't understand why once `bzr switch trunk` works and once it does not | 16:36 |
| Saviq | and then list out the recommended approaches | 16:36 |
| greyback | If you write something that needs more than 1-2 tests, then the tests should be separate | 16:37 |
| Saviq | `bzr rebase` might be your friend there, too | 16:37 |
| Saviq | aanyway, EOD for me guys | 16:38 |
| Saviq | we'll talk on monday, have a great weekend | 16:38 |
| greyback | Saviq: thanks for good discussion | 16:38 |
| greyback | Have a good one! | 16:38 |
| nerochiaro | have a good weekend | 16:39 |
| nerochiaro | Saviq: one last thing, if you have a sec | 16:39 |
| Saviq | nerochiaro, yup | 16:39 |
| nerochiaro | do you know if when i overwrite a branch with --overwrite and you want to pick up what i did, but preserve the build in your local tree, how to do that ? | 16:40 |
| nerochiaro | say you branched earlier, then i overwrote the branch, then you want to pick up my overwritten branch | 16:40 |
| nerochiaro | but in the same dir as the previous branch | 16:41 |
| Saviq | nerochiaro, `bzr pull --overwrite` should do, no? | 16:43 |
| nerochiaro | Saviq: i didn't know it existed :) | 16:43 |
| Saviq | :) | 16:43 |
| nerochiaro | Saviq: because with push --overwrite is permissible, then we can relatively easily reorder the history git-style with bzr uncommit and a few helper scripts | 16:44 |
| nerochiaro | s/with/if | 16:44 |
| nerochiaro | and ask the reviewer to pull --overwrite again | 16:45 |
| Saviq | nerochiaro, yeah sure, but I'm too afraid to do that in bzr | 16:45 |
| nerochiaro | Saviq: i've been using uncommit a bunch and it's really sae | 16:45 |
| nerochiaro | safe | 16:45 |
| nerochiaro | but YMMV | 16:45 |
| Saviq | we basically need a `bzr rebase -i` | 16:45 |
| nerochiaro | Saviq: ok i'll think about it | 16:47 |
| nerochiaro | Saviq: have a good weekend | 16:47 |
| Saviq | cheers | 16:47 |
| nerochiaro | greyback: that's funny, i'm fixing something where the test is actually longer than the fix | 16:53 |
| nerochiaro | greyback: also the test depends on something that's in gsettings, do i hardcode these values in the test file or read them from gsettings | 16:56 |
| nerochiaro | ? | 16:56 |
| greyback | nerochiaro: oops sorry, reading | 17:13 |
| nerochiaro | greyback: np | 17:13 |
| greyback | yeah I can see lots of tests longer than the fixes ;) | 17:13 |
| greyback | Especially with my demand for a nice long comment at the top | 17:13 |
| greyback | Oh gsettings grr, another thingy on my list to figure out a proper test system for dconf stuff | 17:14 |
| greyback | nerochiaro: reading from gsettings risky? | 17:15 |
| nerochiaro | greyback: didn't say risky, just wondering what i should do. in the end the test will mostly mirror the fix, since we can't change the resolution on the user's machien | 17:16 |
| nerochiaro | greyback: i mean, i will read the min resolution, check what the user has, and test what the dash does. the dash will read the min resolution, check what the user has, and do something. i mean, it's pretty much the same ;9 | 17:18 |
| nerochiaro | ;) | 17:18 |
| greyback | nerochiaro: lol ok so. Go for gsettings then | 17:28 |
| burli | does someone use unity-2d? or is maybe a developer? | 19:32 |
| burli | I want to know why unity-2d does not support the shortcuts for the lenses | 19:33 |
| burli | like Super+a or Super+f | 19:33 |
| nava_ | i use it | 19:41 |
| nava_ | i dont know wht | 19:41 |
| nava_ | why | 19:41 |
| nava_ | but you can mail them to why they dont develop it | 19:42 |
| burli | and I want to replace Metacity with Mutter | 19:43 |
| nava_ | why ? | 19:43 |
| burli | With Metacity I have problems with tearing | 19:44 |
| nava_ | ok | 19:44 |
| nava_ | did u try unity 2d 5.2 ? | 19:44 |
| nava_ | its new | 19:44 |
| nava_ | just 1 week release | 19:45 |
| burli | It looks good so far. The only downside is, that the window decorations is not hidden at maximized windows | 19:45 |
| burli | yes, I have Precise | 19:46 |
| nava_ | good | 19:46 |
| nava_ | enjoy it | 19:46 |
| nava_ | and also u can report bugs in lunchpad | 19:46 |
| burli | I can, and I do | 19:46 |
| nava_ | good | 19:47 |
| === kancerman_ is now known as kancerman | ||
| burli | nava_, why do you use unity-2d? | 19:55 |
| vadi2 | Does unity 2d allow you to re-order icons? | 21:11 |
| vadi2 | I cannot seem to be able to drag the icon out. (using 2d for performance reasons) | 21:12 |
| kenvandine | mhall119, did you say that i should be able to add/remove filter options now? | 21:23 |
| mhall119 | kenvandine: on what? | 21:23 |
| kenvandine | a scope | 21:24 |
| kenvandine | whoops | 21:24 |
| kenvandine | completion fail | 21:24 |
| kenvandine | mhr3, ^^ | 21:24 |
| kenvandine | sorry mhall119 :) | 21:24 |
| mhall119 | ah, ok | 21:24 |
| mhall119 | no problem :) | 21:24 |
| mhr3 | kenvandine, that's right | 21:25 |
| kenvandine | mhr3, well it doesn't blow up if i do it | 21:25 |
| kenvandine | but the lens doesn't see it | 21:25 |
| mhr3 | nooo, dont tell me it doesn't work | 21:26 |
| kenvandine | mhr3, i wish i wasn't telling you that :) | 21:26 |
| mhr3 | kenvandine, could you just restart unity while your lens is up? | 21:26 |
| mhr3 | see what happens | 21:26 |
| kenvandine | i tried, restarting unity makes it show up | 21:26 |
| mhr3 | cause i have a feeling that at some point unity no longer cares about changes to the model | 21:27 |
| mhr3 | but that'd be a bug in unity | 21:27 |
| mhr3 | kenvandine, anyway now that it's restart does it react to changes in the filters? | 21:28 |
| kenvandine | i didn't try that, let me do that | 21:28 |
| kenvandine | actually, maybe it isn't unity's fault | 21:29 |
| kenvandine | i don't get the filter.changed signal | 21:29 |
| kenvandine | i connect to the signal before i add options, and get the signal when it is first populated | 21:30 |
| kenvandine | but later if i remove or add an option i don't get the signal | 21:30 |
| kenvandine | var filter = scope.get_filter ("account_id") as CheckOptionFilter; | 21:31 |
| kenvandine | filter.add_option (account.id, account.service + "/" + account.username); | 21:31 |
| kenvandine | is what i am doing | 21:31 |
| * kenvandine restarts unity | 21:31 | |
| kenvandine | ok... that doesn't really help... i have an unrelated crasher when interacting with those filters :) | 21:38 |
| kenvandine | but am am not getting filter.changed signals after i initially populate them | 21:40 |
| jasox | hey guys | 23:26 |
| snadge | gday | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
