Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate

#sugar-meeting meeting, 2012-08-07 16:30:14

Minutes | Index | Today     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
16:30 meeting_ Meeting started Tue Aug  7 16:30:14 2012 UTC. The chair is garycmartin. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30 Useful Commands: #action #agreed #help #info #idea #link #topic #endmeeting
16:30 garycmartin Hey folks, who do we have left for the design meeting today?
16:30 m_anish is here
16:30 ajay hi garycmartin
16:31 garycmartin m_anish: ajay hi!
16:31 m_anish garycmartin, hi!
16:31 manuq hi garycmartin et all!
16:31 tch___ hiho
16:32 garycmartin Hi tch___ glad you could make it, manuq glad you're still here :)
16:32 m_anish tch___, buen dia!
16:32 erikos lurks
16:32 tch___ :)
16:32 garycmartin OK then, let's dive right in to the first agenda item
16:33 #link http://wiki.sugarlabs.org/go/Design_Team/Meetings
16:33 #topic Lease expiry information display in My Settings
16:33 #link http://lists.sugarlabs.org/arc[…]-July/038571.html
16:33 #link http://wiki.sugarlabs.org/go/F[…]formation_Display
16:33 m_anish So I think I answered dsd's query and didn't get a reply, the only bit of confusion i think is where to place it
16:33 garycmartin The mail-list thread on this one has been pretty active, some good feedback I think.
16:34 m_anish fwiw, I liked gonzalo's suggestion of creating a separate security heading, but might use up more space just for a single item ... so open to ideas :-)
16:34 garycmartin, +1
16:34 garycmartin m_anish: Yes I think that's the point to resolve, where it should go.
16:35 m_anish: I liked the suggestion from gonzalo__ for a new Security section.
16:35 Ariel_Calzada1 <Ariel_Calzada1!~aricalso@201.184.226.52> has joined #sugar-meeting
16:35 m_anish garycmartin, +1 from me to it
16:35 Ariel_Calzada has quit IRC
16:36 tch___ garycmartin: me too, sounds like it could help to avoid confiusion
16:36 ajay garycmartinm_anish, tch__: +1
16:36 m_anish garycmartin, there seemed to be some other rearranging of fields needed (mentioned in the ml thread) but those are different frm the lease info
16:36 garycmartin It can go below the Identity section, and in the future could hold a few more items of information if available. If there is no Security related information then the Security section does not need to be shown.
16:37 m_anish garycmartin, +1
16:38 garycmartin OK, do we have any objections here for adding (when needed) a Security section to the About My Computer module?
16:38 m_anish No
16:38 qwebirc1009583 <qwebirc1009583!3bb2a7ad@gateway/web/freenode/ip.59.178.167.173> has joined #sugar-meeting
16:38 tch___ nop
16:38 ajay nopes
16:39 garycmartin OK, +1 from me
16:39 manuq: Any thoughts on this one or are you still catching up sleep after GUADEC? ;)
16:40 tch___ haha
16:41 garycmartin Suggestion: I'll make a screen shot mockup of this CP with the added section and post it to the mail-list thread.
16:41 m_anish either gnome or sugar needs a better notification system :-P
16:41 garycmartin m_anish: ;)
16:41 m_anish garycmartin, okay, makes sense
16:42 garycmartin #action Post a screenshot mockup of the proposed Security section for showing the lease information (gary)
16:42 manuq garycmartin: is fine for me
16:42 garycmartin OK onwards and upwards!
16:42 manuq: thanks :)
16:43 #topic Journal multi-select
16:43 #link http://wiki.sugarlabs.org/go/F[…]ction_screenshots
16:43 m_anish braces for a long discussion ;)
16:43 garycmartin #link http://lists.sugarlabs.org/arc[…]-July/038558.html
16:44 ajay: So you'll be glad to hear I _do_ have your two latest rpms (sugar and sugar-toolkit) installed happily on the XO-1 DX3 here, but I've just had minimal time to experiment with it and test!
16:45 ajay garycmartin: awesome!! mailing-list is always up to the rescue, to have  post-meeting discussions :)
16:46 garycmartin ajay: absolutely (mail-list is best as it provides many eyes)
16:46 so...
16:46 ajay garycmartin: (just for brevity), I have incorporated all the BUG-fixes/FEEDBACK-changes, as per you. So, as of now, I am done from my side. The ball is in your court now :)
16:47 garycmartin I can say the feedback in the Toolbar is looking great, no more feedback dialogues popping up all the time :)
16:47 ajay +1. me too realised this is MUCH better and sleeker :D
16:47 m_anish garycmartin, btw, sorry to interrupt, dsd just replied to the lease info thread, and he also acknowledges the importance of this feature... there are some tech details we need to work out (i'll reply to the thread)
16:48 garycmartin ajay: Yes. So the one obvious side step you made was your work around for the 'what if you rename' bug ;)
16:48 m_anish ajay, garycmartin how's the speed (just curious)
16:48 garycmartin m_anish: Speed is a second item I'd like to raise...
16:49 ajay garycmartin: yes. and I mentioned the reason too, in the m-l, and the patch. It is a logical issue (regarding proper-fix).
16:50 garycmartin: Please read the "VERY IMPORTANT NOTE" in http://git.sugarlabs.org/dextr[…]4277642252cae628f
16:50 garycmartin So 1) the workaround for the bug triggered by renaming in select mode while on documents volume needs a proper fix (I can't believe the maintainers would let this on slip past code wise when they review).
16:50 ajay: Yes, I saw the note :)
16:50 Regarding speed...
16:51 ajay garycmartin: That would be a big change (from what I see as of now). Anyhow, I will reply on the m-l, and seek opinions if someone has a "workaround" idea, that could fix this properly.
16:52 garycmartin ajay: With 100 Journal items, your latest patch with the fix for the tickbox redraws works well, but takes about 1second to draw the tick.
16:52 ajay garycmartin: Right now, that would require how UIDs are constructed for non-journal folders.
16:52 garycmartin: (regarding) speed, that's expected. The window is hidden, then made visible, per entry. Only then the "redraw" takes effect
16:54 garycmartin: but that i guess is ok anyways, since there is a (bigger, more time-consuming) refresh in non-editing mode (for eg, when a favorite-icon is clicked).
16:55 garycmartin The 1sec (on an XO-1) is not great, but not fatal (improvements would be nice polish to the feature). Where the problem shows up is when using Select all, or Deselect all. The batch operation redraws for ever single update one by one, a second each time. It it possible to just update the Toolbar status text, and only redraw the list view at the end?
16:57 dirakx1 has quit IRC
16:58 garycmartin ajay ^^
16:58 ajay garycmartin: that should be possible. But there will not be the "textual" and "visual" feedback per entry side by side; though it would be alright at the end (after all entries are selected/deslected)
16:58 garycmartin: so yes, I would do that (if it's ok for you).
16:59 garycmartin: sorry for a little delay, I had been disconnected :-\
17:00 garycmartin ajay: If the status in the toolbar is counting through the items as it goes, this gives visual feedback and 'motion' to the UI, you eye would be naturally drawn up there to the visual changes.
17:00 ajay garycmartin: yep, you are right.
17:01 dirakx <dirakx!~rafael@190.159.157.143> has joined #sugar-meeting
17:01 ajay garycmartin: fine.. so i will make the change (shouldn't take more than 15 mins)
17:02 garycmartin ajay: So I think it's OK that in large batch operations the main list view doesn't have to be in immediate sync with the progress number. You could do an alternative an perhaps redraw avery 20 items (or a similar number)?
17:03 ajay garycmartin: hmm.. that would be better. But, it now comes down  to heuristics. What number do u suggest?
17:04 garycmartin How fast is it when there are no redraws? (I guess I'm asking if ~90% of the time is lost in the redraw)
17:05 ajay garycmartin: I think 90% is too less the time-saved. I would say the time-saved is of the order of 99%
17:05 garycmartin ajay: Do we know what items are visible? And only redraw when they change?
17:05 m_anish has to leave (sorry)... will come back and see the logs later
17:06 ajay garycmartin: in select-all/deselect-all, all the items change :)
17:06 garycmartin m_anish: Thanks for staying around this long!.
17:06 ajay garycmartin: in single-mode, we HAVE to redraw per click
17:06 tch___ in select/deselect all does it refresh once per each item?
17:07 garycmartin ajay: "in single-mode, we HAVE to redraw per click" Yes understood. It's the Select all, Deselect all I'm worried about just now.
17:07 ajay garycmartin: Ohh.. you mean.. the redraw per entry? Well, that's not feasible. The treeview-treecolumn code is too tightly coupled
17:07 garycmartin tch___: yes, currently it's redrawing for each, 1sec for every change.
17:09 tch___ in that case I would really go for the chunks idea,
17:09 ajay garycmartin: anyways.. given that the users are anyways used to a "much-more-time-consuming" refresh (when the backend-frontend) both are involved when we click the favorite-icon, I am not thinking to much into this "frontend" refresh
17:09 garycmartin ajay: Ah so the backend forces a redraw on each change, and there is no way to stop it – I thought you have some evil code doing just that that was triggering the fav star redraw bug ;)
17:10 ajay garycmartin: no.. no.. right now, the "refresh" DOES NOT involve the backend; whereas the favorite-icon (in single-mode) does.
17:11 garycmartin: so, in that sense, we are still much better off (I think with the 900~ entries u r testing, the refresh in single mode will take much longer). just try.
17:12 garycmartin ajay: So can we can prevent the redraw of each entry tick in the view when the Select all button is clicked, so my 100 items doesn't leave me sitting there for almost two minutes?
17:12 is sorry but loosing grip on the implementation details here.
17:13 ajay garycmartin: yes, that's easy. We would then do one last redraw?
17:13 garycmartin ajay: Yes!
17:13 ajay garycmartin: great. so, please set this as the action-item
17:13 :D
17:13 tch___ :)
17:14 garycmartin ajay: The only extra question was if we should do some chunk updates, say a redraw every 10 or 25 batch entries?
17:14 ajay: you know, sort of the best of both worlds :)
17:14 ajay garycmartin: that too is possible. I think 10 would be a reasonable number? or 25?
17:14 garycmartin: whatever u say :D
17:15 tch___ It could be proportional to the no. of entries :P
17:15 garycmartin tch___: :P
17:15 tch___ just saying xD hehe
17:15 ajay garycmartin, tch___: every 1% of the total entries? what say?
17:16 garycmartin, tch___: that would be a ten-fold increase in speed
17:16 garycmartin thinks...
17:17 tch___ if its not too expensive to query that no. of items I would go with something proportional... If not, we could put something around 20, and test until its feels good
17:17 garycmartin ajay: How about always after first 10 entries (if your looking at top of Journal that is the first page folks will usually see), and then...
17:19 ajay garycmartin: after every 10 entries?
17:19 tch___ ajay: i guess hes thinking in 2 stages mode
17:20 ajay tch___: ohkk.. :P
17:20 garycmartin …then in 20% steps (or 10 entries if 20% is less)
17:22 Yes a two step, get the first page of entries updated (most folks will be looking at the top), and then every N entries, where N is at least 10, or 20% of total entries.
17:22 ajay garycmartin: ok.. for the first page, a redraw every 10 entries?
17:24 garycmartin ajay: Not quite, the first 10 entries, and then in 20% steps of total (but if 20% is less than 10, update in 10s)
17:24 tch___ we should keep this simple
17:24 garycmartin tch___: +1 :)
17:24 ajay garycmartin: a redraw pr entry, for the first 10 entries?
17:25 garycmartin OK, lest just go for 20% steps if this is too confusing...
17:25 ajay garycmartin: i understood the second part
17:25 tch___ please. :)
17:26 garycmartin ajay: No, a redraw after 10, and then in 20% steps. No single item redraws, all in batches.
17:26 ajay garycmartin, tch___: ok, so we fresh after every 20%. that would make it a total of 5 redraws in total, right?
17:26 tch___ for 100 items, yes
17:26 ajay garycmartin, tch___:   okkk
17:26 finally,
17:26 i wish to clarify
17:27 garycmartin, tch___: a redraw after first 10 entries; then after every 20% of entries, right?
17:27 tch___ ajay: i think thats what gary meant :)
17:28 ajay tch___: okies.. sorry.. got a bit confused.
17:28 garycmartin ajay: yea if implementation is not horrible :)
17:28 tch___ yup, please lets keep it simple on top of everything
17:29 ajay garycmartin: hmm.. it should not much be. luckily, the code is written in stages for any batch-feature; so should be a matter of making change at one place only
17:29 garycmartin ajay: Yes that 20% but not less than 10 is meant to avoid single slow redraws when you have like 15 items in total.
17:30 ajay garycmartin: okies.
17:30 tch___ sounds good!
17:30 garycmartin fav :)
17:31 ajay: OK one quick thing while I'm looking at it (just playing with the feature).
17:31 gonzalo__ ajay, has you tried disconnect the model from the view while updating the model? is possible?
17:32 ajay gonzalo__: disconnecting the model while in view? Hmm.. Could you give an example, please?
17:32 gonzalo__ ajay, i am looking at http://stackoverflow.com/quest[…]e-of-sorting?rq=1
17:33 ajay, but something similar is here http://blog.riff.org/2007_02_0[…]_gtktreeview_fast
17:33 tch___ gonzalo__: If i understand your concern, I think I did it for my implementation, but it was a horrible hack to disconnect the callbacks
17:33 gonzalo__ ajay, actually the second link is not applicable
17:34 tch___, i don't know the implementation, just asking
17:34 garycmartin ajay: The string has shouty capital letters for COPYING and ERASING, can we keep it normal case as per the original email thread. The braces and / can also go, so it's all in friendly text "Copying 4 of 27", "Erasing 7 of 9"
17:34 ajay gonzalo__: that's where the "refresh-inhibit" in multi-select mode helps. It was exactly because of this "reordering", that I had disabled refresh in multi-select mode.
17:35 garycmartin: ohh.. that should be trivial :D :D
17:35 garycmartin ajay: Oooops, Bug alert. The (Stop) feature for errors does not appear to work. I just erased my entire Journal! ;)
17:36 gonzalo__ ajay, ok
17:36 ajay garycmartin: oops.. what action were you trying to do?
17:36 garycmartin Erase.
17:36 (it's ok, just test data)
17:37 ajay garycmartin: you got an error in erase?
17:37 tch___ maybe he didn't confirm and still got deleted?
17:37 garycmartin Hmmmm…. retesting....
17:38 m_anish looks like some brainstorming is going on (/me listens ;-))
17:38 ajay garycmartin: never mind. reproduced it at my end.
17:38 should kill himself
17:39 garycmartin ajay: No error. Hit select all, Erase, and then Stop.
17:39 :)
17:39 ajay: Land the feature first!! ;)
17:40 m_anish ajay, for everytime you want kill yourself, remember you're saving lives in the real world :-P
17:40 tch___ lol..
17:40 ajay garycmartin: +1. And as erikos said, sometimes bug-fixes are better, when you land the feature :)
17:40 m_anish: :)
17:40 garycmartin ajay: Same bug for Copy (clicking Stop still copies over the files)
17:41 ajay garycmartin: yep. that is expected. there is just one code controlling both. so a single fix solves both (OOPS does have its advantages) :D :D
17:41 garycmartin Fab :)
17:42 OK, we are 10min over time so should call an end to the meeting.
17:42 ajay garycmartin: so three action-items as of now :: 1) fix the redraw-intervals   2) change strings    3) fix "stop" error.
17:42 garycmartin Any requests I should add to the agenda for next week?
17:42 tch___ preserve the current list haha
17:43 ajay tch___: :D
17:43 garycmartin #action improve batch tick redraw-intervals (ajay)
17:44 #action change status strings to normal case and remove braces and / for friendly language (ajay)
17:45 #action make Stop aleart before batch operations really stop the batch operation (ajay)
17:46 #action More testing feedback to mail-list using larger number of Journal entries (garycmartin)
17:46 Ok a quick count down...
17:46 5
17:46 tch___ 4
17:46 ajay 3
17:47 m_anish 3
17:47 2
17:47 garycmartin Ooop stuck at 2 :)
17:47 m_anish manuq.notify() :-P
17:47 manuq 1 (I was just lurking) :)
17:47 garycmartin #endmeeting
17:47 meeting_ Meeting ended Tue Aug  7 17:47:55 2012 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot. (v 0.1.4)
17:47 Minutes: http://meeting.sugarlabs.org/s[…]-07T16:30:14.html
17:47 Log:     http://meeting.sugarlabs.org/s[…]12-08-07T16:30:14

Minutes | Index | Today     Channels | Search | Join

Powered by ilbot/Modified.
Webmaster