=== m_conley_away is now known as m_conley === m_conley is now known as m_conley_away === eu is now known as adorilson [08:11] morning all! [08:28] Happy Monday, everyone! :-D [11:12] good morning! [11:37] gatox, morning! [11:37] gatox, I have a question for you! [11:37] :) [11:37] mandel, shoot [11:38] gatox, I'm fixing bug #1065513 [11:38] Launchpad bug 1065513 in Ubuntu One Control Panel "Double gathering info screen " [Medium,Triaged] https://launchpad.net/bugs/1065513 [11:38] gatox, it seems to happen because one of the overlays (don't know which) is drawn at the wrong position or something, that is, if you set the lodaing overlay to be a singleton you won't get the second one [11:39] gatox, why do we have server overlays? could we have used a single one and hide and show according to the tab? [11:40] mandel, i'm not sure i understand what you mean.... we are showing the overlay in each tab when the user press in some tab and the info need to be refreshed [11:41] gatox, yes, but we are creating 10 instances of the overlay [11:41] gatox, one for the folderspanel, other for the share links panel, devices etc... [11:42] gatox, the question is, why do we create one for each panel, should we use a single one and use a ref to it to tell it to be shown or not? [11:42] mandel, let me recheck the code [11:43] gatox, the code imports UbuntuOneBin (which I have no clue of what it does) in several places, which is what instantiates the overlay [11:44] mandel, yes... i see it [11:45] gatox, which means that the overlay has more than one sintance and is shown per tab, could mean that the double overlay we see in other systems (I cannot get it on ubuntu) is because of that [11:45] gatox, the ideal way would be to have a single overlay that is shown or not as per request of the tab [11:46] mandel, can you show me a screenshot of the double overlay? [11:46] gatox, sure, give me a sec [11:46] gatox, mandel: I can help with that, if you want [11:46] nessita, one sec, uploading pict so that we all can see the problem :) [11:47] gatox, mandel: if it's what I think it is, "is not a bug is a feature" :-) [11:48] every request that hits the "network" or syndaemon has to show feedback to the user that we're fetching data that may take a while [11:48] nessita, i don't think is a bug either..... but i want to see what mandel means too [11:48] so, when opening the control panel, we fetch 2 different pieces of info [11:48] yes [11:48] the account info, which shows a "global" overlay, covering the whole window [11:49] and the folder info, which shows an overlay only on top of the folder tab [11:49] unifying those could be a little (a lot) complicated [11:49] it is a bug because it looks like this: http://ubuntuone.com/73sN9YTCoGkv4wEIMpsGG3 [11:49] cuz each piece of info can arrive a very different times [11:50] mandel, that is exactly what nessita explain [11:50] mandel: yes, is not a bug [11:50] does not look ideal [11:50] but is not a bug [11:50] mandel: each overlay is referrring to different info [11:50] nessita, gatox, is a bug, if there is loading info we should not show redundant information, we should ensure that if the loading overlay is shown we don't show it again [11:51] mandel: that's very very hard to do [11:51] you could have a singlenton in yo which you can register as a timed operation, and you removed yourself when done [11:51] overlay gets the signal I'm done, and if all are done gets out of the way [11:51] nessita, yes, I know it is a lot of work [11:52] mandel: ok, what I care the most if that you don't remove it without understanding why there is 2 [11:52] FYI, this is only happening when the account info is retrieved [11:53] then we never show more than one overlay [11:53] mandel, yes........ but you will have a parentship problem if you want a single overlay....... where it can blocks the ui, so when something is loading you can't press other buttons..... and to avoid that you need to add it in each widget, so you can set the parent and resizeEvent properly [11:53] mandel: also, is worth noting that you should not block the whole ui when fetching info for single tab [11:53] nessita, ^ [11:53] gatox: exactly (what I just also said) [11:53] nessita, yep! [11:53] nessita, yes, that is why if the tab is not visible should be taken into account [11:54] mandel: not sure what that means [11:54] nessita, as in, if a ui element that requires certain info to be ready is not visible do ignore it and do not show the overlay [11:56] * mandel hopes he makes sense [11:57] mandel: yes, and that's currently the case [11:57] mandel: if your screenthost, the 2 elements that are showing an overlay are visible: [11:58] the account section, and the folders tab [11:58] dobey: ralsina: ping [11:59] nessita, exactly, which repeats the information an adds redundancy that is not needed, a single overlay should be shown in this case for any possible combination, that is account is there and tab is not or the otherway around [11:59] mandel: I agree that a bug is worth reporting to design a proper solution... [11:59] nessita, has been reported already and ralsina pushed it my way, that is why I'm asking the reasoning from doing it like it is done :) [12:00] mandel: reasoning: was the not extremely complex way of doing it [12:00] nessita, ack [12:00] mandel: other ways are pretty complex. If you have any proposal for solving this, I would love to read it and help you decide if it will solve the problem [12:01] nessita, I'll write something about my toughs about it [12:01] mandel: let me know :-) [12:13] mandel, if you have a moment, could you review this one? (small) https://code.launchpad.net/~diegosarmentero/ubuntuone-client/deflated-size/+merge/129215 [12:17] gatox, yes, will do asap [12:17] mandel, thx [12:19] gatox, nessita, a small idea on how to possible change the current implementation: http://paste.ubuntu.com/1280969/ [12:20] gatox, nessita, the signal I mention does not have to have an overlay specific name, maybe currentWorkLoad or something like that is better [12:21] mandel: did you read the message I wrote before about not blocking the whole ui when fetching info for a single panel? [12:21] gatox, nessita we might want to talk with lissette to consider how to show the loading oeverlay, may be being over the entire ui is as bad as having two [12:21] nessita, yes, with this idea you will just do so in the first case.. [12:22] mandel: how come? if we hav a single instance, that instance will be as big as the whole window, no? [12:22] nessita, we can have two overlays and one do not show the message if the other is (I'm more interested in the idea of using signals to do it) [12:22] or perhaps I'm missing something? [12:22] nessita, yes, you are right, there I did not consider that case [12:23] nessita, could have a single instance for all tabs and one for the account into [12:23] mandel, you can't one instance for all the tabs [12:23] nessita, the one in the account info will show the loading message only if the other overlay is hidden [12:23] gatox, why?> [12:23] mandel: well, the instance for the tabs needs to leave the tabs "out" so the can be clicked [12:23] mandel, because the overlay has as it parent the content of the tabs..... not the qtabwidget [12:24] gatox: so, when fetching shares links info, the user needs to be able to click on devices [12:24] which avoid having the problem nessita mention [12:24] sorry, mandel I meant :-) [12:24] mandel -> so, when fetching --for example-- shares links info, the user needs to be able to click on devices [12:24] so we can't have an overlay per the whole tab group [12:25] and that's why you can't use singleton either [12:25] nessita, gatox, hm... then maybe same number of instances, make the tab overlay instances be in-sync with the accounts overlay via signals [12:25] gatox, I hate singletons in most use cases :) [12:25] nessita, gatox, so that account info overlay instance know when to show or not the loading message [12:26] mandel: not sure how that solution would be implementable... [12:26] mandel: any chance you outline the specifics a little more? [12:27] nessita, sure, fancy to talk over mumble, I think we would agree faster :) [12:27] mandel, yep..... i would like to mumble..... i have some questions about that [12:27] mandel: I'm at the phone right now, could be in mumble in 15'... [12:28] mandel: but you can mumble with gatox, he understands the issue :-) [12:28] * I think * :-P [12:28] nessita, I'll mumble with gatox and then I'll take some of you time after my lunch hehe [12:28] go ahead [12:28] gatox, to the mumble cave!!! [12:28] nananana [12:35] good morning! [12:35] ralsina, hi [12:38] nessita, mandel: what we need is all overlays to be in the exact same place. That way, if we have the window-overlay, we don't see two ;-) [12:39] but that is mostly a cosmetic fix [12:39] ralsina, wet think we have a better approach [12:39] ralsina, join mumble :) [12:39] mandel: can't, sorry [12:39] ralsina, fuuuu [12:39] mandel: but I am all for better approaches ;-) [12:39] ralsina, ok, so, they can't all be in the same place because they don't know about each other [12:40] mandel: nah, it's trivial [12:40] mandel: so, I don't believe you ;-) [12:40] ralsina, gatox and I were thinking of removing the one from the account panel and add a loading gif to the name and siable the button [12:40] ralsina, then add the name and th enable the button when done [12:40] super simple [12:40] and no hack needed [12:40] "button"? [12:40] the connect/disconnect [12:40] hello, all! [12:41] mandel: is that the only bit that blocks the whole window? [12:41] mandel: if yes, +1 and remove the global overlay [12:41] ralsina, for the accounts, yes [12:41] gatox: no need to disable the connect.disconnect button [12:41] nessita, me, right :) [12:41] nessita, ah..... true [12:41] mandel: ^ since is not related to fetching account info [12:41] nessita, even better! [12:42] nessita, ralsina, gatox we just do it for the name and done :) [12:42] so, easier.... just replace the name label [12:45] sounds like a great way to solve it then [12:45] I'll speak with lisette after lunch about it [12:46] now, time for me to have food :) === mandel is now known as mande|lunch [12:47] dobey, let me know when you are here please..... now i can access tarmac.... but it seems it can do bzr branch there....... this thing hates me [12:47] it can't [12:50] gatox: ssh -A [12:50] dobey, checking.... thx [12:50] Chipaca: hey, what's up? [12:51] gatox: but i pulled your branch on that instance and ran the tests, and they passed [12:52] dobey, what?!....... why is failing then?! [12:52] * gatox cries [12:52] i have no idea [12:52] :( [12:53] dobey: hey. Nothing, in the end. [12:53] dobey: crises averted. [12:53] great [12:53] hello dobey, welcome back! [12:54] dobey, ah! and welcome back! :D [12:54] thanks [12:57] ralsina, so..... i'm running the tests manually in tarmac..... and they all pass!!.... but i have u1-cp branches bouncing on launchpad.... should i try to re-accept them again or that is the definition of insane? [13:12] gatox: that's very strange. Locale? [13:13] gatox: also it doesn't look like a timing issue at all... perhaps something in the PYTHONPATH is different in tarmac? [13:13] ralsina, locale??..... but i'm running them on tarmac too.... and they pass for me and dobey when i execute the tests manually [13:13] gatox: no, tarmac runs with en_US.UTF-8 [13:14] dobey, that no was for me or ralsina ? [13:14] gatox: for you, it's not the locale [13:14] ah yes.... i suppose it's not [13:14] and it's almost certainly not the PYTHONPATH either [13:15] i just tried to re approve the branch....... crazy things happend.... [13:15] * gatox finger cross [13:16] gatox: i did that on your previous branch it failed again with the same errors, so i'm not sure that will help [13:16] dobey, nop..... it didn't work again...... [13:17] this is driving me crazy [13:20] quick errand....... brb === gatox is now known as gatox_brb === m_conley_away is now known as m_conley [13:28] gatox_brb: well, one branch just merged ok [13:30] gatox_brb: and why did you delete https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/shares-broken/+merge/128108 ? [13:36] gatox_brb: though i think i see why your branch is failing; not sure exactly the cause, but i think i know what change is triggering it [13:37] back === gatox_brb is now known as gatox [13:38] dobey, i deleted that branch.... because it was a workaround for the mac release..... and didn't land on trunk before i proposed the proper solution for the issue... so it's not actually needed anymore having the other branch [13:39] gatox: don't delete branches, reject them [13:39] ralsina, ack [13:39] gatox: what ralsina just said; deleting them is discourteous [13:41] gatox: on tarmac, are you just branching your code, or branching trunk and merging it? [13:41] ralsina, branching my code...... i'll try merging [13:43] ralsina, same result [13:43] gatox: so, it passes? [13:43] ralsina, yes [13:43] gatox: ok, we can do a nasty thing :-) [13:43] * gatox accepts anything [13:43] gatox: you could add some prints in your branch and try to merge again [13:44] ralsina, why? [13:44] why some prints i mena? [13:44] gatox: because it's failing with first argument of unbound method must have type 'QThread' [13:44] gatox: and I want to know exactly what thing it believes is an unbound method [13:44] ralsina, ahhhhh you mean to debug it [13:44] gatox: exactly [13:45] ralsina, ack..... i'll do that! [13:45] gatox: worst case, it merges with a print and dobey hunts you down ;-) [13:45] jejeje [13:46] the merge *could* be broken [13:48] nope [13:48] passes merged for me [13:48] so probably timing [13:48] dobey, yep.... for me too [13:48] passed i mean [13:49] mande|lunch, after lunch, review this one too if you can: https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/pointing-hand/+merge/129502 [13:50] gatox: i don't quite understand what the changes in test_share_links_search.py have to do with the rest of the branch === nessita1 is now known as nessita [13:51] gatox: and i suspect those changes are what's breaking this [13:53] dobey, that is actually fixing a timing issue that we used to have....... and making sure that the QThread is not executed as a thread [13:55] gatox: can you file a separate bug for that issue, remove those changes from that branch, and put them in a new branch for the new bug? [13:55] dobey, of course..... will do that [13:55] thanks [13:56] gatox: please ping me when u1-cp-publishapi branch is updated to not have those changes, and we'll try to merge without them === mande|lunch is now known as mandel [13:56] gatox, ok [13:57] dobey, ack [13:57] mandel, thx [13:58] anything else blow up while i was away? or just gatox's branch? [13:59] hi folks, welcome back dobey! hope you had a good break [14:01] thanks; and eh, it was not as good as was planned; weather failed me [14:06] dobey: just gatox's [14:06] good morning mmcc [14:06] mmcc: how hard would it be to make a separate build for 32 bit macs? [14:06] hrmm [14:06] u1cp windows tests seem to be failing [14:07] gatox, here: https://code.launchpad.net/~diegosarmentero/ubuntuone-client/deflated-size/+merge/129215 why changing the name from size to deflated_size ?? [14:07] dobey: there are failures on a bunch of windows projects, mostly because jenkins has been down recently so they snuck in [14:07] dobey: and jenkins doesnt actually work right now (working on it) [14:08] briancurtin: this seems to be like it's got a messed up checkout or something [14:08] ralsina: I'm not sure. Definitely requires some tweaking on the fsevents daemon to get it 32-bit compatible - it uses objc language features that are only in the 64-bit runtime… [14:08] mandel, check the bug description: https://bugs.launchpad.net/ubuntuone-client/+bug/1062729 [14:08] Ubuntu bug 1062729 in Ubuntu One Client "sync menu uses wrong upload size for percentages" [Undecided,Confirmed] [14:09] briancurtin: but i'll leave it to you then :) [14:09] dobey: i'm probably going to rebuild the setup since it has some out-of-date stuff and should be on the same setup we're running on dev boxes [14:09] briancurtin: sounds good [14:10] mmcc: ack, it's worth investigating [14:10] mmcc: we got one request for the 32-bit version at least [14:10] all: i'm going to post my standup done/todo now because i need to head to a doctor's appointment (bad time choice, i know). i came early and will stick around late depending on how long this takes [14:10] DONE: adjusted the sso bin-finding branch to work with the u1client branch, so now u1cp on windows works fine. two small branches to review: https://code.launchpad.net/~brian.curtin/ubuntuone-client/correct-subprocess-args/+merge/129506 and https://code.launchpad.net/~brian.curtin/ubuntu-sso-client/correct-subprocess-args/+merge/129442 [14:10] TODO: look at jenkins (done a bit this morning) because it still isn't running the tests, but it executes a bunch of pre-test steps. review a few branches that have backed up [14:12] (ammendment to the TODO - probably just rebuilding the jenkins setup to make it easier) [14:12] ralsina: ok. I'll see if there are any other issues for 32. [14:12] mmcc: at least knowing what needs to be done [14:13] ralsina: ok === yofel_ is now known as yofel [14:25] gatox, oh, ok [14:26] gatox, both reviews done [14:27] mandel, thx..... approved or need fixing? [14:27] gatox, both +1 [14:27] mandel, awesome! thx [14:41] dobey, the branch has been modified [14:49] ok, just sent an email about using PyObjC for the menu. In short, I think it's a good idea (and it's working in code). But I'm sensitive to the fact that it's adding to the number of languages & frameworks we need to know to maintain the code… [14:51] mmcc: how does it affect binary size? It's a very minor concern. [14:51] mmcc: also, does it add any packaging complexity? [14:52] mmcc: you can probably kill this bug report, asked the user to submit a ticket in support. https://bugs.launchpad.net/ubuntuone-client/+bug/1066920 [14:52] Ubuntu bug 1066920 in Ubuntu One Client "MacBook Pro (retina) will not shutdown while ubuntu one client is running" [Undecided,New] [14:54] ralsina: good questions… binary size - negligible. just a few K for PyObjC python code, no new frameworks (just loads the AppKit that's already there, and that's OK to do.) [14:55] ralsina: packaging complexity, not really. need to tweak things around to have the menu be a separate process anyway, this would roll into that [14:55] mmcc: ok, so no new concern there [14:55] mmcc: I don't expect it to be a complex program, as long as the reactor and pyobjc get along [14:55] mmcc: not much more than current systray.py at least [14:56] chaselivingston: that's a dupe, I'll find the orig. It sounds like maybe we need to add a FAQ about where the logs are on osx -- the reporter was looking in ~/.cache, but they're in ~/Library/Caches/ubuntuone [14:56] ralsina: it's about the same, yeah. [14:57] mmcc: so +1 from me, and better now than later [14:57] mmcc: right, my script can get those if you want to tell them about that as well [14:57] ralsina - oh I forgot something in the email: I haven't tried this yet - of course :) - but I do think we can use trial to test this thing, so we don't have to adopt a new test framework [14:57] mmcc: good one ;-) [14:58] ralsina: do we actually need a reactor in the process though? [14:58] dobey: yes for the IPC [14:58] oh, right :-/ [14:59] dobey: on mac/win we pretty much always need a reactor [15:00] me? [15:00] me [15:00] me [15:01] me [15:01] me [15:02] DONE: wrap u1db TODO: ?? BLOCKED: no NEXT: gatox [15:02] gatox: hah, and your branch merged without those changes. so that set of changes is triggering another issues it seems :) [15:02] DONE: [15:02] Proposed a couple of branches for control panel. A lot of ssh configurations and fights trying to connect to tarmac. Tested bouncing branches there. Refactor bouncing branch and updated. Working in another branch for the qthread problem. [15:02] TODO: [15:02] Proposed a fix for the race condition with qthread. Keep fixing stuff in cp. [15:02] BLOCKED: [15:02] No [15:02] dobey, go [15:02] me [15:02] DONE: holidays [15:02] TODO: catch up, bug triage, fix bugs, move off pylint [15:02] BLCK: None. [15:02] alecu: go [15:02] DONE: got some medical checks, more planned for this wed, fixes in dash branches [15:02] TODO: get dash branches reviewed and merged [15:02] BLOCKED: no [15:02] NEXT: mmcc [15:02] DONE: pyobjc menu does progress bars [15:02] TODO: finish menu impl, tests [15:02] BLOCK: no [15:03] next ralsina? [15:03] sorry guys go without me :-( [15:03] mandel: go [15:03] DONE: Review, reviews, reviews. Worked on bug 1065513 with nessita and gatox, talk with lisette on the design ideas. [15:03] TODO: Organize possible travels, get bug 1065513 fixed. 1-1 [15:03] BLOCKED: no [15:03] Launchpad bug 1065513 in Ubuntu One Control Panel "Double gathering info screen " [Medium,Triaged] https://launchpad.net/bugs/1065513 [15:05] gatox: wha? it merged? [15:05] oh I forgot one more thing about PyObjC: method names like "NSTimer.scheduledTimerWithTimeInterval_target_selector_userInfo_repeats_" make the pep8 checker go nuts. :| [15:06] (or pyflakes, I forget which. line length, anyway) [15:06] ralsina, yes..... i'm proposing another branch with the qhtread thing to avoid the race conditionn [15:06] mmcc, ralsina: while we are on the pyobjc discussion, let's keep in mind that it's a bit undermaintained, and that support for python 3 is hacky at best: http://blog.pythonaro.com/2012/08/how-to-compile-pyobjc-for-python-3-on.html [15:07] mmcc, you can always tell it to ignore a file (pep8 I guess is the one complaining) [15:08] mmcc, if this is in ubuntuone-client is pyflakes in the others is pylint [15:08] mmcc, in pylint you can use a # pylint: disable=#NUMBER [15:08] alecu: yes, good point - ronald is the only person actively working on it. py3 support is what he's most actively working on, though. And the website is so far behind that I actually volunteered to help fix it [15:09] mmcc: nice [15:09] mandel, in my case it's emacs highlighting lines from the result of both pyflakes and pep8.py, so still :| [15:09] mandel: the long line thing is probably pep8 [15:09] dobey, I think so too [15:10] mmcc, well, that is a diff story, but if you ignore them tarmar will let you merge the branch, else it will be blocked [15:10] alecu: and despite low # of active committers, people do use pyobjc for real shipping things. I'm not sure if that means it'd get picked up if ronald stopped, but it's something. [15:10] mandel: i guess this isn't in a branch yet exactly? [15:11] mmcc, why not using ctypes? [15:12] mandel because ctypes is for C. calling ObjC with a C interface would mean reimplementing PyObjC, basically [15:12] oh, ok [15:12] every message send in objc boils down to a C call to objc_msgsend(), so I'd need to wrap that, depythonify data structures, etc etc, boom I've rewritten pyobjc, badly :) [15:12] :-) [15:14] alecu: keep in mind that we will stay py2 on windows for a long time, so probably makes no difference to stay py2 on mac as well [15:15] ralsina: it would be nice to consider dropping python 2.6 (and with it, the classic non-GIR gobject bindings) at this point though [15:15] dobey: that only affects lucid, right? [15:15] lucid is the only active ubuntu version that uses 2.6, yeah [15:15] ralsina: right, I just want us to have in mind the limitations of pyobjc. And it would be nice having the possibility of switching everything to 3 when we have the chance. [15:16] and the only reason we still support 2.6 in the client at all really, is for some of the tests that run on the server which is still on lucid [15:16] something else I forgot about - I think this might be best done as a separate project, if only because of the different test requirements (i.e., shouldn't have tarmac block on pep8 errors) [15:17] but I'm not sure it needs to be separate, it just seemed simpler… [15:17] dobey: right, gatox had to do some fixes very recently because of the server running on lucid. [15:17] mmcc: it should probably be a separate project just because it doesn't have any proper direct relation to the others [15:17] dobey: yes, we can't drop 2.6 until the end of this cycle because of the server tests [15:17] ralsina: until 12.10 or until 13.04? [15:18] 13.04 [15:18] dobey: well, it imports from all of them, but yeah, it is a distinct thing. [15:18] mmcc: it imports from things other than u1-client? [15:19] facundobatista: the timeline for switchng the servers to precise is 13.04 right? [15:20] dobey: it imports strings from control panel and syncdaemontool from u1-client, which ends up getting credentials from sso [15:21] ok..... lunch here === gatox is now known as gatox_lunch [15:21] brb [15:22] mmcc: hrmm, the menu strings? i thought u1client had those strings as well? [15:25] dobey: maybe it does. I didn't look… I'll make a note [15:27] mmcc: i think it does, as the strings for the menu on ubuntu are in u1-client [15:27] we probably need to fix control panel to import them from u1-client instead of having copies [15:31] ralsina, gatox_lunch I'm aiming to get this as per design: https://docs.google.com/a/canonical.com/presentation/d/13LMJQfBA3NgbRZ82j4Il1lkutg0mR03WpJA87epw1j4/edit#slide=id.g20c9f360_0_37 [15:31] is more work, but is better to get it done the right way [15:37] mmcc: oh, I'm just reading your email, and it already addresses my pyobjc concerns. Doh :-) [15:39] ok, need to get lunch; bbiab [15:42] mmcc: looking... [15:42] that was for mandel. So, mandel... how? ;-) [15:43] ralsina, add an extra layout for the entire things that depends on the content of the name, leave the account pane with no layout [15:43] ralsina, the rest works the same [15:43] mandel: ok, want to see it [15:43] mandel: so go ahead :-) [15:44] ok [15:44] ralsina, that sounded like a challenge hehe [15:50] back after 1:45 complete waste of time [16:10] briancurtin: what happened? [16:11] "oh, you have an appointment? we don't do monday appointments since they doctors aren't here today" - "oh..." - "who set your appt up?" - "cathy" - "that's me" [16:12] so i guess the real appointment is now thursday if i can trust them [16:12] mandel: there's one catch with that design [16:12] alecu, tell me [16:13] mandel: when starting, the "getting information" bubble will move at some point, when the account info is retrieved, but the folder info is not yet. [16:13] mandel: so, it will appear to "jump". [16:13] alecu, true [16:13] alecu, and that is not good at all [16:14] lisettte, ^^ [16:14] mandel: my opinion is that it should remain in a fixed place, and yes, the tabs and the top could be "unobscured" when the account info is available. [16:15] alecu, mandel: depending on what the 'jump' looks like, it seems better for users to have all the functionality they can have in the shortest possible time [16:15] yeah, let's please not make it jump around. even the font resizing when the quota percentage is finally drawn is annoying enough. [16:16] alecu, mandel: what exactly is going to jump? [16:16] lisettte: the "getting information bubble" [16:16] lisettte, it will move down a little [16:16] lisettte: in slide 5 the bubble is many pixels below, compared to slides 3 and 4 [16:17] alecu, mandel: we should see how this works in reality, but it seems we need the partial cover anyway: right now it shows me the waiting animation briefly every time i move to a different tab [16:18] lisettte, yes, that is because it does a request for every tab change [16:18] alecu, mandel: i am not sure it is a huge problem for it to move down [16:18] might be a big change, but can we fix this instead by storing locally the username and quota and just not displaying the loader for the account info? Seems crazy to wait 10 seconds to see my name. [16:18] mmcc: your name comes free when we request the available space [16:18] alecu, mandel: the alternative is to cover it until everything is available, which was my first choice, but then we would still need the partial cover for moving between tabs? [16:19] is just that the name is the most notizable pieze of info [16:19] mmcc: and the quota should be updated when we start, right? [16:19] alecu, mandel: which would be 4 states [16:19] lisettte, alecu, yes, if you want to move between tabs that is the issue, if you add an overlay on top the tabs wont be clickable [16:20] alecu: the name comes free but slow! the quota could be out of date for a few seconds, or just display a dash instead of the actual percentage… [16:20] mandel: can you show us how irritating the jump is? it seems the least of all evils [16:20] lisettte, sure, I'll have that done by tom and we can see how bad it is [16:21] I'm close to my EOD [16:21] mandel: awesome!!!!! :) [16:21] mandel: I see what lisette proposes now: when starting, let's keep everything occluded until the folder info is retrieved [16:21] alecu, lisettte, I'll do both options and will record a video so we can choose === gatox_lunch is now known as gatox [16:22] is better to see it [16:22] mandel: saweet! [16:22] mandel: that means having some logic in the first tab to know this is the starting, and not the switching... [16:22] alecu: and the first tab could be any tab [16:22] alecu, mmcc, is not the first tab, but the main widget [16:22] which is diff [16:22] ko [16:22] er ok [16:22] mmcc: I believe that it was chosen not to cache the name, because it was something that could be changed on the website. [16:23] mandel, so..... is going to be the option with the whole overlay? [16:23] mmcc: but yes, I agree that it's slow, and ugly [16:23] hmmm. [16:24] mmcc: perhaps we can poke nessita to explain the reasons not to cache the name and total available quota in the control panel (at least until they are updated by the first webcall to the account api) [16:24] not caching the quota makes some sense, since the cached quota could be wrong often, but the cached name would never be wrong for almost everyone... [16:25] gatox: not with the whole overlay. The whole overlay when starting, the per-tab overlay when switching tabs. [16:25] alecu, yes.... that's what i mean [16:25]