| 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 | 00:00 |
|---|---|---|
| MCR1 | but do you understand my arguing ? | 00:00 |
| bschaefer | yeah | 00:00 |
| 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... | 00:02 |
| bschaefer | MCR1, hmm the biggest thing is I just dosn't happen like that on my build... | 00:02 |
| MCR1 | hmm, yeah - that is the strangest thingie... | 00:02 |
| bschaefer | MCR1, I think why it is there | 00:03 |
| bschaefer | MCR1, is move the the mouse over where the launcher would show... | 00:03 |
| bschaefer | Then open the dash | 00:03 |
| bschaefer | then close the dash | 00:03 |
| bschaefer | and the launcher hides, with the mouse over | 00:03 |
| bschaefer | it | 00:03 |
| MCR1 | I could reproduce it on several machines and this hunts me for since Precise alphas | 00:03 |
| MCR1 | if you close the Dash, but the pointer still hovers the launcher it should imho not hide either | 00:04 |
| bschaefer | MCR1, hmm well make a bug :) | 00:04 |
| bschaefer | which then the design team can make the decision | 00:05 |
| bschaefer | (though since it is programmed it I would think they already did) | 00:05 |
| * MCR1 is searching for his video-evidence :-D | 00:05 | |
| bschaefer | MCR1, well make two bugs, one for that video you have | 00:06 |
| bschaefer | and when the mouse is over the launcher when the dash opens | 00:06 |
| MCR1 | bschaefer: Too tired today, maybe I'll attack that tomorrow ;) | 00:08 |
| bschaefer | MCR1, alright, cool. Have a good night :) | 00:08 |
| bschaefer | MCR1, also 1307 neil.pa | if (GetQuirk(MOUSE_MOVE_POST_REVEAL)) | 00:09 |
| bschaefer | so it was added a while ago | 00:09 |
| MCR1 | 1207 ? | 00:10 |
| MCR1 | *1307 | 00:10 |
| bschaefer | rev 1307 | 00:11 |
| MCR1 | ah | 00:11 |
| bschaefer | like we are on 26xx or something like that | 00:11 |
| MCR1 | line 58 is also strange... | 00:13 |
| MCR1 | tomorrow... gn :) & thanx a lot for your patience with me, bschaefer ;) | 00:14 |
| === charles_ is now known as charles | ||
| mhr3 | bilal, ping | 07:02 |
| MCR1 | JohnLea: Hi :) I would need your input here: https://bugs.launchpad.net/unity/+bug/1047232 | 08:47 |
| ubot5 | Ubuntu bug 1047232 in Unity "Unity Launcher Autohide Behavior: The Launcher should never autohide if the mousepointer hovers over it" [Undecided,New] | 08:47 |
| === mmrazik is now known as mmrazi|otp | ||
| MCR1 | duflu: Mornin' :) Do you have any comments on https://code.launchpad.net/~mc-return/compiz/compiz.merge-replace-defines/+merge/122865 ? | 09:11 |
| duflu | MCR1: Sorry, out of time this week | 09:11 |
| duflu | In a mad rush this afternoon | 09:11 |
| MCR1 | mad rushes can be productive, so I will stop nerveing ;) | 09:12 |
| MCR1 | *nerving | 09:12 |
| JohnLea | MCR1; that bug looks like a dupe of bug #745707 | 09:15 |
| didrocks | MCR1: see the MP, you are breaking one use case | 09:15 |
| 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 | 09:15 |
| didrocks | JohnLea: ^ | 09:15 |
| didrocks | JohnLea: this will break the "super" key case | 09:15 |
| JohnLea | didrocks; how will bug #745707 break the "super" key use case? | 09:16 |
| 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 | 09:16 |
| 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 | 09:16 |
| 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 | 09:20 |
| JohnLea | anding IMHO | 09:20 |
| 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 | 09:20 |
| JohnLea | didrocks; I'm updating the description of bug #745707 | 09:20 |
| 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 | 09:20 |
| didrocks | JohnLea: the bug doesn't describe it, however MCR1's fix is breaking it | 09:20 |
| didrocks | JohnLea: so the fix has to be redone, otherwise, we will have this regression | 09:21 |
| MCR1 | JohnLea, didrocks: To my understanding it would fix bug 745707 | 09:21 |
| JohnLea | didrocks; ok, MCR1 can you fix it? ;-) | 09:21 |
| didrocks | MCR1: see above + my comment ^ | 09:22 |
| didrocks | MCR1: you still have that use case to work | 09:22 |
| 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... | 09:23 |
| didrocks | MCR1: that was an explicit design use case | 09:23 |
| didrocks | there was more case in the past, that was removed by design | 09:23 |
| 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. | 09:25 |
| 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 | 09:25 |
| 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 | 09:25 |
| * MCR1 reading | 09:25 | |
| MCR1 | a long bug report... | 09:27 |
| * MCR1 needs some time to read and comprehend it all... | 09:27 | |
| 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 | 09:28 |
| MCR1 | JohnLea: Yes, I understand that case... | 09:29 |
| === mmrazi|otp is now known as mmrazik|lunch | ||
| MCR1 | JohnLea: Have you seen bug 1019453, btw. ? | 09:36 |
| 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 | 09:36 |
| JohnLea | MCR1; yes I have seen it ;-) | 09:37 |
| MCR1 | ^^^this would imho be the best behavior for launcher hiding... | 09:37 |
| MCR1 | JohnLea: Ofc I am very interested in what you think about it also... :) | 09:40 |
| 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. | 09:55 |
| sil2100 | JohnLea: what problems did normal users have with intellihide? | 09:56 |
| 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. | 09:57 |
| 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 | 09:57 |
| sil2100 | Progress requires learning... | 09:57 |
| 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 | 09:57 |
| 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. | 09:58 |
| 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? | 09:58 |
| 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... | 09:59 |
| 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 | 10:00 |
| JohnLea | cost of supporting the code. | 10:00 |
| JohnLea | MCR1; the problem with what you are describing is that most non-advanced users wouldn't get what was happening | 10:01 |
| 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 | 10:02 |
| MCR1 | JohnLea: As I said before, there never was intellihide implemented in Unity, so no user was testing it ever... | 10:02 |
| sil2100 | MCR1: there wasn't? | 10:02 |
| didrocks | MCR1: this was in the code, it was "dodge active window" | 10:02 |
| JohnLea | sil2100; there is also a UX cost to having options, just look at KDE. However in this case it was the cost of maintaining the feature that killed it. | 10:02 |
| MCR1 | JohnLea: Unity-2d has intellihide, Unity-3d once had window dodge... | 10:02 |
| MCR1 | Unity-2d's autohide feature acts like intellihide IIRC... | 10:03 |
| MCR1 | (it is a long time ago ;)) | 10:03 |
| didrocks | MCR1: so it had it | 10:03 |
| MCR1 | Unity-3d never had it | 10:03 |
| didrocks | dodge active window? | 10:04 |
| didrocks | I wrote this part of the code, I know what I wrote… :) | 10:04 |
| MCR1 | Unity-2d had it until it was removed, but it was called autohide | 10:04 |
| 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 | 10:04 |
| didrocks | MCR1: http://www.webupd8.org/2012/05/how-to-get-dodge-windows-and-minimize.html if you don't believe me | 10:05 |
| sil2100 | JohnLea: there's a lot of things to consider here indeed.. | 10:05 |
| didrocks | and look at the screenshot | 10:06 |
| didrocks | there is "dodge active window" | 10:06 |
| 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 | 10:07 |
| didrocks | MCR1: the ppa just reverted the commit | 10:07 |
| didrocks | so not a completely different re-implementation | 10:07 |
| didrocks | MCR1: http://bazaar.launchpad.net/~unity-team/unity/branch-3.0/view/head:/unityshell.xml.in | 10:09 |
| didrocks | this is unity oneiric | 10:09 |
| didrocks | see "Dodge Active Window" | 10:09 |
| didrocks | or you will tell that I faked the bzr repo? :) | 10:09 |
| MCR1 | oh, *surprised* | 10:09 |
| didrocks | thanks for trusting me when I told I wrote it… :/ | 10:09 |
| MCR1 | didrocks: I am really sorry - I never saw this option before... | 10:10 |
| didrocks | well, it was there :) | 10:11 |
| MCR1 | & ofc I trust you ;) | 10:11 |
| didrocks | the logic is not a lot more compared to the first one: http://bazaar.launchpad.net/~unity-team/unity/branch-3.0/view/head:/src/Launcher.cpp#L1894 | 10:11 |
| didrocks | just an "active" tag | 10:11 |
| didrocks | and the hidemachine had a state if we had that option enabled | 10:12 |
| didrocks | (which wasn't the default) | 10:12 |
| MCR1 | maybe the problem was that dodge any window was the default... and only this got tested, but I feel :-[ now, that I somehow skipped this option in CCSM... | 10:15 |
| MCR1 | great code, btw | 10:15 |
| didrocks | I loved the feature too, but as JohnLea said, user testing showed it was too complicated for them | 10:16 |
| didrocks | and the code is now buried… | 10:16 |
| MCR1 | :( | 10:17 |
| MCR1 | I know many people (especiall older ones) who have problems differentiating left and right mousebutton, but I still do not think that the right solution for this problem is to remove one of the buttons... | 10:19 |
| MCR1 | *especially | 10:19 |
| MCR1 | ^^^this is no joke... | 10:19 |
| didrocks | some did it :-) | 10:23 |
| MCR1 | :) | 10:24 |
| JohnLea | MCR1, didrocks; personally I am a fan of three button mice, RiscOS style. Left button primary action, middle button context menu (and no other app menus other than these context menus), right button secondary action. And everything in the operating system and all applications conforming to this pattern. I still miss RiscOS | 10:30 |
| MCR1 | JohnLea: Unfortunately no experience at all with RiscOS :) | 10:31 |
| JohnLea | MCR1; was way ahead of it's time in the early 90s, but got squeezed out by a combination on Windows, and inventing a chip that it named ARM, that quickly became worth more than the rest of the company. | 10:33 |
| JohnLea | MCR1; it did a bunch of UI things that were very different from both windows and osx and worked very well | 10:34 |
| MCR1 | JohnLea: From screenshots it reminds me a bit of the early Amiga days - those were glorious 8-) | 10:38 |
| MCR1 | My first HDD had 20 Megabyte and was starting like a jetplane :) | 10:39 |
| === mmrazik|lunch is now known as mmrazik | ||
| === MacSlow is now known as MacSlow|lunch | ||
| Night-hacks | any way to rotate Unity to bottom in 12.04 64 bit ? | 11:16 |
| popey | Night-hacks, No | 11:20 |
| Night-hacks | popey: really, that sucks ! | 11:21 |
| gord | you could turn your monitor on its side? | 11:45 |
| Mirv | didrocks: can you merge lp:~timo-jyrinki/compiz/ubuntu_add_pythoncompizconfig_pc to lp:ubuntu/compiz, so that we can propose lp:~compiz-team/compiz/compiz.merge-minor-fixes for merging and compiz works again? | 11:53 |
| didrocks | let me look :) | 11:55 |
| didrocks | Mirv: done | 11:57 |
| Mirv | didrocks: thanks | 11:59 |
| === mmrazik is now known as mmrazik|otp | ||
| didrocks | yw :) | 11:59 |
| sil2100 | didrocks: I prepared the nux tarball btw - can you push, in the meantime, the changes to lp:~ubuntu-desktop/unity/precise ? | 11:59 |
| sil2100 | didrocks: for the renaming? | 11:59 |
| sil2100 | didrocks: https://code.launchpad.net/~sil2100/unity/precise-geis-rename | 11:59 |
| didrocks | sil2100: the unity one are already done I think | 12:00 |
| didrocks | did you check? | 12:00 |
| sil2100 | ... would be awesome if it was | 12:00 |
| sil2100 | ;) | 12:00 |
| sil2100 | Awesome ;p | 12:00 |
| sil2100 | didrocks: thanks! | 12:00 |
| didrocks | :) | 12:00 |
| didrocks | yw | 12:00 |
| === MacSlow|lunch is now known as MacSlow | ||
| === mmrazik|otp is now known as mmrazik | ||
| sil2100 | didrocks: ok, I prepared and did a test build of the new nux tarball (with the renaming) | 12:32 |
| sil2100 | didrocks: can I push and publish? ;) | 12:32 |
| didrocks | sil2100: is there a bug to track the renaming? | 12:35 |
| didrocks | but yeah, publish the nux tarball | 12:35 |
| davidcalle | mhr3, hey, is there a libunity method to close a preview without closing the Dash? | 12:54 |
| sil2100 | didrocks: new tarball released, here is the packaging: https://code.launchpad.net/~sil2100/nux/precise-newtarball-geis | 12:54 |
| Mirv | MCR1: sam now added a python-compizconfig fix on top of your compiz.merge-minor-fixes, so he combination of that lp:~compiz-team/compiz/compiz.merge-minor-fixes would be going in and hopefully fixing everything (tm).. | 12:54 |
| zyga | hey everyone, I have just noticed that classic desktop in 12.10 has wrong order of window control buttons -> in unity that order is [x] [-] [o] while in classic mode they are [x] [o] [-] -- is this by design? | 12:56 |
| didrocks | sil2100: hum, in fact, I think you are missing a Breaks: | 12:59 |
| didrocks | like, if nux is updated | 12:59 |
| didrocks | and not unity | 12:59 |
| didrocks | hum | 12:59 |
| didrocks | forget about that one | 12:59 |
| didrocks | can be fine if there are symlink in the new utouch* packages | 13:00 |
| didrocks | sil2100: this has been the case, right? | 13:00 |
| didrocks | symlink from old naming to new naming? | 13:00 |
| sil2100 | didrocks: I think a transitional package is there | 13:03 |
| didrocks | sil2100: I'm speaking about symlink | 13:04 |
| didrocks | like if I update utouch* to the new naming | 13:04 |
| didrocks | with old nux and unity (because I couldn't upgrade everything in a row) | 13:04 |
| didrocks | is there a symlink to ensure that nux and unity are still running? | 13:05 |
| sil2100 | fginther: ^ | 13:05 |
| fginther | didrocks, sil2100 the old and new utouch libraries can coexist (i.e. libgeis1 and libutouch-geis1 can be installed at the same time). However, there is a conflicts and replaces on libutouch-geis-dev in libgeis-dev | 13:08 |
| didrocks | fginther: can we load in the same process the old and new one? | 13:09 |
| didrocks | fginther: like new nux using libgeis1 and old unity using libutouch-geis1 | 13:10 |
| fginther | didrocks, hmmm.. Yes that should work. Let me examine something to verify... | 13:11 |
| didrocks | thanks :) | 13:11 |
| sil2100 | I need to get fginther's unity/5.0 rename changes merged in | 13:12 |
| sil2100 | But the merger fails, looks to me like some stupid problem again | 13:12 |
| fginther | didrocks, Bonjour! Yes, you can mix new nux with old unity. nux only has s build-time dependency on libgeis-dev. | 13:16 |
| fginther | sil2100, what's the issue? | 13:17 |
| didrocks | fginther: excellent! thanks :) | 13:17 |
| didrocks | sil2100: there is a missing thing in the unity packaging though, in that case | 13:18 |
| didrocks | if libutouch-geis-dev and libgeis-dev are conflicting | 13:18 |
| didrocks | let me fix that :) | 13:18 |
| sil2100 | didrocks: thank you! | 13:28 |
| sil2100 | :) | 13:28 |
| didrocks | sil2100: not sure if you saw my question later today about the bug to track the renaming? | 13:30 |
| didrocks | sil2100: we need one for SRUing I guess | 13:30 |
| sil2100 | didrocks: hm, right | 13:32 |
| sil2100 | fginther: is there a bug for that already? | 13:32 |
| fginther | sil2100, will this work? https://bugs.launchpad.net/ubuntu/+bug/1037621 | 13:33 |
| ubot5 | Ubuntu bug 1037621 in Ubuntu Precise "[Needs-Packaging] geis (project name change)" [Undecided,In progress] | 13:33 |
| didrocks | I think something obvious with "renaming blablabla" would be better | 13:36 |
| didrocks | with a test case meaning, upgrading and see that there is no change, no regression and that multitouch is working | 13:36 |
| fginther | didrocks, ok, new bug on the way | 13:40 |
| fginther | didrocks, sil2100: https://bugs.launchpad.net/nux/+bug/1047385 | 13:52 |
| ubot5 | Ubuntu bug 1047385 in Nux "Update dependency on renamed geis" [Undecided,New] | 13:52 |
| tsdgeos | my first silly contribution to compiz so that i can at least compile it :D https://code.launchpad.net/~aacid/compiz/kde_needs_kdeworkspace/+merge/123278 | 13:53 |
| didrocks | fginther: good, please add the packaging task, the unity ones as well, and nominate for precise | 13:53 |
| didrocks | fginther: put the quantal tasks as fix released | 13:53 |
| mhr3 | davidcalle, no, user decides when to close it, not the scope | 14:10 |
| mhr3 | why would you need that? | 14:10 |
| davidcalle | mhr3, to do something to a result when an preview action is clicked, without loosing the context of the search. Possible use case : https://plus.google.com/u/0/117867558830601601230/posts/eLD7PMcMZ7M | 14:12 |
| davidcalle | losing* | 14:12 |
| davidcalle | mhr3, another option (for this use case) would be to be able to update the content of the preivew (including actions), when an action is activated. | 14:13 |
| mhr3 | davidcalle, oh so you want to go back to results after clicking? | 14:14 |
| MCR1 | Mirv: thx 4 the info. | 14:14 |
| davidcalle | mhr3, yeah | 14:14 |
| mhr3 | yea, we should support that, and it might be possible somehow already :) | 14:15 |
| mhr3 | maybe if you used goto dash uri | 14:15 |
| davidcalle | mhr3, goto dash uri, I've seen that used somewhere... | 14:15 |
| mhr3 | i'm not sure it'd work, but protocol-wise it's doable | 14:16 |
| MCR1 | tsdgeos: Keep it coming ;) | 14:16 |
| mhr3 | (doable right now) | 14:16 |
| tsdgeos | MCR1: jenkins complained https://code.launchpad.net/~aacid/compiz/kde_needs_kdeworkspace/+merge/123278 but but but, any idea why? | 14:17 |
| tsdgeos | mmrazik: ↑ ? | 14:17 |
| davidcalle | mhr3, you mean something like Unity.ActivationResponse(goto_uri='' , handled = 1) | 14:18 |
| mmrazik | tsdgeos: I'm just looking at it | 14:18 |
| davidcalle | mhr3, nevermind, just seen what you are talking about | 14:19 |
| MCR1 | tsdgeos: Have you rebased on latest lp:compiz ? | 14:19 |
| MCR1 | tsdgeos: bzr merge lp:compiz | 14:20 |
| MCR1 | bzr commit | 14:20 |
| MCR1 | bzr push | 14:20 |
| tsdgeos | let me see | 14:20 |
| MCR1 | cp: cannot stat `debian/tmp/debian/tmp/usr/lib/pkgconfig/compizconfig-python.pc': No such file or directory | 14:20 |
| MCR1 | dh_install: cp -a debian/tmp/debian/tmp/usr/lib/pkgconfig/compizconfig-python.pc debian/python-compizconfig//usr/lib/pkgconfig/ returned exit code 1 | 14:20 |
| MCR1 | the fix for that is missing in your version ^^ | 14:20 |
| mmrazik | tsdgeos: that ie exactly where jenkins fails | 14:20 |
| tsdgeos | i see | 14:21 |
| mmrazik | MCR1: so it is in trunk already? | 14:21 |
| MCR1 | I have not tested, but I think - 1 sec | 14:21 |
| mmrazik | MCR1, tsdgeos: well.. I just found a bug in the ci job config. It is not merging with trunk... | 14:22 |
| MCR1 | mmrazik: yes | 14:22 |
| mmrazik | that should be fixed | 14:22 |
| mmrazik | so let me re-trigger the job | 14:22 |
| tsdgeos | mmrazik: i'm useful! | 14:22 |
| tsdgeos | :D | 14:22 |
| mmrazik | :) | 14:22 |
| MCR1 | mmrazik: yeah, you are right - I just got the mails that it did... | 14:23 |
| fginther | sil2100, didrocks can I ask you to please hold off work on the nux/unity for a moment | 14:23 |
| davidcalle | mhr3, don't work, it just closes the Dash. | 14:23 |
| MCR1 | mmrazik: no, it is in trunk (since 50 min) | 14:23 |
| MCR1 | http://bazaar.launchpad.net/~compiz-team/compiz/0.9.8/revision/3352 | 14:24 |
| mmrazik | MCR1: ack. The compiz-ci was building just the branch from tsdgeos and it didn't merge it with lp:compiz | 14:24 |
| mhr3 | davidcalle, what did you use? | 14:24 |
| davidcalle | return Unity.ActivationResponse(goto_uri='', handled=3 ) and return Unity.ActivationResponse.new(Unity.HandledType.HIDE_DASH, '') | 14:24 |
| davidcalle | Not HIDE_DASH, bad copiy paste | 14:24 |
| davidcalle | but GOTO_DASH_URI | 14:25 |
| mhr3 | davidcalle, try "home.lens" for the uri | 14:25 |
| sil2100 | fginther: ugh? What's up? | 14:25 |
| didrocks | fginther: sure, and TBH I don't ming, tons of pings here | 14:26 |
| davidcalle | mhr3, nope | 14:27 |
| fginther | sil2100, didrock chase found a potential issue that needs to be root cause | 14:28 |
| mhr3 | davidcalle, so, yea... open a bug :) | 14:28 |
| sil2100 | fginther: ok, keep me in touch then ;) Need any help? | 14:28 |
| sil2100 | fginther: where is the issue btw.? Hope it's not in nux... | 14:32 |
| fginther | sil2100, I don't have many details yet, just that "- Verify gesture functionality" isn't working. | 14:35 |
| sil2100 | Oh, ok | 14:36 |
| === yofel_ is now known as yofel | ||
| MCR1 | didrocks: Can and should I use the ubus_manager_ to check if the Dash has been activated with the shortcut key ? | 16:29 |
| didrocks | MCR1: not sure you will get this info, but I didn't look at ubus_manager for a long time :) | 16:30 |
| bschaefer | MCR1, it should send this message when the dash opens. UBUS_OVERLAY_SHOWN | 16:40 |
| * bschaefer double checks it | 16:40 | |
| bschaefer | yeah | 16:40 |
| didrocks | bschaefer: right, but it doesn't special case if it's opened with the shortcut key | 16:40 |
| didrocks | which is what MCR1 wanted I guess | 16:41 |
| bschaefer | didrocks, ooo, yeah...wait I think it does... | 16:41 |
| * bschaefer goes to check | 16:41 | |
| MCR1 | bschaefer: I thought more about using UBUS_DASH_EXTERNAL_ACTIVATION | 16:41 |
| bschaefer | ubus.SendMessage(UBUS_PLACE_ENTRY_ACTIVATE_REQUEST, g_variant_new("(sus)", "home.lens", dash::NOT_HANDLED, "")); | 16:41 |
| bschaefer | LauncherController.cpp:727 | 16:42 |
| bschaefer | MCR1, ^ | 16:42 |
| MCR1 | bschaefer: thx | 16:42 |
| bschaefer | MCR1, np :) | 16:42 |
| mhr3 | and i'll be probably removing ubus_manager :P | 16:52 |
| bschaefer | mhr3, please do...it just causes issues | 16:54 |
| bschaefer | :) | 16:54 |
| bschaefer | things need to be re worked though.... | 16:54 |
| mhr3 | bschaefer, well, i mean like rewrite it, not get rid of it completely | 16:55 |
| bschaefer | mhr3, haha, I was hoping you figured out how to do that | 16:55 |
| * bschaefer thinks ubus ruins OO design | 16:55 | |
| mhr3 | imo it's useful | 16:55 |
| bschaefer | yeaah | 16:55 |
| bschaefer | but I wonder if things could be designed to fit better | 16:56 |
| mhr3 | and it's message passing, isn't that base of OO? :) | 16:56 |
| bschaefer | yeah, but it likes a huge global variable | 16:56 |
| bschaefer | err | 16:57 |
| bschaefer | its talking with things it shouldn't be | 16:57 |
| mhr3 | like? | 16:57 |
| bschaefer | like when the Dash is about to show it sends this ubus message to everyone who is listening (which you never know when it'll get there) | 16:58 |
| bschaefer | which causes syncing problems | 16:58 |
| mhr3 | fwiw one thing i'll change is that you'll be able to assign priority to the message when sending it | 16:58 |
| bschaefer | oo that would be awesome | 16:58 |
| bschaefer | but its a queue! | 16:58 |
| bschaefer | priority queue | 16:59 |
| mhr3 | which from my tests is a huge win for responsiveness | 16:59 |
| bschaefer | max/min heap...hmm that should work :) | 16:59 |
| bschaefer | mhr3, yeah, ubus does help a lot, but I keep running into times where I NEED the message to be sent and read before going on... | 16:59 |
| mhr3 | well the listeners will still be invoked in order they registered | 17:00 |
| mhr3 | but the high prio msg will be delivered sooner than the standard ones | 17:00 |
| didrocks | mhr3: do you have so much UBUS traffic to need that? | 17:00 |
| didrocks | was pretty low in my time :) | 17:01 |
| bschaefer | yeah, that would be awesome | 17:01 |
| mhr3 | didrocks, no, but it uses idle which is not acceptable for everything | 17:01 |
| didrocks | you want some sync messages? | 17:01 |
| mhr3 | didrocks, didn't you read the bugs which say that dash opens >5seconds after super keypress | 17:01 |
| bschaefer | didrocks, yes | 17:01 |
| mhr3 | that's because it uses idle | 17:02 |
| didrocks | mhr3: didn't see that one TBH :) | 17:02 |
| mhr3 | bschaefer, no, no, still fully async | 17:02 |
| bschaefer | mhr3, I removed that | 17:02 |
| * bschaefer always confuses async and sync | 17:02 | |
| didrocks | I remember to have reported that more than one in my old system :) | 17:02 |
| bschaefer | but I know the definition of both haha | 17:02 |
| bschaefer | mhr3, that Idle in opening the dash is removed :) | 17:03 |
| didrocks | mhr3: hum, async and no idle to bring it back to the main loop, I'm confused :) | 17:03 |
| bschaefer | (or it will be soon) | 17:03 |
| mhr3 | didrocks, async is fine as long as you can specify the prio | 17:03 |
| mhr3 | and in compiz it's simple | 17:04 |
| mhr3 | HIGH prio - do on next iteration, STANDARD - do when current processing finishes, LOW - do sometimes in the future when the app isn't doing anything (which is once in 30seconds on slow machines) | 17:05 |
| mhr3 | right now it defaults to the last, and therefore it sucks | 17:05 |
| bschaefer | mhr3, yea, if it would do it next iteration at times I would no longer hate ubus as it is in unity :) | 17:05 |
| mhr3 | (ok the 30seconds was a bit exagerrated) :P | 17:06 |
| bschaefer | haha ~1 second | 17:06 |
| bschaefer | is still to long | 17:06 |
| didrocks | mhr3: hum, I don't get the STANDARD one, you will get the mainloop more than once | 17:06 |
| mhr3 | for user-initiated actions, indeed | 17:06 |
| mhr3 | didrocks, compiz repaints and reading from sockets is done with standard | 17:07 |
| bschaefer | mhr3, wait is this just some sort of dream or in the works? | 17:08 |
| didrocks | ok | 17:08 |
| didrocks | make sense now | 17:08 |
| MCR1 | from reading your conversation above it seems to me that the ubus solution might not be the best for my problem | 17:08 |
| mhr3 | otherwise said - the usual case is - HIGH: do on next iteration, STANDARD: do in next ~10 iterations, LOW: next ~100? | 17:08 |
| didrocks | mhr3: yeah, more clear that way :) | 17:09 |
| didrocks | you are basically implemented a g_source? :) | 17:09 |
| mhr3 | bschaefer, ehm.... :) | 17:09 |
| mhr3 | didrocks, ubus uses gsources, so i'm just explaining how it fits into the global picture of processing events | 17:10 |
| bschaefer | mhr3, well I would love to work on that part (If I ever get time) ... as it would be fun to implement a priority queue | 17:10 |
| didrocks | ok :) | 17:10 |
| mhr3 | bschaefer, you mean like auto q = std::queue<...>(); ? | 17:10 |
| bschaefer | mhr3, that is a standard queue | 17:11 |
| bschaefer | FIFO | 17:11 |
| mhr3 | oh.. priority | 17:11 |
| mhr3 | sorry | 17:11 |
| bschaefer | I don't think that is in the standard... | 17:11 |
| mhr3 | bschaefer, so yea auto q = std::priority_queue<...>(); :P | 17:11 |
| bschaefer | mhr3, dam, it has been a while since I wrote a heap :( | 17:11 |
| bschaefer | mhr3, but that is going to be better then what I could have made haha | 17:12 |
| mhr3 | bschaefer, although data structures are awesome, don't expect you'll ever have to implement one :) | 17:12 |
| bschaefer | mhr3, i know :) (I can dream though!) | 17:12 |
| mhr3 | bschaefer, know their properties though, that's extermly important | 17:13 |
| bschaefer | mhr3, yes it is! and awesome it uses a heap :) | 17:13 |
| mhr3 | i never got to implementing heap at uni, i randomly picked hashtable instead :P | 17:14 |
| bschaefer | mhr3, we got to make a process scheduler (not a real one haha) | 17:14 |
| bschaefer | that was really fun | 17:14 |
| mhr3 | oh that sounds nice | 17:14 |
| bschaefer | which in a sense is what you would want with the ubus | 17:15 |
| bschaefer | each new ubus message add to queue | 17:15 |
| bschaefer | let the heap do its magic | 17:15 |
| bschaefer | grab front | 17:15 |
| bschaefer | though I am not sure how ubus works with the main loop | 17:15 |
| mhr3 | my plan say multimap | 17:16 |
| mhr3 | msgs with same priority will be appended, high prio is put where it needs to | 17:17 |
| bschaefer | nice, using that binary tree :) | 17:17 |
| bschaefer | hmm so a max of 3 nodes? | 17:17 |
| bschaefer | and each node having a queue? | 17:18 |
| mhr3 | honestly i dunno what multimap uses | 17:18 |
| bschaefer | (maps use binary trees) | 17:18 |
| mhr3 | but yea, i guess binary tree with lists as nodes | 17:18 |
| bschaefer | hmm that would also work, but if the priority queue is already in the standard it could make things easier | 17:19 |
| bschaefer | so you wouldn't have to make a map<int, queue> | 17:19 |
| mhr3 | yea, i'll check it out | 17:19 |
| bschaefer | mhr3, cool :) that sounds like fun haha | 17:19 |
| mhr3 | anyway, eod for today :) | 17:19 |
| bschaefer | yeah, I should do some work :) | 17:19 |
| bschaefer | have a good weekend! | 17:19 |
| === artfwo_ is now known as artfwo | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!