=== pangolin is now known as pangolin-Supreme === pangolin-Supreme is now known as pangolin [00:07] * thumper hunts for fud [02:40] thumper, hey another update on the bug: https://bugs.launchpad.net/unity/+bug/711199 [02:41] thumper, mhr3 finished the work in the lenses and I have the code set up for unity. Whats left is the HomeView which is getting reworked atm [06:12] <[reed]> where does the unity launcher save the things that are stored on it? documentation seems to say ~/.local/share/applications/, but that's not true in my case [07:58] morning [09:01] Saviq: answered your question about if we need C++ for https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_no_dbus_to_ourselves/+merge/89247 Basically with the current status of the rest of the code, yes [09:08] Saviq: do you know what's supposed to set the DASH_MIN_SCREEN_WIDTH and DASH_MIN_SCREEN_HEIGHT env variabled that the dash uses in trunk to choose if to go always fullscreen ? [09:08] tsdgeos: dyams: ^ [09:10] guys, I don't have power, trying to cope on 3G, but I might not do well [09:10] nerochiaro: no idea [09:11] greyback: do you know ? ^ [09:12] can you repeat? I just joined [09:12] greyback: do you know what's supposed to set the DASH_MIN_SCREEN_WIDTH and DASH_MIN_SCREEN_HEIGHT env variabled that the dash uses in trunk to choose if to go always fullscreen ? [09:13] nerochiaro: no I don't. I didn't even think they were env vars, I thought they were constants [09:13] greyback: static int minHeight = getenvInt("DASH_MIN_SCREEN_HEIGHT", [09:13] DASH_MIN_SCREEN_HEIGHT); [09:13] greyback: i'll try to look who did the commit then [09:13] nerochiaro: yes just grepped :) No idea [09:15] greyback: wow it's from agateau at the end of february last year. it's the commit that introduces the non-fullscreen dash :) [09:15] let's check what unity3d does... [09:16] nerochiaro: interesting. Might make testing the maximize stuff easier?? [09:16] greyback: i was actually thinking if it's possible to remove the conditional on that env var ;) [09:17] nerochiaro: :) [09:17] greyback: i just grepped in unity and they don't seem to read that env anywhere [09:18] smells like dead code to me [09:18] nerochiaro: then I don't really see why we need it. [09:18] nerochiaro: OEM never used it? [09:18] greyback: no idea [09:19] nerochiaro: either way, I doubt removing the code would set them back [09:20] greyback: yeah, i'll zap it [09:20] nerochiaro: great, thanks. Another nice all-red qdiff to look at :) [09:21] greyback: nah, just less stuff i am bringing back from trunk to shell [09:21] but same effect [09:21] ak oh [09:21] nerochiaro: lemme check [09:24] nerochiaro: Didi you check this ? DASH_MIN_SCREEN_WIDTH = 1280; [09:24] DASH_MIN_SCREEN_HEIGHT = 1084; [09:24] dyams: where ? [09:24] dyams: oh, seen it [09:25] DashSettings:: [09:25] nerochiaro : DashSettings:: [09:26] dyams: i still don't see that used anywhere in unity-3d though [09:27] nerochiaro: then how they find out if the screen is wide enough to display dash in desktopMode? Just asking [09:28] njpatel: do you know if the dash in unity has a feature where if the screen resolution is below a certain threshold it will always display fullscreen ? [09:28] dyams: better to ask ;) [09:28] nerochiaro: As I remember class DashSettings itself was an import from 3D though :) [09:29] dyams: it might be that i'm not good enough at grepping, then [09:29] nerochiaro, yes, it should, I believe it checks height < 800px [09:30] njpatel: any idea where that check is in the code ? [09:30] nerochiaro, DashController.cpp or DashView.cpp would have that code [09:30] njpatel: looking. thanks [09:37] kamstrup, btw there's an issue - when i was doing the music-lens branch i noticed that unity doesn't care about position of an item in the model - so whenever you add something to the model unity just appends it to the result list (and it's understandable, the splitting to categories doesn't make this easy), this makes MergeStrategy a bit useless, you can't really sort the results with it [09:37] Saviq: do you think you'll be able to have a look at the MR i put you in with your power issue or you prefer me to bug someone else to have a look at them? [09:37] nerochiaro: :) === dyams is now known as dyams|lunch [09:37] mhr3: :-( [09:38] mhr3: we can look into it when we've landed the home-lenses branch [09:38] mhr3: I had the same issue with categories, but I fixed it in unity [09:38] kamstrup, right, it's doable, but not exactly trivial [09:38] tsdgeos, might be better if you bug someone else, I can't be sure I'll make it [09:39] mhr3: hehe, wait till you see the home-lens, you'll redefine trivial ;-) [09:39] 3G doesn't work, either, I'm on EDGE now, and not going to be here long [09:40] kamstrup, i'm worried already :P [09:40] Saviq: okidoki [09:42] nerochiaro: added you to the 3 MR that were on Saviq in case you have time [09:43] tsdgeos, I might be able to do the BFB one [09:43] was already on it before [09:43] cool [09:43] tsdgeos: i'll get one after i'm finished with the tests for this task i'm doing [09:47] tsdgeos, approved [09:47] Saviq: cheers [09:48] tsdgeos, do you have an idea about testing the root qml selection? [09:48] actually did not think about that [09:49] should not be that difficult to do, just put a dummy .qml in the testing repo, point it there and then check via testability that the contents of the qml file is there [09:50] i'll give it a go [09:50] yup, I was thinking similiar [09:53] greyback: is there any special way to set env vars with testability ? [09:54] nerochiaro: set them in the @app.run method [09:55] nerochiaro: like :environment => 'LC_ALL=en SPECIAL_VAR=value' [09:55] greyback: awesome === dyams|lunch is now known as dyams [10:01] sorry all, I'm going offline, not sure I'm gonna make it for the standup, hope you boys will be good [10:02] Saviq: good luck [10:02] Saviq: ok so [10:14] greyback: there? [10:14] tsdgeos: yep [10:15] greyback: i'm very confused, i am putting a printf inside the "if (arrayContains(argv, argv + argc, "-testability")) {" and it never gets there [10:16] tsdgeos: I know the qt libs look for -testability switch before we do, but I hope they don't remove it from argv [10:17] well that is the "standard" QAppplication behaviour [10:17] they eat the args they know [10:17] that's why the check for style is done in earlySetup [10:17] ah in which case, there's your answer:( [10:17] I see [10:17] instead of on the constructor [10:17] then it means we don't really need that code? [10:18] tsdgeos: where is it? Did I put it there by accident? [10:18] greyback: Unity2dApplication::Unity2dApplication [10:19] tsdgeos: oh feck, I thought I removed that. [10:19] tsdgeos: yes all that is not necessary, as is testabilityinterface.h [10:19] oh [10:19] ok :D [10:19] * tsdgeos was getting increasingly confused by that [10:19] qt since 4.6.4 (I think) does all that already [10:20] can we kill it? [10:20] yep [10:20] When I started playing with Testability, I didn't realise it was built into Qt [10:20] docs didn't make it clear [10:21] did nux or compiz break abi or something recently? [10:21] * kamstrup getting weird segfaults [10:21] dyams: i'm looking at your review on https://code.launchpad.net/~unity-2d-team/unity-2d/unity-2d-shell-dash-panel-buttons. regarding this comment: "2) In future, Dash mode needs to be persistent. It should remember fullscreen/desktop mode across login/logout. [10:21] In your current change is it possible to restore the previous dash mode?" i think that if it's something "for the future" it's better to worry about it later when we actually need to implement that feature [10:22] nerochiaro: no prob, I was just asking [10:23] dyams: ok, i'll leave it out for now. fixing the rest of the comments. thanks for the review btw [10:26] nerochiaro: no prob [10:26] greyback: want me to make the MR to kill it? [10:27] mhr3: did you have a branch for u-l-m with the collated categories in global? [10:28] mhr3: if so, can you attach it to https://bugs.launchpad.net/unity/+bug/885738 please? [10:28] kamstrup, k [10:28] tsdgeos: yeah please do [10:33] mhr3: works well, one thing though - the music lens should not show anything when we don't have a search in global [10:33] oh, it shouldn't? [10:34] easy fix [10:34] dyams: updated the MR to match your review: https://code.launchpad.net/~unity-2d-team/unity-2d/unity-2d-shell-dash-panel-buttons/+merge/89436 [10:35] kamstrup, does all these music lens tweaks impact the way the rbox scope should behave? [10:35] nerochiaro: thx, i'll check [10:35] davidcalle: yes [10:36] davidcalle: when I mp the homelens branch I'll attach some screenies for design review. When we have that up we can talk it through? [10:38] kamstrup, pushed [10:39] davidcalle, are you doing the rb scope as a separate remote scope? [10:39] kamstrup, no problem. I'm on the data fetching part, the global search part can wait. Are there changes for the lens view? Still tracks/albums ? [10:39] in python? [10:39] davidcalle: afaik the lens view is the same [10:40] mhr3, yes for both. Do you hate me? [10:40] :) [10:40] davidcalle, as a default scope, i think we'll want a native one [10:43] mhr3, won't this be an issue for people upgrading from Oneiric? A default scope recommending rhythmbox will install it. I don't think that's ideal. [10:44] davidcalle, it doesn't need to recommend anything, it can be a local scope in the lens that will fail gracefully if rb isn't installed [10:44] that's the case with the banshee scope afaik [10:47] mhr3, ok. There is still an issue, afaik I'm the only person working on the Rhythmbox scope and Vala is still an issue for me. I can give it a try, but it won't be nice before feature freeze. [10:49] davidcalle, no worries i can help [10:49] although you'll find out that processing strings and xml is so much nicer in python :/ [10:50] Well, internal vala scope it is, then. === om26er is now known as om26er- === om26er- is now known as om26er [11:14] nerochiaro: currently the dashmode is already saved in dconf. [11:15] greyback: we don't have unity-2d "staging" builds for oneiric anymore? [11:15] nerochiaro: the same parameter("com.canonical.Unity.farmFactor) used by unity3D is used in 2D too [11:18] tsdgeos: hmmm, looks like that got turned off. [11:18] tsdgeos: asking about it [11:18] nice [11:19] dyams: yes, but it's the form factor, it's not the dash mode [11:19] dyams: they are two differnt things, no ? [11:20] dyams: form factor is for saying desktop, tv, phone, tablet, and so on [11:20] dyams: while dash mode is only for saying if dash should be fullscreen or not fullscreen [11:21] nerochiaro: dash.qml is using the farmfactor to set fullscreen/desktop [11:22] nerochiaro: you may be right that its for saying desktop, tv, phone, tablet...and so on. [11:22] dyams: that is because only in desktop mode the dash can be non-fullscreen [11:22] nerochiaro: May be they misused it? [11:22] dyams: no, it's right to have it there. but let me check again [11:23] tsdgeos: staging PPA is precise only now. unity-2d is building right now [11:23] greyback: ok, sad for us still on oneiric [11:24] tsdgeos: I know. See dx channel for why [11:25] nerochiaro: currently, toggling the dash mode is also chaning the farmFactor in gconf. [11:26] dyams: is it ? where is the write happening? [11:27] DashSettings itself [11:27] nerochiaro: It is in DashSettings::setFormFactor [11:27] dyams: yes, but does anyone actually call that function ? [11:28] nerochiaro: currently? yes [11:28] dyams: where ? [11:28] nerochiaro: from WindowHelper.cpp I believe, lemme check..one sec [11:29] dyams: i think windowhelper just change isFullScreen [11:29] nerochiaro: Yes, WindowHelper::unmaximize() [11:30] nerochiaro: Currently == from unity-2d/trunk [11:30] dyams: ah, ok, i already removed that [11:30] dyams: and i think we need to remove DashClient::formFactor completely [11:30] nerochiaro: You mean, DashSettings::formFactor? [11:31] dyams: yes. because it doesn't make sense in DashClient. if someone wants to read the unity form factor it needs to read it from unityConfiguration [11:31] but it's not the dash form factor. it's the form factor for the entire unity [11:31] nerochiaro: agreed [11:31] dyams: i'm gonna change it as part of that branch you are reviewing then [11:32] nerochiaro: Don't we need a explicit parameter for DashMode? [11:32] nerochiaro: in Dconf i mean [11:32] dyams: we need it later, when we want it to be permanent across sessions, i guess [11:32] nerochiaro: ok. I'll wait [11:33] <[reed]> where does the unity launcher save the things that are stored on it? documentation seems to say ~/.local/share/applications/, but that's not true in my case [11:33] dyams: and when it needs to be added, please let's set it from the dash itself, not in dashclient [11:34] [reed]: in dconf i think [11:34] <[reed]> nerochiaro: ok, thanks [11:34] nerochiaro: Ok, sure [11:35] [reed]: /desktop/unity/launcher/favorites [11:35] <[reed]> thx [11:35] nerochiaro: lemme check if 3D is also doing same thing... using the dconf->'formFactor' for desktop/fullscreen mode [11:35] dyams: unity-3d doesn't have all the form factors that 2d has, IIRC [11:36] nerochiaro: ok.. if they are using that setting then we need to be consistent, no? [11:37] dyams: if there's a specific formFactor for the dash that means only fullscreen or non-fullscreen then yes, otherwise it seems like a bug to me [11:38] dyams: because what we call formFactor is global to the entire unity-2d [11:38] nerochiaro: agreed [11:53] nerochiaro: In 3D they are using it(gconf->formFactor) as a setting to store fullscreen/desktop mode [11:54] dyams: gconf or dconf ? [11:54] nerochiaro: d :) [11:54] dyams: :) and what's the full path of the key ? [11:55] nerochiaro: They are chaning it everytime toggle maximize is called. check here : PanelMenuView::OnRestoreClicked() [11:55] nerochiaro: one sec [11:55] nerochiaro: com.canonical.unity.formFactor. no? [11:56] dyams: i don't know, but if it's that key, then it's definitely wrong to use it the way they are using it [11:56] because that's the global unity form factor, not hte dash form factor [11:57] dyams: and we're doing something wrong too, because we're reading the global form factor from com.canonical.unity-2d [11:58] nerochiaro: Changing that setting to something else might is technically correct, but that might confuse the current users [11:59] nerochiaro: It was for consistency purpose I believe. [11:59] dyams: the real issue is: do we want to share that setting with unity3d ? if we don't it's fine as it is, if we do then we should come to an agreement, or just use the wrongly named setting from com.canonical.unity with comments to explain what it should be in reality [11:59] nerochiaro: but sure, that could lead to confusion too [11:59] Kaleo: any input on the above ,please ? ^ [12:01] nerochiaro: let me read [12:02] nerochiaro: 2d's semantic of the key is correct I believe [12:03] Kaleo: so we're fine with that we have and we don't want to share this setting with 3d (to have fullscreen persist between sessions) [12:04] nerochiaro: yes, it's a tradeoff [12:04] awesome [12:04] thanks for the input [12:04] nerochiaro: we should have a good name for that feature (dashFullScreen or something) [12:04] mhr3: there was a conflict on https://code.launchpad.net/~mhr3/unity-lens-music/home-lenses/+merge/89667... not sure where that came from. I also added a small nitpick [12:05] Kaleo: it's already called isFullScreen over DBUS, so i guess we'll use dashFullSCreen or dashIsFullScreen in dconf === om26er_ is now known as om26er [12:08] nerochiaro: makes sense to me [12:09] nerochiaro: kaleo: a boolean? [12:09] dyams: yes [12:09] it's either fullscreen or not ;) [12:11] nerochiaro: no need to worry what is Netbook or Desktop mode either. Easy and Simple :) [12:13] dyams: yep [12:13] :) [12:48] mhr3: I still get the g_variant_unref: assertion `value->ref_count > 0' error on libunity trunk when using dee trunk... I thought we fixed that with the tweak to the DeeSerializable? [12:48] kamstrup, yep, it should work [12:49] kamstrup, fwiw it's ok here [12:49] I think my system is hosed [12:49] unity is also crashing with no end [12:50] mhr3: argh! the i18n snuck in... :-/ *grumble* [12:50] I tried SO hard to not get it in [13:02] * Saviq is back [13:08] * greyback rejoices [13:09] mhr3, rbox xml parsed and tracks thumbs too with gio... So, the amount of help needed should be minimal. [13:10] greyback, hey bug 917458 , thoughts? [13:10] davidcalle, oh wow, awesome! [13:10] om26er: looking... [13:13] om26er: could have accidentally put one Firefox on one workspace, and Terminator on the other. It would explain the behaviour. [13:13] om26er: I'll comment on it now [13:13] greyback, ah, thanks :) [13:42] greyback: I guess https://bugs.launchpad.net/unity-lens-music/+bug/841902 implies some work on unity-2d as well? [13:43] kamstrup, ours does that already [13:43] there was a new filter type added "filter-checkoption-compact" that assumes unity will render 3 columns [13:43] Saviq: you guys are just to hawt ;-) [13:43] oh ok, so ours hacks that up [13:44] i.e. "if lens == 'music': 3 columns" [13:44] Saviq: yep it's a hack, tiagosh has done a little work getting ready to support it [13:44] ah, I don't expect many customers for the "filter-checkoption-compact" filter type though, so not big prio [13:44] still, shouldn't be a big issue [13:44] * kamstrup adds a u2d task then [13:44] great [13:45] kamstrup: yep, it's in progress already I believe [13:48] kamstrup: filter-checkoption-compact is not in staging either..still waiting...lemme check again now [13:49] it's been in libunity and unity-lens-music trunks for a few days I believe [13:49] dyams: if you're on Oneiric, you may not be seeing any updates from the staging PPA. It's Precise only now [13:50] since Wednesday [13:50] greyback: sure, am on precise [13:52] kamstrup: there are 4-5 branches which one is final revision [13:53] dyams: good. last libunity build on staging was 2 minutes ago, so that filter-compact hint should be there now [13:53] greyback : lemme refresh [13:54] dyams: now don't ping me for 2 minutes, it's mucking up my tests :) [14:03] kamstrup: greyback: yay! filter-checkoption-compact is coming to unity2d-shell [14:03] saviq: ^^ [14:03] cool [14:03] saviq: greyback: lemme do it for unity2d-shell. [14:05] dyams: it was you I gave to do it, not tiagosh. My bad. Yes please do [14:06] greyback: no prob [14:07] woot [14:18] kamstrup: all renders will have two columns except "filter-checkoption-compact", no? [14:18] kamstrup: only "filter-checkoption-compact" have 3 columns [14:19] dyams: in short, yes [14:20] dyams: the reason we choose the "compact" moniker was to leave that a bit up to the unities rendering this. The lens can say "Like normal filters, but I have more options". [14:20] it just so happens that our Unity2/3d implementations use a 3 column layout for this :-) [14:21] kamstrup: Ok, thank you for the description [14:21] kamstrup: :) [14:26] kamstrup, there's something odd with your branch - hiding the dash using super seems to reset the search string for the lenses, but it stays in the entry [14:26] JohnLea: ping [14:26] greyback: you were planning having tests for modes != intellihide, right? how far is that? [14:27] kamstrup, ie "gedit" -> see gedit in results -> hide with super -> summon again -> see "gedit" in the entry, but lenses show results for "" [14:27] tsdgeos: not got ot it yet, sorry [14:27] *to [14:27] mhr3: let me check [14:28] greyback: oh, i'm working on something "show-all-the-time" mode only, what's your suggestion for the test? change it forth and back manually? [14:30] mhr3: hold on, I need to fix my system. Got hit by a double whammy with nux abi break and libglew1.5->1.6 abi break as well... b000000orked [14:32] thumper: ping === dyams is now known as dyams|away [14:34] tsdgeos: launcher in the fixed state? (you're doing the strut stuff). Manual is only thing I can suggest just now. [14:34] greyback: yes, the strut stuff [14:34] greyback: ok, i'll go manual then [14:37] mhr3: I get it now... trunk also has this in reverse I think. It clears the text entry but not the lenses. You just don't see it because it's hidden [14:37] (behind the home screen tiles) [14:38] kamstrup, no trunk doesn't clear the search string [14:38] that's the statefulness design wanted, no? [14:38] mhr3: odd... it does here [14:39] kamstrup, are you hiding using super or esc? [14:39] mhr3: I know, looking at the code it looks like it doesn't, but in reality it does; somewhere [14:39] mhr3: super [14:39] please don't say those are different [14:39] afaik, yes :P [14:39] ah, so Esc is "back" [14:39] makes sense [14:40] mhr3: what do you see if you hit , type "ged", , and then to re-show dash? [14:41] I get a cleared home screen with the tiles [14:41] kamstrup, trunk or your branch? [14:41] trunk [14:41] a sec [14:42] i suppose "a crash" doesn't count? :) [14:42] mhr3: oh, I can add that in my branch as well if we need to mimic trunk? [14:42] ;-) [14:43] mhr3: you might be hit by the abi changes as well [14:43] it's the music lens and compact filter [14:43] ah yeah [14:43] unity thinks it better crash if it doesn't know a filter [14:43] ok, so i get the search cleared [14:43] saw that [14:44] and i see the huge icons again [14:44] right [14:44] then it's the same as me [14:44] nevermind then, i assumed it'd behave like lens views now [14:44] how about I just clear the entry in my branch then, and we should be equiv. to trunk [14:44] better check with john what's desired now? [14:44] JohnLea, ping [14:44] then we can chat to John about what we should *actually* be doing ;-) [14:45] seems like he doesn't have time [14:45] you killed him! [14:45] better now JohnLea? ;-) [14:45] someone resurrected him [14:46] kamstrup; hyia, out of meeting now [14:46] JohnLea: I am just discussing with mhr3 what state we carry around in the dash [14:46] JohnLea: currently trunk clears the text entry when you hide the dash [14:47] which makes sense since we want to show the huge icons [14:47] (and places you back on the home screen next time dash comes up) [14:47] right [14:47] My gut instinct says we should still reset [14:47] kamstrup; the state of almost everything should be retained. text entered into search field, filters, filters open or closed, category headers expanded or collapsed, etc... [14:47] the new home screen contains lots of useful stuff [14:48] k [14:48] one sec, let me dig out a bug... [14:48] found it. have a look at https://bugs.launchpad.net/ayatana-design/+bug/914759 [14:49] this fixes the inconsistency we have had with Dash Home and Lens behaviour [14:49] kamstrup, mhr3: ^ [14:49] ah [14:49] ok, i think that clears the it, thx JohnLea [14:50] yep [14:50] kamstrup, mhr3; thx! [14:50] mhr3: if I can easily implement it then I'll do so. Otherwise I'll just clear the entry for now and then we can add it as a later task to implement the statefulness [14:50] JohnLea: I'd like to talk to you about coming up with some kind of guideline for the creation of new lenses [14:51] kamstrup, ok [14:51] mhall119; e.g. what a Lens should and shouldn't do? [14:51] JohnLea: yeah, since we're starting to see people make per-source lenses, not per-content-type lenses [14:52] I'd like to have a wiki page or something to point them to that gives "official" recommendations about when you should and should not make a new lense [14:52] mhall119; yes, that would be very useful. Did you see my post on the ayatana mailing list about part of this subject a little while ago? [14:52] nope (not sure i'm on that ML, let me check) [14:53] is it an LP list, or lists.u.c? [14:53] mhall119; that would be a really good, ping me when you have a first draft ready. One sec, I'll dig out the post [14:54] I like how you turned that back around into work for me :) [14:54] mhr3: hrm... I've started getting segfaults from unity in my branch http://paste.ubuntu.com/814339/ . The odd thing is that I don't get it when using the standalone dash... [14:55] kamstrup, fun, works here though :) [14:56] mhr3: yeah, my gut instinct says it's somehow because I broke libunity-core abi... [14:56] * kamstrup will never break any abis again [14:56] i was just going to say that [14:56] EVER! [14:56] (today. at least) [14:57] kamstrup, it's almost like you didn't use jhbuild or something :P [14:57] mhr3: I use nothing else :-) [14:57] mhall119, would you mind if we draft it together in a Google doc? [14:58] mhr3: btw, I looked at the lens-icon-shifting-issue you pointed out. It's present in trunk as well. So not my bad! :-) [14:58] davidcalle: 50% less work for me, definitely [14:58] JohnLea: what was the title of your email onthe ML? [14:58] kamstrup, no it's not, sorry there's really something wrong with your unity :P [14:59] JohnLea, mhall119, mhr3, davidcalle: the per source lenses thing is probably a relic of the old libunity API where the concept of "sources" wasn't really wired up. mhr3 fixed this in trunk where it should work great [14:59] mhr3: fuuuuu! [15:00] kamstrup: what do you mean? [15:00] mhall119; just pinged it to you in irc, let me know when you have a first draft available. This is a piece of documentation that we are really missing, thanks for spotting it and offering to help [15:01] JohnLea: thanks [15:01] mhall119, we now have api that the scopes can use to show in the lens a "Source" that can be enabled/disabled [15:01] mhall119: I was talking in relation to the lenses-per-source vs lenses-per-content-type you mentioned [15:02] ok, I understand now, thanks [15:02] mhr3: I am *quite* sure that it is in trunk. Have you tried an up-to-date lp:unity and then running standalone-clients/dash (compile it with 'make dash') [15:03] kamstrup, i'm running trunk unity right now, there's no offset issue [15:03] oh wait [15:03] no i'm not [15:04] it's the one from precise [15:04] aha! [15:04] kamstrup, ok you win [15:06] davidcalle: JohnLea: invite to google doc sent [15:07] mhall119, thanks. [15:10] JohnLea: do we have any document about when to create vs. reuse an indicator? I think there might be some overlap in intention between indicators and lenses === om26er_ is now known as om26er [15:20] nerochiaro: what does "Put back in support for 4-finger slide gesture (in a way that's not tied to the panel)" mean in the MergePlan wiki? [15:21] tsdgeos: let me point you at the relevant code. hold on [15:22] tsdgeos: in short, on touch-enabled devices when you slide on the screen with 4 fingers you should "drag out" the launcher, which will then stay out if you slide past a certain "distance [15:22] hmmm [15:22] seems difficult to test :D [15:22] * tsdgeos looks for something else to do [15:23] tsdgeos: :) that's the problem everyone will have with it :) [15:23] i think it's something only Kaleo himself can do, i don't know anyone else with touch devices [15:24] nerochiaro: I can indeed [15:24] nerochiaro: anybody with a macbook can [15:24] * tsdgeos looks around [15:24] no macbook [15:25] Kaleo: none here [15:25] :) [15:25] nobody in the team has anything but me? :) [15:25] tough beans [15:25] Kaleo: i've a red tshirt! [15:26] nerochiaro: you doing "When screen/desktop is resized adjust shell size accordingly and update input mask" ? [15:26] Kaleo: serves you right for buying shiny white hardware [15:26] * greyback is playing it quiet :) [15:26] tsdgeos: that one is easy. try killing the panel when the shell is up [15:26] tsdgeos: fix the wrongness you see [15:26] ok, though you were doing it somehow [15:27] tsdgeos: i was "in the area", but didn't get to fix that specific one [15:27]