#ubuntu-unity 2012-09-01 <Mirv> I think it's mostly about not using some operations that are not part of GLES spec, and then figuring out if there's a direct equivalent or if something more indirect has to be done <Mirv> with my 0 experience I wouldn't think it'd be too hard for eg. single plugin :) <Mirv> (it's always so easy to say such things!:) <bluesabre> Hi charles, ochosi tells me that you might be able to help with an indicator-dev question <mhall119> mhr3: halp! <mhall119> I upgraded to unity 6.4, and now it's segfaulting instantly <mhall119> something about the ThumbnailGenerator and more than one thumbnail generator being created <mhr3> that's just a warning, that would cause a crash <mhr3> would NOT <mhall119> well it segfaults immediately after <mhall119> could it be something with old plugins? I got some dialog about using unityshell.so and unitymtgrabhandles.so (or something like that) <mhall119> http://paste.ubuntu.com/1180456/ <mhall119> is the log from running unity from the commandline <mhr3> looks odd <mhr3> failing to spawn dbus is pretty bad <mhr3> something's wrong with your dconf <mhall119> I tried unity --reset <mhall119> didn't fix it <mhr3> i wouldn't be surprised if this had something to do with you installing schemas on your own <mhall119> what schemas? <mhall119> oh, the ones I did when using the staging ppa? <mhr3> --reset doesn't do anything now that compiz uses gsettings <mhall119> oh <mhr3> yes <mhall119> :/ <mhall119> so...any ideas on how to fix it? <mhr3> you don't want to hear what i'd say :) <mhall119> I want it more than I want metacity without gnome-panels <mhr3> well... there's an iso on ubuntu.com.... you know the rest :) <mhall119> :p <mhall119> there's gotta be a way to reset the glib schemas without a reinstall <mhr3> sure, if you manage to remove everything that's not coming from package, dconf should fix itself and everything should work <mhall119> no way to downgrade to 6.2? <mhall119> warning: Schema 'com.canonical.Unity.ApplicationsLens' has path '/desktop/unity/lenses/applications/'. Paths starting with '/apps/', '/desktop/' or '/system/' are deprecated. <mhall119> warning: Schema 'com.canonical.Unity.Runner' has path '/desktop/unity/runner/'. Paths starting with '/apps/', '/desktop/' or '/system/' are deprecated. <mhall119> warning: Schema 'com.canonical.Unity.FilesLens' has path '/desktop/unity/lenses/files/'. Paths starting with '/apps/', '/desktop/' or '/system/' are deprecated. <mhall119> when glib-compile-schemas gets run <mhall119> but I removed the schema I manually put in, and ran apt-get install --reinstall unity unity-common and it put them back and ran the above <mhr3> mhall119, yea, those are useless <mhr3> did you try unity --debug? <mhr3> still, i think it's dconf <mhall119> mhr3: guest session works fine, so it's not a system-wide issue <mhall119> I deleted my .compiz and .compiz-1 folders in my home directory, and now unity load <mhall119> ss <mhall119> except now any time I hit 'alt' the window in focus is closed :( <mhall119> which is pretty annoying <mhall119> mhr3: xev gives me this when I hit 'Alt': <mhall119> KeyPress event, serial 38, synthetic NO, window 0x5800001, root 0xc6, subw 0x0, time 5671354, (108,88), root:(1284,140), state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False <mhall119> ClientMessage event, serial 38, synthetic YES, window 0x5800001, message_type 0x146 (WM_PROTOCOLS), format 32, message 0x144 (WM_DELETE_WINDOW) <mhr3> i suppose it doesn't do that on the guest session? <mhall119> haven't tried it on guest yet <mhall119> once again, guest is fine, so another problem on my user <mhr3> dconf is fun, right? :) <mhall119> oh yeah <mhall119> at least I've gotten it partly working agian without re-installing <mhall119> linux FTW <mhall119> seriously though, dconf is beginning to look like the windows registry #ubuntu-unity 2012-09-02 <mhr3> you should tell that to ryan :P <mhall119> ok, I'm about to blow away my dconf/gconf directories <mhall119> yay, it's not closing windows anymore <mhall119> not sure what I changed, but something fixed it <bluesabre> Hello everyone. I'm trying to port the new indicator-messages back to gtk2. Is there a straightforward method to get the GtkActions from the GtkActionGroup? <gotwig> jo <ochosi> hi gotwig <gotwig> freedomrun: yeah, sup <MCR1> I fixed some deprecated warnings, maybe someone wants to review that: https://code.launchpad.net/~mc-return/nux/nux.merge-fix-deprecated-warnings/+merge/122408 :) <gotwig> hey <batteronizer> I was trying to build unity following http://unity.ubuntu.com/getinvolved/development/unity/ , but I get the error: "package 'nux-3.0>=3.0.0' not found" <batteronizer> can anyone help <batteronizer> Probably useful to mention that I did build nux #ubuntu-unity 2012-09-03 <sil2100> seb128: hi! <sil2100> seb128: as I wrote in the e-mail, strange thing with the bamf thing <sil2100> seb128: since the tarball is upladed and visible here https://launchpad.net/bamf/0.3 <seb128> sil2100, hey <seb128> weird <sil2100> But *strangely* the newly created series is not available from the home page :/ <seb128> https://launchpad.net/bamf/ doesn't list it on the right <sil2100> Indeed <sil2100> I think I need to tinker with the LP series properties <sil2100> mhr3: hi! You registered a series before, right? <mhr3> sil2100, hey, sure <sil2100> mhr3: what did I do wrong that the series I created is not visible on the main page? <sil2100> Do you have to set something explicitly? <sil2100> mhr3: ^ * mhr3 checks <mhr3> set it as development focus, changed 0.2 status to "current stable release", you should also branch the 0.2 code into a separate branch now (when it didn't have the 0.3 features, so that bug fixes could be done in that branch) <mhr3> otoh bamf was never branched according to ubuntu releases, so... :/ <mhr3> sil2100, ^ <mhr3> sil2100, seb128, btw the plan was to make 6.x libunity release with ubuntu's beta, is it ok if we bump stuff now? <mhr3> cause it's 5.96 or something atm <seb128> mhr3, wfm <mhr3> k <sil2100> mhr3: so that branch is necessary, yes? <sil2100> mhr3: works for me regarding libunity as well <sil2100> mhr3: could you branch the bamf code to 0.2? Since I don't really know how to make this fancy lp:bamf/0.2 branch <mhr3> sil2100, why is bamf tagged as 0.3.0, yet configure says it's 0.2.122? <sil2100> Oh, maybe I didn't push? <sil2100> Ah yes <sil2100> Crap, last week was horrible <sil2100> Let me fix that <mhr3> sil2100, also, none of the upstream bugs that were fix committed were changed to fix released <mhr3> at least not automagically <mhr3> which it used to do <sil2100> Yes, since there was no one to run unify this time ;) <sil2100> And I left the milestone opened <sil2100> Since all of this was so chaotic that I didn't want to close it right now <sil2100> mhr3: pushed <mhr3> sil2100, the tag needs to be moved <sil2100> Yep <sil2100> One moment... <sil2100> mhr3: it should be fine now <sil2100> mhr3: I'll change them manually now <sil2100> mhr3: the bugs - or maybe you want to wait a bit? Since I might try familiarizing with that unity thing <mhr3> $ bzr pull <mhr3> Using saved parent location: bzr+ssh://bazaar.launchpad.net/%2Bbranch/bamf/ <mhr3> No revisions to pull. <mhr3> Conflicting tags: <mhr3> 0.3.0 <sil2100> Strange, I overwrote the tags <mhr3> do i need to pull --overwrite? <mhr3> hmm, that worked <sil2100> I think so - although hm, now that I think of it, does bzr enable moving of tags without overwriting them? <sil2100> Since my bzr-foo is still weak <mhr3> like bzr tag --force? <sil2100> Yes, if I would do a bzr tag --force 0.3.0 and then push it to the remote repo, would it move the tag without me forcing --overwrite-tags ? <mhr3> if you used push --overwrite, it's not surprising that i had to pull overwrite <mhr3> afaik tag --delete and then tag again shouldn't require overwriting <sil2100> That's what I did actually... <sil2100> Strange that you had to overwrite during pull <mhr3> indeed <mhr3> but whatever, i didn't have half-finished branch <sil2100> Sorry about tha <sil2100> t <mhr3> nothing to be sorry about, i guess bzr is just being picky <sil2100> Shit, I did the same thing with nux, grrr <sil2100> Or wait, I think Timo put the tags on <sil2100> ANyway, need to fix that up <seb128> sil2100, mhr3: please guys no --overwrite that breaks all the mergers, distro tools, etc which default to pull and not pull --overwrite <sil2100> mhr3: what would be the best way to move a tag? bzr tag --delete, bzr tag and bzr push ? <sil2100> seb128: I just was doing --override-tags if anything <mhr3> hmm, seb128 has a point, next automerge to bamf will fail <sil2100> Overwriting tags? <sil2100> Ah, right <sil2100> Ok, hm, how to fix this now - maybe I'll bring back the tag to the previous version? <sil2100> But then the commit with the version bump won't be around <mhr3> i guess the branch signature changed already, the only way to revert it is to push --overwrite the original branch <mhr3> although i'm just guessing <sil2100> mhr3: do you have the original branch somewhere? <mhr3> no, i --overwritten it a moment ago <sil2100> Ok, so officially I broke the mergers today <sil2100> Great <sil2100> hm hm <mhr3> at least you didn't do it last week :) <sil2100> Yeah, great ;p <sil2100> Maybe if I tag the same commit, it'll get fixed, right? <mhr3> no idea.. #bzr? <sil2100> Since only the tag is a conflict, and it should be related to the commit it points to <sil2100> Ok, so it seems we can re-add the tag at the old place and it will be te same then <sil2100> mhr3: but do we want that actually? Since the tag was wrongly placed anyway... <sil2100> mhr3, seb128: maybe we can do bzr pull --overwrite-tags once in the mergers to fix those? <mhr3> from upstream pov - no, from unbreaking distro tools pov - yes <seb128> not sure, but the merge is only one place you might have broken <seb128> --overwrite should be banned from such public projects... <mhr3> sil2100, perhaps ask #bzr people if there's a way to move tag without it causing this problem? <mhr3> maybe with a dummy commit or something <sil2100> mhr3: waiting for an answer <sil2100> seb128: ok, I'll put the tag back <seb128> sil2100, thanks <sil2100> seb128: should be as it was before <seb128> sil2100, great, thanks <sil2100> seb128: we would need 2 branches for precise merged, for renaming geis <sil2100> seb128: who should I poke about this? <seb128> sil2100, Didier when he's back wednesday <seb128> I don't have time to deal with precise geis stuff this week with beta1 <sil2100> seb128: is there anyone else I could ping about this before that time? <seb128> well, me I guess <seb128> what's the issue? <seb128> is that only vcs merges to do? <seb128> or is that sponsoring and uploads? <sil2100> For now only a vcs merge <sil2100> Since we'd need to have the packaging change uploaded so that we can merge in the code changes <sil2100> hmm, but I need to re-do the branch though <sil2100> Since Francis added some quilt patches <seb128> sil2100, just tell me what to merge where and I will run the command <OwaisL> Hi everyone, has the messaging menu API changed in Quantal? I can see we have libmessagingmenu and after latest updates everything but empathy is missing from the messaging menu <gotwig> hello <gotwig> unity scope devs here? <gotwig> would be pleased to know if if self.scope.get_filter('appetizers'): <gotwig> baseurl = "http://www.chefkoch.de/rs/s0g2/%s/Vorspeisen-Rezepte.html" does work in a scope file. Seems it does not. What do I need to do, so I can check if a filter is active, in a scope? * gotwig is afk <gotwig> unity scope devs here? <gotwig> I have questions regarding using filters.. <gotwig> unity scope/lens devs available? <seb128> gotwig, wrong day,time I guess, it's late for anything but the U.S and it's an holiday in the U.S today <gotwig> and here in Germany, too :/ <seb128> gotwig, davidcalle or mhr3 when they are around (european hours), or maybe mhall119 can help you <gotwig> I wrote David Calle a message on GTalk <seb128> he's maybe not around...? <gotwig> yeah, he gets it as an Email I guess <gotwig> I am working on my cooking lens <gotwig> First filters, than previews ;P <gotwig> I have time, till 12.10 ^^ <gotwig> around 230,000 recipes are searchable, I guess <gotwig> even some specialized things for Netherlands, Germany <seb128> nice <gotwig> yip.. <gotwig> Germany got 200,000 recipes <gotwig> lol <gotwig> Germans like to cook really often <gotwig> night 2 all #ubuntu-unity 2012-09-04 <gotwig> hey <gotwig> scope devs here? <tsdgeos> should i need to restart unity after changing the "key to show hud"? <gotwig> tsdgeos: yes <tsdgeos> doesn't work here on quantal :/ <gotwig> tsdgeos: you do something wrong :O <gotwig> tsdgeos: try to restart your pc <tsdgeos> gotwig: did that already 4 minutes ago <tsdgeos> didn't help <gotwig> tsdgeos: :( <MCR1> tsdgeos: There are some problems with hardcoded Unity keys, but changing Alt *should* work. Please file a bug report if it doesn't. <tsdgeos> MCR1: bug filed already <tsdgeos> already = a few minutes ago <MCR1> tsdgeos: Ah, see it - thx :) <gotwig> unity scope/lenses devs here? <MCR1> gotwig: I would like to help, but never did that be4 ;) <sil2100> seb128: hi! How is your workload today? <seb128> sil2100, hi, okish so far, want to change that right? ;-) <sil2100> seb128: ... ;) <seb128> sil2100, what do you need? <sil2100> seb128: actually fginther will ping you about this in a moment ;) <fginther> seb128, heh. I have the nux packaging changes ready. This is for the libgeis rename <fginther> seb128, sil2100, my apologies for my process confusion <fginther> seb128, changes are here: https://code.launchpad.net/~sil2100/unity/precise-geis-rename <sil2100> seb128: and I have the unity packaging changes (based on fginther's branch) <fginther> seb128, oops wrong one (that ^^ is for unity). Here's nux: lp:~fginther/nux/precise-libgeis-rename-patch <sil2100> seb128: if you ACK those and push them for us, we'll be able to accept the respective unity and nux source changes <sil2100> It's for precise if anything <sil2100> So target branches are lp:~ubuntu-desktop/unity/precise and lp:~ubuntu-desktop/nux/precise <seb128> sil2100, do you have a merge request for it? <sil2100> seb128: yes, there are - one moment <sil2100> https://code.launchpad.net/~fginther/nux/nux-2.0-libgeis-rename/+merge/121653 <- here's for nux <sil2100> https://code.launchpad.net/~fginther/unity/unity-5.0-libgeis-rename/+merge/121654 <- here for unity <sil2100> Francis prepared everything <sil2100> The unity branch got approved by Sam, but the packaging changes are needed first <alucardn1> Hello, are there any guidelines to design icons for an app-indicator??? <gotwig> davidcalle: hey <MCR1> bschaefer: Hi :) Can it be that Jenkins does not have any drive space left ? https://jenkins.qa.ubuntu.com/job/automerge-compiz-core/120/console <bschaefer> MCR1, hmm it looks like that haha <bschaefer> MCR1, jenkins just seems to have problems atm.... :( <MCR1> bschaefer: His picture calms me down at least :-D <bschaefer> MCR1, wait whos picture? I've always imagine Jenkins as some sort of god that needs sacrifices to stay happy <MCR1> bschaefer: Scroll down to the end of the page I posted above, he rather looks like a waiter serving the FAILURE ;) <bschaefer> MCR1, wth I don't have a picture....I see a tiny icon under my tab <MCR1> Hmm, strange -> maybe it is better you imagine the god that needs sacrifices - I do not want to destroy your vision ;) <bschaefer> MCR1, haha, jenkins just seems to hate merges sometimes <MCR1> http://imageshack.us/f/546/dashboardjenkinschromiu.png/ <bschaefer> MCR1, o haha, I just have the ubuntu image <MCR1> bschaefer: IIRC you had an idea to reduce the code duplication of the shortcuts/help display of Unity (almost the same code in unityshell.cpp and StandAloneShortcuts.cpp) <bschaefer> MCR1, hmm I hadn't spent time thinking of a great way but it needs to be done <bschaefer> since not all the shortcuts are derived the same way... <MCR1> Yes - that is bugging me also - but I have struggle to find where the unity-specific shortcuts are even defined in the code... <bschaefer> as we should be able to have a *.h file with a static st33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abstring [] that we can loop through <bschaefer> instead of having *.push_back(<huge line>) 50 times... <MCR1> yes <bschaefer> hm soo we know the hard coded strings/tips <bschaefer> looking through that would be easy <bschaefer> then we need that to line up with the shortcuts and buttons to push... <MCR1> I would like to make the hardcoded shortcuts configurable via CCSM Unity plug-in <bschaefer> which will take a bit of looking/thinking to find a nice pattern <MCR1> that would solve a lot of problems <bschaefer> hmm yeah it would, I haven't really spent much time looking at shortcuts but im guessing there is a reason they are hard coded <MCR1> for some maybe, for others I am not sure <MCR1> Super and Alt are special modifier keys for example, but then those are already configurable... <bschaefer> we could also have an array for short cuts....shortcut_type[COMPIZ] ... yeeah I need to really look more at the code then just ramble :) <MCR1> I looked at the code and searched a bit, but I just did not find where those definitions exactly take even place... <bschaefer> MCR1, well im talking more about encoding the hard coded keys into an array <bschaefer> which we can line up with another array <bschaefer> shortcuts[0] = {"Shortcut tip here, shortcut_type[COMPIZ] } <bschaefer> and add more <bschaefer> so we can just loop through in the 2 files <bschaefer> shortcuts[0] = {"Shortcut tip here" , shortcut_type[COMPIZ] } <MCR1> bschaefer: First we should make them all COMPIZ shortcut types, no ? <bschaefer> MCR1, no we can say <bschaefer> shortcut_type[UNITY-...] <bschaefer> something <bschaefer> maybe the hardcoded value * bschaefer should really look at the code haha <MCR1> If you find the place where the hardcoded keys are defined shout out loud, please ;) <bschaefer> MCR1, I will, but Im talking about a work around for that for now :) <MCR1> I already made the strings static constants in unityshell.cpp, maybe this also helps... <bschaefer> soo there are up to 7 different parameters for the shortcuts....{ "Shortcut Owner", "", "", "Shortcut Tip", shortcut33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abOMPIZ/HARDCODED, "unityshell", "show_launcher"} <bschaefer> but they are sometimes variable ... <bschaefer> but we want to be able to loop through all of those in a nice loop in some other header file... <MCR1> some have (Tap) or (Hold)... <bschaefer> yeah <bschaefer> but we can have an array hold this <bschaefer> a[] = {"", "_(Tap)", ....} <bschaefer> then we define enums <bschaefer> NONE = 0 = "" <bschaefer> TAP = 1 = "_(Tab)" <bschaefer> im not sure if iam making any sense atm haha <MCR1> Sure, but we should make it easily editable, so that future changes would be easy... <bschaefer> that is why everything would be in 1 header file, with a few different arrays and everything should be easy to edit (at lease what iam thinking) <MCR1> Maybe one day the shortcuts displayed will show all available shortcuts on several pages or other features might get added... <bschaefer> MCR1, yeah, but it would be better to reduce having almost 2 exact copies of code into 1 then go from there... <bschaefer> idk though <MCR1> Also I've seen a bugreport complaining about deleted shortcuts being displayed wrong <bschaefer> haha...yeah <MCR1> bschaefer: Ofc, I agree 100% with you <bschaefer> MCR1, I do wish things weren't hard coded though... <MCR1> Yes, I will try to fix that once my understanding is big enough. <MCR1> The commit which added the configurable Alt key for example would be a big help... <bschaefer> MCR1, yeaah, I don't know how it is done atm and would have to do some digging as well <MCR1> But all visual bzr tools do not work here on Quantal... <bschaefer> MCR1, hmm really maybe qbzr? <MCR1> qbzr for example is broken <MCR1> I did not file a bbug report yet <bschaefer> aww <bschaefer> well do a bzr log | grep "stuff" <bschaefer> and maybe you can get lucky@ <bschaefer> ! <MCR1> yeah, thanks for the tip. I'll try <bschaefer> "stuff" would be like ALT or something <MCR1> :) <bschaefer> np :) #ubuntu-unity 2012-09-05 <sil2100> seb128: ping! :) <seb128> sil2100, hey <sil2100> seb128: did you find a moment to look at those precise distro branches for nux and unity? <sil2100> seb128: for the geis rename <seb128> sil2100, no <seb128> sil2100, but didrocks is back so maybe he can help :p <sil2100> didrocks: boing <seb128> sil2100, to be fair I couldn't care less about renaming stuff that are working in stable series atm <sil2100> Well, it's a bit more tricky <seb128> sil2100, still trying to deal with beta1 work and stuff that aren't working <didrocks> sil2100: won't be today anyway, still catching up on emails <didrocks> and agreed with seb128, I think you have any gsettings transition regression to polish before we get to that :) <sil2100> didrocks: working on that as well ;) <tedg> mhall119, Is there a guide somewhere on making a new account type for UOA? <mhall119> tedg: not that I know of, kenvandine might know though <kenvandine> tedg, not really <kenvandine> best to ask in #accounts-sso <kenvandine> but not until tomorrow <kenvandine> late for those guys now <tedg> But, I wanna know now! :-) <tedg> Okay, I'll see about it tomorrow. <tedg> Thanks kenvandine <kenvandine> np <sil2100> MCR1: ok, I think I found a fix <sil2100> https://code.launchpad.net/~sil2100/compiz/fix-pkgconfig/+merge/122946 <MCR1> sil2100: YEAH \o/ <sil2100> See you tomorrow! #ubuntu-unity 2012-09-06 <MCR1> sil2100: Good morning :) Thanks for fixing Compiz yesterday - fixes are landing again 8-) <MCR1> sil2100: But Unity still is blocked ? <MCR1> duflu: Hi :) Have you seen: https://code.launchpad.net/~mc-return/compiz/compiz.merge-replace-defines/+merge/122865 ? <duflu> MCR1: Yes I know about it. Too busy to get to looking at it yet <MCR1> duflu: Ah, okay - but I hope the general direction of replacing #defines is okay for you too... <MCR1> duflu: I've read a survey that said that 9.7 out of 10 duflus like #defines being massaged to static constants of standard variable types ;) <Mirv> staging looks like fixed at least now, and unity also has rebuilt against compiz <Mirv> I re-pushed all the unity branches that got rejected to approved again, but indeed it does not look like they'd still be going forwards really <Mirv> or then it's just slow, also the compiz stuff took quite many hours to start merging, and I only pushed unity two hours ago <MCR1> Mirv: That are good news :) Hope it will soonish start to merge. Thx. <sil2100> MCR1: it's still blocked? Will have to check that later! Morning btw/ <Mirv> sil2100: the merger isn't rejecting anything anymore regarding unity, so it maybe just slow (compiz was only fixed and built 3 hours ago) <Mirv> so now the next checks merger will do should be successful <MCR1> sil2100: I do not know exactly, because I do not see this info (it would be cool if that info could be added to the launchpad code review page), but Compiz merged, then stopped, while Unity was not merging anything... <MCR1> For a newbie like me this is exciting - will Jenkins do it this time or... :-D <Mirv> well it's exciting for everyone ;) <MCR1> hehe <sil2100> MCR1: can you point me to a recent merge that failed? <MCR1> sil2100: Not really, I think they just stopped... like on hold. <MCR1> sil2100: They are still in the "ready to land" queue... <sil2100> huh <MCR1> sil2100: 6 hours ago, 5 commits were merged into lp:compiz, the last commit merged into lp:unity was 19 hours ago... <Mirv> the unity couldn't have continued until the 5 commits committed to lp:compiz went in and also built, which happened 3h ago <Mirv> so I'm just wondering if it takes time for lp:unity to continue (no rejects so far) <MCR1> idk <Mirv> sil2100: do you think that's possible? <MCR1> sil2100: This lp:compiz merge failed 6 hours ago: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix-URLs/+merge/122632 <MCR1> sil2100: The Jenkins console says Finished: SUCCESS - but did not merge it then... <MCR1> sil2100: But unity-merger says that the same console report shows an error and refuses to merge, see: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix-URLs/+merge/122632/comments/264474 <MCR1> sil2100: Maybe that helps... <sil2100> MCR1: the merge you posted is one of those strange cases where the merger fails by success <MCR1> sil2100: yes <didrocks> sil2100: hey hey, you are around! :) <sil2100> didrocks: hi! Yes! Battling with some things right now <didrocks> sil2100: can I give you another request for today? <sil2100> didrocks: yes, please ;p <TheMuso> Hey folks. What is the likelyhood of getting bug 1023542 expedited? An at-spi2 package update is pending, and I can't update it until this bug/branch is merged upstream, so it can be cherry-picked into the quantal unity package... <ubot5> Launchpad bug 1023542 in unity (Ubuntu) "[a11y] Unity and unity-panel a11y initialization need to be ported to atk-bridge library" [Undecided,In progress] https://launchpad.net/bugs/1023542 <didrocks> sil2100: so, did you read my email yesterday about branches without FFe? <didrocks> sil2100: the 2 bugs <didrocks> sil2100: can you poke the release team and watch closely about new features introduced without FFe acked <didrocks> sil2100: because right now trunk is unreleasable <didrocks> sil2100: my take 2 is that I saw Mirv's branches for compiz have been merged, did you finish your part for migration/default values and can we cherry-pick that and upload today? <sil2100> didrocks: will try! <didrocks> thanks <didrocks> keep me posted <didrocks> sil2100: you did notice that the merger still doesn't merge everything on unity? <sil2100> didrocks: I see that it didn't even fail merging - it just doesn't merge unity <sil2100> didrocks: I'm trying to poke Martin about it <didrocks> sil2100: right, it's just someway stalledâ¦ <sil2100> didrocks: since I actually wanted to know if my yesterday's fix actually fixed all problems <didrocks> what was it btw? <didrocks> oh right <didrocks> the .pc file <tsdgeos> how am i supposed to start "unity" properly? <tsdgeos> unity --replace doesn't seem to give me much <tsdgeos> i.e. i don't have a launcher, etc. <Mirv> tsdgeos: unity imples --replace, no need to specify it. some problem if launcher isn't shown, maybe pastebin output of unity --debug.. <sil2100> tsdgeos: if the launcher and panel are not visible it means that the unityshell plugin is not loaded probably <tsdgeos> hmmm <tsdgeos> maybe i broke something while compiling <tsdgeos> let me recompile <tsdgeos> Mirv: http://paste.ubuntu.com/1188757/ not much besides the complaint about the panel service <Mirv> tsdgeos: 12.10 or 12.04? hmm, maybe the --debug wasn't a good idea, try also without <Mirv> tsdgeos: without I get something like this (start of output): http://pastebin.ubuntu.com/1188760/ <Mirv> on 12.10 <Mirv> so you should see Backend/Integration/Profile at least <Mirv> Profile shoud be unity, Backend should be gconf (on 12.04) or gsettings (on 12.10) <tsdgeos> Mirv: 12.10 <Mirv> with --debug I don't get Unity running, funnily.. <Mirv> (ok, now it ran with --debug as well) <tsdgeos> interesting <tsdgeos> yep without debug works <tsdgeos> tx :D <Mirv> hmm :D <tsdgeos> Mirv: any hints on compiling compiz from lp:compiz sources? if i do the typical, cmake, make, make install i end up with unity not being loaded, seems like it does use ini backend instead of gsettings and everything goes downhill from there <sil2100> That's why I'm always using packaging for testing lp:compiz <tsdgeos> right <tsdgeos> but i want to develop <tsdgeos> so i need to compile stuff <tsdgeos> and compile the packages all the time <tsdgeos> is a bit of a pain <tsdgeos> being doing that <tsdgeos> but each time i want to change a line have to wait like 5 imnutes to get the deb files recompiled <tsdgeos> does note scale much <sil2100> hm, it's been a while since I last used lp:compiz directly for testing, so I'm not sure if I can help you here - in the past it was easy, just the 3 steps as already mentioned <dandrader> tsdgeos, you will probably have to compile lp:unity and lp:nux as well. Just to make sure you're everything in sync <dandrader> tsdgeos, check this http://askubuntu.com/questions/28470/how-do-i-build-unity-from-source <tgm4883> Is it possible to open a unity preview from inside another unity preview (nested previews?). I've been testing, but it just seems to close the preview whenever I click a button in a preview rather than just go to another preview <MCR1> tsdgeos: https://answers.launchpad.net/compiz/+question/203490 <tsdgeos> dandrader: MCR1: tx, will have a look <MCR1> tsdgeos: Your help is appreciated, there is enough to do ;) <tsdgeos> well, let me get stuff compiling first :D <MCR1> tsdgeos: A trick I use often if it is just a plug-in I am fixing: simply copy the 2 files (nameoftheplugin.xml file in build/generated and the .so file from build/plugins/nameoftheplugin/nameoftheplugin.so to the respective .compiz-1 directories in ~) <MCR1> tsdgeos: After compiling lp:compiz ofc <tsdgeos> yep <tsdgeos> actually compiling and overwriting a plugin worked <tsdgeos> it's just the main thing that somehow doesn't want to work <MCR1> :) <MCR1> duflus solution *should* work <tsdgeos> back in a sec <tsdgeos> my window manager setup kind of broke, need to logoff and fix some stuff <sil2100> didrocks: small report (sorry that so late) <didrocks> sil2100: I was just about to ping you! <didrocks> :) * MCR1 is listening interested also :) <sil2100> didrocks: I pushed the migration branch (took so long since we were checking some other things in the meantime, like the merges and SRUs) - will request a merge soon for comment <sil2100> didrocks: regarding the two FFe's <sil2100> didrocks: the gtk decorator has been ACKed, but the XIM nux one needs discussion still <didrocks> sil2100: bug #1042323 <sil2100> didrocks: I have been asked by Daviey to discuss it on #ubuntu-desktop <ubot5> Launchpad bug 1042323 in Compiz "[FFE] Port GTK Window Decorator to GSettings" [High,Confirmed] https://launchpad.net/bugs/1042323 <didrocks> I don't see a ack? <didrocks> sil2100: yeah, we discussed about it a couple of hours ago <didrocks> with Daviey <sil2100> didrocks: it'll get formally ACKed in a moment <didrocks> sweet :) <didrocks> sil2100: can you make sam aware once done? <didrocks> sil2100: they, we can pack this up with the migrations part <sil2100> didrocks: regarding the XIM branch... well, I would *personally* like to have it, since this way we'll have time to test such things till 13.04 <didrocks> and release a package tomorrow <sil2100> didrocks: ACK <sil2100> ;) <didrocks> sil2100: 12.10 is not a test bed for 13.04 :) <didrocks> bet* <sil2100> I know, but it still would open up Nux for many many input methods <sil2100> Right now we only have the standard IM and ibus, which might be a bit problematic <didrocks> right, but now that the FF target is done, I want to know what the test coverage is and how this can impact existing code <sil2100> didrocks: right, we'll need bschaefer to get online for that <didrocks> sil2100: well, it wasn't problematic enough to ship only ibus support in 11.04, 11.10, 12.04 <didrocks> so, what changes? <sil2100> Sure, it's not a regression, but it doesn't mean it was supposed to be like this always, since this is not intended behavior, right? <didrocks> depends on who you ask :) <sil2100> It's maybe not *necessary*, ok <didrocks> GNOME is going to support only ibus <sil2100> Ouch <sil2100> I wouldn't like that <sil2100> Really <didrocks> so I'm just wondering what the benefit/risk to just wait for enabling that for 13.04 and not 12.10 <didrocks> if the benefit is greater than the risk, fine <didrocks> otherwise we should reconsider :) <sil2100> True true, hm hm <sil2100> THe diff is big, I would also like to ask some questions related to this branch <didrocks> yeah, better to check beforehand <didrocks> giving all assets to the release team <didrocks> so that they can decide <MCR1> sil2100: Are you aware that ~1h ago r2658 in Unity was merged, but now merges seem to have stopped again ? <sil2100> MCR1: ah, patience please ;) <sil2100> MCR1: but it should be alright now <MCR1> sil2100: :-[ <bschaefer> MCR1, im awake now! <MCR1> Yeaj <MCR1> bschaefer: If you are bored: https://code.launchpad.net/~mc-return/unity/unity.merge-remove-unused-variables/+merge/122940 ;) <bschaefer> MCR1, im never bored :), Ill take a look at that later (I have some other review's to fix atm ) <bschaefer> MCR1, thanks though! <bschaefer> MCR1, actually it is really small... <MCR1> bschaefer: hehe <bschaefer> 26 - CompWindow* w, *oldPrev, *oldNext; <bschaefer> 27 + CompWindow* w; <bschaefer> what happened to old? <bschaefer> and Prev and Next? unused? <MCR1> they just got assigned NULL, but were not used <MCR1> to my understanding <bschaefer> MCR1, cool, let me just look through that really quick :) * MCR1 is recompiling to make sure also (40%)... <didrocks> sil2100: https://bugs.launchpad.net/unity/+bug/761155 needs a FFe <ubot5> Ubuntu bug 761155 in unity-2d (Ubuntu) "[launcher] All launcher icons should be moveable except trash and BFB" [Medium,Triaged] <didrocks> and it's also landed into trunk :/ <didrocks> sil2100: can you have a review from Daviey/the release team please? <didrocks> sil2100: this is between a bug fix and a feature btw (as it's part 2 of the work landing) <didrocks> but the change is large <sil2100> didrocks: will take care of that too! <sil2100> didrocks: and the XIM issue <didrocks> thanks! <didrocks> and keep watching the merger please, to ensure you spot them and go to people :) <mhall119> mhr3: hey, would it make sense to pre-fetch the next screenshot when doing previews? Waiting for images to load makes it feel slow <mhall119> or does it already do that, and I'm just flipping through too fast <mhr3> mhall119, no, and not gonna happen for 12.10 sorry <mhall119> that's fine, it's still an awesome feature <mhr3> mhall119, which lens is this slow for you though? <mhall119> mhr3: applications <mhr3> ah, right grabs images from web <mhr3> mhall119, but i'm pretty sure people on mobile connections are happier went it doesn't do any pre-fetching <mhall119> I'd think just +1 wouldn't be that big of a deal <mhall119> you'd never load more than one more than you wanted <mhall119> mhr3: on a side note, what's a good python example of using the previews api? <mhr3> lp:unity-lens-sample <didrocks> mhr3: didn't you eod a while ago? (just checking ;)) <mhr3> didrocks, i did, but actually i'm just putting shoes on and am out <didrocks> ah, it's not mhr3bot then :) <didrocks> mhr3: run run :) <mhall119> thanks mhr3 <mhr3> didrocks, why do you think my bots can't run? ;) <mhr3> didrocks, they're very advanced <mhr3> but really /me out <didrocks> mhr3: I don't doubt about it! <didrocks> mhr3: good night :) <sil2100> didrocks: will you find time for unity SRU precise branch analysis? ;) <didrocks> sil2100: not tonight TBH, but bring them on, I can have a look tomorrow morning <sil2100> didrocks: ok, as long as we'll be able to release unity tomorrow, I'm fine with that ;) <didrocks> well, it will be in -proposed <didrocks> then, someone has to accept it there <sil2100> didrocks: for now I need someone to upload branches to lp:ubuntu/unity and nux <sil2100> didrocks: since we're blocked on those <didrocks> what is blocked? new build-dep? <sil2100> didrocks: https://code.launchpad.net/~fginther/nux/precise-libgeis-rename-patch <- nux <sil2100> THe geis rename <sil2100> https://code.launchpad.net/~sil2100/unity/precise-geis-rename <- unity <didrocks> this is for precise <sil2100> didrocks: since we need some modifications in trunk too, but we need packaging changes first <sil2100> Yes <didrocks> how come you want that to lp:ubuntu/unity and lp:ubuntu/nux <sil2100> Preparations for Unity SRU <sil2100> Aaaah, sorry! <didrocks> which are for quantal? <sil2100> ;) <sil2100> ~ubuntu-desktop/unity/precise I meant, eh <didrocks> why debian/patches/02_libgeis_rename.patch? <didrocks> and nothing in unity? <didrocks> there is no utouch-* ref in unity? <didrocks> in that case, we shouldn't build-dep on it, right? <sil2100> didrocks: no no, let me explain <sil2100> didrocks: there is, but all those changes are made in trunk <sil2100> didrocks: upstream <sil2100> didrocks: the nux patch is necessary because nux build system is broken <didrocks> broken? <sil2100> didrocks: yes - it includes 'configure' in the tarball, and doesn't generate a new one from configure.am automatically it seems <didrocks> well, that's normal <didrocks> you mean, there is no autoreconf, right? <sil2100> I think so <didrocks> sil2100: I want first to see the code in nux upstream trunk <didrocks> and rerolling a tarball <didrocks> I think it worthes it <sil2100> didrocks: to get it merged in, we need to change the build-deps change <sil2100> One moment, I'll give you the MRQs <sil2100> https://code.launchpad.net/~fginther/unity/unity-5.0-libgeis-rename <sil2100> I mean: <sil2100> https://code.launchpad.net/~fginther/unity/unity-5.0-libgeis-rename/+merge/121654 <sil2100> https://code.launchpad.net/~fginther/nux/nux-2.0-libgeis-rename/+merge/121653 <sil2100> TO anyone interested: https://code.launchpad.net/~sil2100/unity/keybindings-migrations/+merge/123117 <didrocks> argh seb128 had a lock <didrocks> on the bzr repo <didrocks> let me break it <didrocks> sil2100: unity branch: it diverged from lp:~ubuntu-desktop/unity/ubuntu <sil2100> You mean, lp:~ubuntu-desktop/unity/precise I think ? <sil2100> See you tomorrow everyone <Oranger> Hello, sorry to kill this silent but I want to know if it's possible to compile the 6.0 branch of Unity into precise ? <MCR1> bschaefer: Are you still here ? <bschaefer> MCR1, yup <MCR1> Do you remember my launcher hiding although the mouse was over the launcher problem ? <MCR1> The one I posted the video about... <MCR1> The one you could not reproduce... <bschaefer> MCR1, yeah <bschaefer> do you know how to reproduce it? <MCR1> No, but to my understanding the code says that it should hide if the mouse is not moved after reveal... <MCR1> which is wrong <MCR1> I do not know of any case where the launcher should hide although the pointer hivers over it... <bschaefer> MCR1, if the mouse is over the launcher at all it should never hide (If set to autohide) <bschaefer> until the mouse is moved away <MCR1> bschaefer: Please zstrickland@example.net line 150+ * bschaefer takes a look <MCR1> thx <MCR1> to my understanding it forces the user to move the mouse after reveal to keep the launcher open <MCR1> which is also what the comment says <MCR1> and which I experienced quite often in several installations, but noone could reproduce it and it would not happen in a guest session... <bschaefer> MCR1, well comments are not always write. The code is always right. It looks like it gets set on line 58 <MCR1> the code does the same like the comment, no ? <bschaefer> well it looks like it sets that Quirk to true when the launcher is revealed... <bschaefer> from pressure <bschaefer> but then I have to see where MOUSE_OVER_LAUNCHER is set <bschaefer> MCR1, which gets set in the Launcher...which gets set when the mouse is inside the launcher <bschaefer> MCR1, when a mouse_enter is emited, which should happened when the pressure is large enough to reveal the launcher <bschaefer> MCR1, and this it is set to false when mouse_leave is emited <bschaefer> which would cause the launcher to hide <bschaefer> so it should know that the mouse is over the launcher when it activates the launcher with pressure....and the mouse_enter signal gets emited <bschaefer> the bug could be that Nux doesn't emit the mouse_enter when the launcher opens up...but I can't get it to do that <bschaefer> though I could be missing something :) (I haven't really devoured that part of the code yet ) <MCR1> to me it says: if the launcher is hidden show it if visibility is required or the mouse revealed it (REVEAL_PRESSURE_PASS) else (if it is already revealed) check (MOUSE_MOVE_POST_REVEAL) then show it when _should_show_quirk is true or the mouse is over the launcher... <MCR1> the check for (MOUSE_MOVE_POST_REVEAL) should be completely removed <bschaefer> MCR1, well te best way to check is to add print statments in :) <bschaefer> comment it out and see what happens <MCR1> MOUSE_OVER_LAUNCHER check should be enough to determine this <MCR1> well, I could not test the code at the moment... <bschaefer> hmm #ubuntu-unity 2012-09-07 <bschaefer> Ill have to look at the code somemore...thought it could be very easy that I missed something when I removed a bunch of that code <MCR1> but do you understand my arguing ? <bschaefer> yeah <MCR1> I could not think of any situation where a hovering pointer over the launcher should still trigger a hide, it should not matter at all if the mouse is moved post reveal or not so long as the pointer is over the launcher which is checked there anyway... <bschaefer> MCR1, hmm the biggest thing is I just dosn't happen like that on my build... <MCR1> hmm, yeah - that is the strangest thingie... <bschaefer> MCR1, I think why it is there <bschaefer> MCR1, is move the the mouse over where the launcher would show... <bschaefer> Then open the dash <bschaefer> then close the dash <bschaefer> and the launcher hides, with the mouse over <bschaefer> it <MCR1> I could reproduce it on several machines and this hunts me for since Precise alphas <MCR1> if you close the Dash, but the pointer still hovers the launcher it should imho not hide either <bschaefer> MCR1, hmm well make a bug :) <bschaefer> which then the design team can make the decision <bschaefer> (though since it is programmed it I would think they already did) * MCR1 is searching for his video-evidence :-D <bschaefer> MCR1, well make two bugs, one for that video you have <bschaefer> and when the mouse is over the launcher when the dash opens <MCR1> bschaefer: Too tired today, maybe I'll attack that tomorrow ;) <bschaefer> MCR1, alright, cool. Have a good night :) <bschaefer> MCR1, also 1307 neil.pa | if (GetQuirk(MOUSE_MOVE_POST_REVEAL)) <bschaefer> so it was added a while ago <MCR1> 1207 ? <MCR1> *1307 <bschaefer> rev 1307 <MCR1> ah <bschaefer> like we are on 26xx or something like that <MCR1> line 58 is also strange... <MCR1> tomorrow... gn :) & thanx a lot for your patience with me, bschaefer ;) <mhr3> bilal, ping <MCR1> JohnLea: Hi :) I would need your input here: https://bugs.launchpad.net/unity/+bug/1047232 <ubot5> Ubuntu bug 1047232 in Unity "Unity Launcher Autohide Behavior: The Launcher should never autohide if the mousepointer hovers over it" [Undecided,New] <MCR1> duflu: Mornin' :) Do you have any comments on https://code.launchpad.net/~mc-return/compiz/compiz.merge-replace-defines/+merge/122865 ? <duflu> MCR1: Sorry, out of time this week <duflu> In a mad rush this afternoon <MCR1> mad rushes can be productive, so I will stop nerveing ;) <MCR1> *nerving <JohnLea> MCR1; that bug looks like a dupe of bug #745707 <didrocks> MCR1: see the MP, you are breaking one use case <ubot5> Launchpad bug 745707 in unity (Ubuntu) "Launcher - Launcher should never autohide when the cursor is positioned over the Launcher (e.g. When a spread ends)" [Medium,Triaged] https://launchpad.net/bugs/745707 <didrocks> JohnLea: ^ <didrocks> JohnLea: this will break the "super" key case <JohnLea> didrocks; how will bug #745707 break the "super" key use case? <ubot5> Launchpad bug 745707 in unity (Ubuntu) "Launcher - Launcher should never autohide when the cursor is positioned over the Launcher (e.g. When a spread ends)" [Medium,Triaged] https://launchpad.net/bugs/745707 <didrocks> JohnLea: see my comment on https://code.launchpad.net/~mc-return/unity/unity.merge-fix-launcher-should-never-autohide-when-pointer-hovers-it/+merge/123231 <JohnLea> didrocks; I don't think what you described in bug #123231 is that much of a problem, however well spotted and I think it would be better if we could add "This only applies when the Launcher is revealed by a pointer action, if the Launcher is revealed by a keyboard shortcut it should auto-hide as normal even if the mouse finds itself over the Launcher" However this last statement is nice to have, not essential, and should not block this fix from l <JohnLea> anding IMHO <ubot5> Launchpad bug 123231 in evolution-data-server "evolution-data-server-1.12 crashed with signal 5 in g_logv()" [Critical,Fix released] https://launchpad.net/bugs/123231 <JohnLea> didrocks; I'm updating the description of bug #745707 <ubot5> Launchpad bug 745707 in unity (Ubuntu) "Launcher - Launcher should never autohide when the cursor is positioned over the Launcher (e.g. When a spread ends)" [Medium,Triaged] https://launchpad.net/bugs/745707 <didrocks> JohnLea: the bug doesn't describe it, however MCR1's fix is breaking it <didrocks> JohnLea: so the fix has to be redone, otherwise, we will have this regression <MCR1> JohnLea, didrocks: To my understanding it would fix bug 745707 <JohnLea> didrocks; ok, MCR1 can you fix it? ;-) <didrocks> MCR1: see above + my comment ^ <didrocks> MCR1: you still have that use case to work <MCR1> JohnLea: It would feel much better if the launcher would not hide in any case if the mouse hovers it, even if revealed by the Super key... <didrocks> MCR1: that was an explicit design use case <didrocks> there was more case in the past, that was removed by design <JohnLea> didrocks, MCR1; I have updated bug #745707 to include didrocks's point about keyboard shortcut triggered Launcher reveals, see bottom of the bug description. <ubot5> Launchpad bug 745707 in unity (Ubuntu) "Launcher - Launcher should never autohide when the cursor is positioned over the Launcher (e.g. When a spread ends)" [Medium,Triaged] https://launchpad.net/bugs/745707 <MCR1> I understand, but it feels unnatural if something hides if the mousepointer hovers it, no matter how it is revealed, so maybe we should re-think this design * MCR1 reading <MCR1> a long bug report... * MCR1 needs some time to read and comprehend it all... <JohnLea> MCR1; I think didrock's point is that if users are using the SUPER + NUMBER shortcut to select applications, they don't want the Launcher stuck out if their mouse pointer just happens to be in the Launcher area prior to SUPER being pressed <MCR1> JohnLea: Yes, I understand that case... <MCR1> JohnLea: Have you seen bug 1019453, btw. ? <ubot5> Launchpad bug 1019453 in unity (Ubuntu) "Unity Launcher Regression: Autohide Option makes the launcher not being used anymore, add Intellihide mode like all other docks/launchers have" [Wishlist,Incomplete] https://launchpad.net/bugs/1019453 <JohnLea> MCR1; yes I have seen it ;-) <MCR1> ^^^this would imho be the best behavior for launcher hiding... <MCR1> JohnLea: Ofc I am very interested in what you think about it also... :) <JohnLea> MCR1; I personally really liked intellihide, I always ran it, and I liked how it surfaced the tiles in my launcher when there was space, and was revealable when there wasn't. However it user tested very badly with everybody other than expert users, and when the decision was made to not have it on by default, the dev team were not willing to carry the cost of continuing to support the feature. <sil2100> JohnLea: what problems did normal users have with intellihide? <MCR1> JohnLea: There never was intellihide in Unity, but just window dodge. The difference between them is very small in terms, but very large in practical use. <sil2100> JohnLea: maybe all that was needed was a short tutorial on first ubuntu login? I think teaching people is much better than just removing complicated features - this doesn't lead to lives getting more convinient <sil2100> Progress requires learning... <JohnLea> sil2100; you should have seen it! user after user would resort to moving there windows out of the way every time they needed to access the Launcher! Most new users assumed this was how you revealed the launcher, and it was very painful to watch <MCR1> JohnLea: While dodge will hide from every window, Intellihide will just hide from active windows and automatically reveal the launcher again if other windows not touching it are active - That is a HUGE difference. <sil2100> I just feel that removing more and more useful features just because some people didn't know how to use them is a bit sad... Since its not that they didn't use it, they just didn't know how it works, right? <MCR1> JohnLea: Please do me a favor and simply install the package docky and set it to intellihide. Especially, but not only on dual screens this makes a huge difference to simple window dodge... <JohnLea> sil2100; if we require someone to pick up the documentation, or complete a tutorial in order to use something we have really failed from a ux point of view. What we want is a nice progressive learning curve, where users start off using the basic interactions, and learn the more complex interactions through usage. The issue that killed intellihide was that when it stopped being the default option the dev team didn't want to continue to carry the <JohnLea> cost of supporting the code. <JohnLea> MCR1; the problem with what you are describing is that most non-advanced users wouldn't get what was happening <sil2100> JohnLea: true, but what if we didn't require people to go through manuals or tutorials, just thinking of a way to *show* the newbie user on how to effectively use the operating system? Since anyway most non-advanced users had to learn the usage of a computer from books, courses or tutorials <MCR1> JohnLea: As I said before, there never was intellihide implemented in Unity, so no user was testing it ever... <sil2100> MCR1: there wasn't? <didrocks> MCR1: this was in the code, it was "dodge active window" <JohnLea> sil2100; there is also a UX cost to having options, just zstrickland@example.net. However in this case it was the cost of maintaining the feature that killed it. <MCR1> JohnLea: Unity-2d has intellihide, Unity-3d once had window dodge... <MCR1> Unity-2d's autohide feature acts like intellihide IIRC... <MCR1> (it is a long time ago ;)) <didrocks> MCR1: so it had it <MCR1> Unity-3d never had it <didrocks> dodge active window? <didrocks> I wrote this part of the code, I know what I wroteâ¦ :) <MCR1> Unity-2d had it until it was removed, but it was called autohide <JohnLea> sil2100; what we would like to do is to provide subtle visual cues to the user to aid discovery, some work to enable proximity effects which don't kill battery life is required to do some of these however <didrocks> MCR1: http://www.webupd8.org/2012/05/how-to-get-dodge-windows-and-minimize.html if you don't believe me <sil2100> JohnLea: there's a lot of things to consider here indeed.. <didrocks> and look at the screenshot <didrocks> there is "dodge active window" <MCR1> didrocks: This PPA was never official code - it was a remake - I never tested it myself, but it was a completely different re-implementation after Dodge was removed in Precise <didrocks> MCR1: the ppa just reverted the commit <didrocks> so not a completely different re-implementation <didrocks> MCR1: http://bazaar.launchpad.net/~unity-team/unity/branch-3.0/view/head:/unityshell.xml.in <didrocks>
{'channel': 'ubuntu-unity', 'month': 9}