[00:00] mas: you might be interested in http://design.canonical.com/2012/01/launcher-reveal-prototype/ and leaving your preferences in the comments [00:00] jono: shell or django? [00:00] mhall119, django [00:00] 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:01] jono: sure, give me a minute [00:01] mhall119, thanks! [00:02] oh thanks mhall, i'll leave some comments [00:03] 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] mas, some hover or glow might be really good for button feedback. [00:03] I'd rather lose 48px of 1024, than 48px of 786 [00:05] If my opinion and experience with unity on corporate machines. The launcher hidding and revealing it self on left side confuses people. [00:06] 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] 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:08] 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:09] 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:11] i mean even mac, the ultimate in controlling the end user's experience let you move the dock around [00:12] i wonder how RTL language users feel about it === htorque_ is now known as htorque [00:22] quit [00:23] bgois: it doesn't take that long to learn to look on the left [00:23] we shouldn't treat users as if they are incapable of learning a better experience [00:24] htorque: that's an interesting question [00:42] hi mhall119 [00:43] are we moving all ayatana chatter here?\ [00:44] what else what talked about on ayatana? [00:45] htorque: I'd love to see some research on RTL languages and launcher expectations [00:45] thumper: moving it here [00:45] we'll put in a redirect on #ayatana in about a week [00:45] mhall119: we should have a call next week [00:45] I'm not actually working today [00:45] thumper: yes please [00:45] 62 hours travelling home [00:45] just back this morning [00:45] eeew [00:45] sure, I'm pretty flexible, so whenever is good for you [00:46] mhall119: where are you based? [00:46] USA, east-coast [00:46] ah cool [00:46] just 3 hours different then [00:46] perhaps Monday afternoon your time [00:46] I assume you're west-coast then [00:46] that matches up with after lunch tuesday for me [00:46] or the middle of the atlantic [00:46] Nope [00:46] NZ [00:46] wait... [00:47] well three hours + one day [00:47] three hours ahead and a day behind [00:47] that still doesn't sound quite right, what time is it there now? [00:47] 13:47 [00:47] damn [00:48] ok, so 6 hours different [00:48] east and west mix up again [00:48] that sounds better [00:48] I do that all the time [00:48] no problem [00:48] you are in the same tz as lamalex, DBO, and jay [00:49] and I don't know any of them.... :( [00:49] you were ISD before? [00:49] yup, until the end of December [00:50] just looked you up on the directory [00:50] thumper: give me a ping monday morning (your time) and we'll setup a time for a call [00:50] I don't think we've met have we? [00:50] maybe in passing at UDS [00:51] I've not been to a UDS since Boston [00:51] ok,then not in passing at UDS [00:51] even then, it was a co-located launchpad sprint [00:52] you were in the launchpad team? [00:52] for 4.5 years [00:52] switched last April to DX [00:52] then it's very possible that I've bugged you about something before ;) [00:52] which is now product strategy [00:52] maybe [00:52] summit or loco-directory perhaps [00:53] * thumper has to head off for stuff [00:53] we'll chat next week === Justin____ is now known as Justinba1010 [01:41] hello [01:42] anyone here? === JoseeAntonioR is now known as JoseeAntonioR1 === JoseeAntonioR1 is now known as JoseeAntonioR [02:50] Hello. Is here the best place to give suggestions about Unity? === nick is now known as Guest94462 [03:28] Hi guys [03:28] I'm running natty here, I think I found a 'security' bug in Unity [03:28] Can someone confirme me if it happens on oneiric?? [03:28] Sure. [03:29] The bug is the following: [03:29] 1 - Press the super key (will launch unity 'default' view) [03:29] 2 - Wait to computer to block [03:30] block? [03:30] As in session block [03:30] As you can see, you can still do a one time usage of unity. [03:30] Ah so the lock screen? [03:30] yep [03:30] the lock screen dont appear directly, you can 'use' unity for a command [03:30] I think what happen is that the unity launcher stays on top of the gnome-lock-screen [03:31] and you can use unity one time, once it dissapears (the unity windows) it goes to the password of the lock screen [03:31] I'll see [03:31] Try it :) [03:31] Put your comp session lock < 2 min [03:32] and press the super :) [03:32] wait, and profit [03:32] 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] :~ [03:34] 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:37] Did you hold the super key, or press and let go? [03:38] my screen turned off and locked, it came back to the lock screen though, not unity [03:38] press and let it go [03:39] Yeah that's what I did, didn't happen here [03:39] Strange :~ === IdleOne is now known as pangolin [06:32] hi all [06:33] anybody here? [06:34] whois JanC JanC [06:39] hello [06:39] bye [06:52] hello [08:31] does anyone know how we sort the lenses in the lensbar in the dash? [08:34] kamstrup, preliminary look at 2d code says that we do whatever you guys give us [08:35] Saviq: yeah, and u3d also seems to take whatever comes out of the FilesystemLenses class [08:35] kamstrup, yup, same here it seems [08:35] but the sorting order in the dash seems to be stable, so there must be something sorting it [08:35] kamstrup, "m_unityLenses = new unity::dash::FilesystemLenses("/usr/share/unity/lenses"); for (unsigned int i=0; icount(); i++) [...]" [08:35] maybe it's really just sorting on inode accurence within the /usr/share/unity/lenses dir... [08:36] Saviq: which order are your lenses in? [08:36] i have home, apps, files, music [08:36] same here [08:36] any additional get added later [08:36] hmmm, so something is likely to sort it [08:36] s/likely/certain [08:37] yup [08:37] Saviq: AHA! vvvv [08:37] /FIXME: We don't have a strict order, but alphabetical serves us wonderfully for [08:37] // Oneiric. When we have an order/policy, please replace this. [08:37] ookies [08:38] in FilesystemLenses [08:38] yup, was just going there [08:39] except the app lens seems to be forced first [08:39] ok, I am actually implementing that policy in my home-lenses branch, so I'll put it on my todo [08:39] right [08:39] and we probably want the home lens to be first in Precise [09:05] Hi [09:22] hey greyback [09:27] 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] Saviq: morning [09:28] gord, i knew you'd said that [09:28] frck! [09:36] Saviq: I think I have addressed all your concerns in the shape tests branch. just pushed the last changes now [09:36] greyback, we need to set locale to en_something in the tests.. [09:37] otherwise I'll waste many more hours wondering what the frck [09:37] or at least require a "en_*" locale for the tests [09:38] Saviq: yep. but then we should also have some localization tests [09:38] Saviq: yeah. Getting tests running on every developers machine correctly is a pain. Why I want to use VBox [09:38] nerochiaro: agreed, and also needed for RTL tests [09:38] greyback, still, I've changed the locale on my vbox to check out RTL yesterday [09:39] 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] and since then I couldn't, for the life of mine, understand why the tests failed [09:39] (min size before it goes fullscreen by default) [09:39] Saviq: yep, my idea was to have a VBox Snapshot that everyone just uses and won't be changed [09:39] greyback, that's not safe [09:39] greyback, tests should work on virtually every machine [09:40] 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] if we just have a snapshot that noone changes, the tests won't get enough coverage, tbh [09:40] Saviq: ^ [09:40] nerochiaro, example? [09:40] 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] Saviq: multimonitor tests ? [09:41] nerochiaro, true, what greyback said - just check whether the env is ready for the test [09:41] and bypass it [09:41] exactly what I want to do for locale [09:41] check if it's en_whateveryouguysuse.UTF-8 [09:41] and drop out of the test suite [09:41] or change the locale for the duration of the tests [09:44] nerochiaro: saviq: In the shape-tests branch i checked move the dash bit away from launcher [09:44] nerochiaro: saviq:actually to the second screen [09:44] nerochiaro: saviq: the dash is no more visible there [09:44] dyams, meaning multimonitor? [09:45] saviq: yes [09:45] dyams, we didn't yet do anything re multimonitor in -shell [09:45] dyams, but you need to remember there is no "dash" and "launcher" anymore [09:45] yep, no multimonitor support in shell for now [09:45] there's just a single window [09:45] which has both the dash and the launcher [09:46] so if you've moved the dash over screen, it will just go overscreen, not to the next screen [09:46] 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:48] nerochiaro: saviq: Yes, I didn't expect it will work perfectly by just reposition it [09:48] nerochiaro: saviq: yet i didn't expect it will be clipped either. [09:48] dyams, what are you repositioning? the whole shell window or just the dash inside? [09:48] dyams, yes it will be clipped [09:48] our window is the size of your current screen's available geometry [09:48] saviq: I reposition dash only [09:49] if you go over that, it will get clipped, yes [09:49] dyams, there's simply no support gone into -shell yet [09:49] saviq: i see , height: screen.availableGeometry.height [09:49] width: screen.availableGeometry.width [09:50] saviq: Ok [09:50] nerochiaro, that fits into the merge-todo, do we have that there yet? [09:50] nerochiaro, at least getting on-par with trunk [09:51] nerochiaro, so you didn't manage to work with _NET_WORKAREA in the end? [09:51] Saviq: i don't think we have it yet [09:51] nerochiaro, ok I'll add it [09:52] 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:53] lazies :P [09:53] ok [09:53] 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] k [09:55] nerochiaro: saviq: 1) Invoke dash, 2) invoke spread, [09:55] 3) Cancel the spread [09:55] Now dash is reappearing [09:56] moreover now dash is not closing either [09:56] didrocks: welcome ;) [09:56] hey didrocks [09:56] dyams: sounds like a bug in shell. let's add to the TODO in the wiki please [09:56] 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:57] didrocks: designers say it's not supposed to [09:57] dyams: ^^ [09:57] hum? [09:57] a lot of people marks the tests are failed because they try to use it [09:57] didrocks: greyback is correct [09:58] greyback: didrocks: actually super + numpad with launcher? Or with windows? [09:58] dyams: launcher [09:59] oh that will be the shortcut for maximinizing the window now [09:59] forgot about it [09:59] dyams, you need to run the spread from the shell branch [09:59] nerochiaro, ^^ [09:59] didrocks: https://bugs.launchpad.net/unity-2d/+bug/750514 [09:59] didrocks: Super + Numpad [1] [2]....[0] Is not supported by launcher [09:59] hey Saviq ;) [09:59] nerochiaro, dyams: works fine for me, but you need to run the spread from the shell branch [09:59] Saviq: oh, right, forgot that might be the issue [09:59] not the installed one [09:59] saviq: trying again.. [09:59] dyams: well, it was for Natty, but the design changed :) [10:00] didrocks: so no Super+numpad does same as Super+num ? [10:00] s/no/now [10:00] greyback: in 3D right [10:01] didrocks: oh they changed it..? Or is it a bug in 3D? [10:01] 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] 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] stop assuming things are bugs in 3d you guys :P [10:01] anyway, there is this new shortcut stuff where it should maximize/semi-maximize window now [10:01] nerochiaro, seems right already, I'm just verifying that the tests fail without the shell being shaped [10:02] didrocks: lemme crosscheck with the shortcuts gdocs once [10:03] didrocks: am consulting with design now :) [10:03] thanks :) [10:04] dyams: John showed me this gdocs, but I can't find it anymore [10:04] didrocks: hrer https://docs.google.com/a/canonical.com/document/d/1jqeKtIJwqLtl58Wk_fqjr9Rrgxn9zsouCYOo-cZsLSE/edit?authkey=CLGG9NkJ&hl=en_GB [10:05] dyams: thanks [10:06] dyams: hum, no, it's ctrl + alt in fact [10:06] so nothing on super + numpad [10:06] seems a lot of people expect it to do the same than super + keynum [10:06] didrocks: see the other channel :) [10:08] dyams: dust off that Super+keypad branch, it's going in :) [10:09] greyback: :) sure, I can do it... :) [10:11] greyback: should we wait for shell work or we merge it current trunk already? [10:13] dyams: as ultimately we'll be using shell, there's little point in merging it to trunk only. [10:13] dyams: see how easy it ports to shell [10:14] greyback: Ok, I'll work on shell branch [10:15] 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] saviq: Yes, Spread works better if I launch it from shell itself [10:15] dyams, "better"? not "correct"? [10:16] saviq: but that didn't solve the issue either [10:16] greyback, true [10:16] greyback, if they fit nicely in both - then both [10:16] otherwise - shell it is [10:16] saviq: two issues i noticed. [10:16] Saviq: agreed [10:17] saviq: 1) Launcher won't stay open when spread is active, it disappears after a few seconds [10:17] weirds, should be forcedVisible, add to the wiki please [10:18] 2) after 3-4 attemps dash stays open and won't go away [10:18] saviq: sure [10:35] nerochiaro: You already added the Dash clipping issue in wiki? [10:35] nerochiaro: Or is it not required? [10:36] dyams, there's no "dash clipping" [10:36] that is not an issue [10:37] saviq: Ok [10:37] dyams, why would you move the dash itself anyway? [10:38] the dash is supposed to be stuck to the launcher, and proper multimonitor support will come later [10:38] Saviq: multi-monitor [10:38] dyams, we won't be moving it [10:38] we will have a dash per-screen [10:38] just as we will a launcher per-screen [10:38] Saviq: no [10:39] dyams, I know, it will just be shown on one screen [10:39] current screen [10:39] but that doesn't mean we will necessarily move the window around [10:39] saviq: Ok [10:40] saviq: then it is like shell per monitor. no? [10:40] dyams, yes [10:40] saviq: i got it :) [10:45] booyacacha mhr3, gord! nailed the home-lenses despite njpatel trying to trip me up with his tricks! :-D [10:45] woohoo [10:45] he's trixy [10:45] just adding some tests [10:45] then mp [10:46] kamstrup, you know omg already wrote about this stuff right? can't disappoint them now ;) [10:46] gord: indeed :-) that kinda upped the pressure a bit... [10:46] gord: as you'll learn soon enough, this was not exactly trivial to get right [10:46] I basically wrote an in-memory relational db :-) [10:47] oh dear, /me gets his finger over the rejected button [10:47] lol [10:47] comment: stop re-writing mysql every six months [10:47] boring [10:48] 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:49] kamstrup, so... i suppose the the merge diff in counted in dozen thousands lines? [10:49] is counted in*? [10:52] indeed [10:53] nerochiaro, I'm pushing just the input shaping tests to lp:~saviq/+junk/shell-shapetests [10:53] nerochiaro, can you try them? I can't seem to be able to fail them even without input shaping.. [10:53] Saviq: how do you remove input shaping ? [10:53] nerochiaro, still pushing, though [10:54] nerochiaro, I just merged the commits that did the tests [10:54] not those that actually implemented the feature [10:54] nerochiaro, pushed [10:54] Saviq: on top of unity-2d-shell ? [10:54] nerochiaro, yes [10:54] nerochiaro, btw, -shell has stuff merged from trunk again this morning [10:55] i saw that [10:55] let me try [10:55] I freakin' can't fail those tests... wth [10:56] Saviq: checking. might be something wrong with waht i do [10:56] nerochiaro, btw that's why it's good to write the tests first, too ;) [10:56] otherwise you never know if they actually fail :] [10:57] or at least make it easy to only merge the tests and not the fix itself [10:57] brb [10:57] Saviq: you have a point [11:04] Saviq: they don't seem to fail here neither. i'm looking into why [11:05] 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:06] Saviq: revision 934 (which i added this morning) is the one that should make the tests properly fail [11:07] nerochiaro, oh [11:07] nerochiaro, will check out again in a bit [11:07] Saviq: okies [11:07] Saviq: i double check and i pushed all of them. the last on top of my branch should be 935 now [11:19] 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] i'll bbiab [11:40] 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:41] davidcalle: depends... :-) [11:41] davidcalle: it could be, but not if we let users override [11:43] i can imagine that in some languages the ordering isn't what we want [11:44] unless it's being sorted on non-localized name [11:44] kamstrup, anyway so what was the thing you wanted me to look at yesterday? [11:44] mhr3: some tweaks to the music lens [11:44] kamstrup, ok. I'm just going to make an Aardwark lens to mess with you guys. ;-) [11:45] Aardvark* [11:45] kamstrup, oh dear :P [11:45] is there a bug opened? [11:45] mhr3: when doing global search, we need to collate the Songs and Albums categories into one Music category (with albums first) [11:46] mhr3: it's in relation to the new homescreen, it's mentioned briefly there [11:46] mhr3: I talked with JohnLea about it [11:46] mhr3: I have a partial branch ready... hold on I'll upload it [11:46] Dee.Transaction comes to rescue us :) [11:49] mhr3: you can save yourself a bit of time if you start from lp:~kamstrup/unity-lens-music/home-lenses [11:59] nerochiaro, so here's what I'm doing: `bzr branch lp:~unity-2d-team/unity-2d/unity-2d-shell-shaped-testability-shapetests` [11:59] nerochiaro, `bzr merge -r 913..907 .` [11:59] there are two small conflicts [11:59] but that gets rid of the actual shaping code [11:59] Saviq: I don't understand why you do that merge [12:00] nerochiaro, I want to get rid of the actual shaping [12:00] Saviq: to test that the tests fail ? [12:00] I want to have shell with shape tests on top [12:00] yes [12:00] and they don't [12:00] Saviq: ok [12:00] nerochiaro, http://pastebin.ubuntu.com/ [12:00] facepalm [12:00] nerochiaro, http://pastebin.ubuntu.com/810617/ [12:01] Saviq: only one fails [12:01] hmm [12:01] 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:02] Saviq: if it does, then something is messed up again and the branch is not current [12:02] Saviq: but honestly to test that the tests fail if the shaping isn't there, i'd just remove the call for XShapeCombine... [12:03] even though i understand why you're doing it that way [12:03] standup [12:03] sure [12:03] i'm there already [12:03] Kaleo, you comin'? [12:14] nerochiaro, lp:~saviq/+junk/shell-shapetests [12:15] Saviq: looking into it now [12:27] 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:28] Saviq: hangs as in IM compare takes 100% cpu seemingly forever [12:29] hi all [12:29] nerochiaro, isn't that why you were comparing the dimensions of the images? [12:30] that imagick hanged when they were different? [12:30] and also, they shouldn't ever be different, should they? [12:30] 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:31] 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] 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:32] Mart_ini, looks like your gnome-settings-daemon crashed, did you try to log out and back in? [12:32] yeah:/ [12:32] and didnt help:/ [12:33] even restart of whole system [12:33] Mart_ini, you can change the theme in gnome-control-cente [12:33] r [12:33] yes I can but it didnt work [12:34] Mart_ini, try in #ubuntu, here isn't really the place for that [12:34] There I have few options like Ambiance , radiance, high contrast but even one of it changes nothing [12:34] ok [12:34] there's more people there that will be able to help [12:35] no problem, thanks:) [12:35] nerochiaro, sure, but the test should only pass if the images are the same size _and_ the input shapes are correct, right? [12:36] nerochiaro, I removed the unlinks, the masks you generate look ok [12:37] except [12:37] let me just have one at a time [12:37] ah no, ok - there's four [12:37] launcher, launcher + dash, launcher + collapsed dash, fullscreen [12:38]