Hi Ajay, On 4 Aug 2012, at 10:21, Ajay Garg <a...@activitycentral.com> wrote:
> On Fri, Aug 3, 2012 at 8:53 PM, Ajay Garg <a...@activitycentral.com> wrote: > Thanks a ton Gary. > This is REALLY useful :) Fab :) > Please find the comments inline. > > > On Fri, Aug 3, 2012 at 6:29 PM, Gary Martin <garycmar...@googlemail.com> > wrote: > Hi Ajay/Anish, > > On 18 Jul 2012, at 11:57, Anish Mangal <an...@activitycentral.com> wrote: > > > I would like to propose the long-discussed-finally-implemented ;-) > > journal entry batch operation and multi selection feature for > > inclusion in sugar-0.98. All the necessary and relevant details should > > be present in the associated feature page: > > > > http://wiki.sugarlabs.org/go/Features/Multi_selection_screenshots > > > > AFAIK, This feature was initially brought up in discussions in EDUJam > > in 2011 and an initial implementation was made by Martin Abente. The > > current implementation, done by Ajay, has been derived from that > > keeping the UI experience largely the same while significantly > > speeding up operations like select/deselect. > > > > Should you have any design related questions about this, feel free to > > reply to this thread. > > At last Tuesday's design meeting we didn't make it back around to this agenda > item, so here's my feedback/notes after testing the DX3 image with the new > rpms: > > - FIXED. Once in multi-select mode, the favourite stars no longer visibly > updates, though changes update later once multi-select mode is exited. > > Great !! > > > > > - FIXED. Auto deselection after batch operation. > > Great !! > > > > > - UNRESOLVED BUG. Tick-box slow/erratic behaviour in dx3ng143 with latest rpm > fixes image on XO1, still needs mouse movement to redraw. This is also an > issue when using the "Select all" toobar button, as the list view tick-boxes > do not update until after the "Select all. You have selected N entries. (Ok)" > dialogue is clicked. > > Yep.. this is becoming a real pain. > I have tried the solutions listed at > http://lists.sugarlabs.org/archive/sugar-devel/2012-July/038626.html, but > none seem to work :-\ > Anyways, I am still trying .. > > [Ajay ACTION 1] : Fix this. > > > > > - NEW BUG. Renaming an entry while in multi-select mode does not display the > name change, only updates the name displayed after multi-select mode is > exited. > > Thanks. Reproduced the bug at my side. > > [Ajay ACTION 2] : Will fix. > > > > > - NEW BUG. If you rename while in multi-select and then try to copy, the > entry can't be copied and raises an error "Entries without a filename cannot > be copied." > > Hmm.. I think this is a false-negative. > I tried the following :: > > * Entered "multi-select" mode. > > * Selected an entry (by ticking the check-box). > > * Re-named the entry (however, the rename was not immediately > visible, due to the above bug). > > * Copied the entry to "Documents". > > * Exited "multi-select" mode. > > * Clicked "Documents" icon. > > * The entry (WITH THE MODIFIED NAME) was present. > > I guess the error message "Entries without a file cannot be copied" occurred > on an entry, that would have anyways given this message, even if you hadn't > renamed the entry. > > [Gary ACTION 1] : Please let me know if you still face the error :) OK, sorry I must have missed an extra step (I can't reproduce this just now). Will email you if I can find a reliable way to reproduce it. However, I seem to have found a more nasty bug, while trying to test... Switch to the Journal Documents view; select an item; rename the selected item; the selected item will be deselected – though you'll still be in multi-select mode (but with nothing selected); click the toolbar button Select none; Journal will now be in a bad/unusable state, spinning busy cursor, can't escape multi select mode, shell log shows tracebacks IOError: Couldn't open metadata directory. I needed to restart Sugar to get back to normal. I'll post some shell logs in a separate email to you. > - UNRESOLVED DESIGN QUESTION. Should filters continue to work once in > multi-select mode e.g: Filter for star favourite items in Journal; multi > select all stared items; un-favourite some entries while in multi-select > mode. Should they be removed from the multi-select view, or stay? Currently > they stay, but this causes a visual 'jump' when exiting multi-select mode as > the initial filter is re-applied to the view. Same issue if filtering the > Journal by title, and you rename some entries while in multi-select mode. > > Well, I would say not to effect the change during multi-select mode, because > of the following reasons :: > > * Currently, the code is tightly bound to having the "current" > listmodel entries in the cache. > A re-fresh, would cause the cached entries to be > re-distributed, requiring a very major code change. > > * The original motive of "allowing" the user to set/unset > favorite status, and rename entry, is to help the user do the processing on > the entry, > as she selects the entry. So, I guess it would be ok to > effect the filters of these "secondary" features, AFTER the original action > (copy, > erase) is completed, and "multi-select" mode exited. > > [Gary ACTION 2] : Anyhow, please let me know if you think otherwise :) > > > > > - FEEDBACK. In multi-select mode the toolbar button string 'Select none' > would be better renamed as 'Deselect all'. > > Ok. > > [Ajay ACTION 3] : Will fix. > > > > > - TESTING. A loaded Journal with ~100 items, and a USB stick with 900+ items > was tested. Selecting individual items one by one is reasonable (ignoring the > above unresolved redraw/event bug). Batch selecting, deselecting, erasing > operations are pretty quick (batch feedback progress is helpful especially > for the 900+ item case). Batch copying is the slowest operation (as to be > expected), feedback progress here is essential for even a few items. > > [Gary ACTION 3] : Ok, so we show the progress for all = "Select", "Deselect", > "Copy", "Erase", right? Yes, but in the primary title bar as a text widget. > - FEEDBACK. In the primary multi-select toolbar, add a separator and text > widget to show how many items are selected, and how many are in the current > multi-select view e.g. "Selected 3 of 123" so the current multi-select state > is always visible to the user. This same widget can be used for progress > feedback during batch operations e.g. "Copying 9 of 22: <title>", "Erasing 3 > of 15: <title>", "Deselecting 5 of 17". This removes the need for all > progress alerts during batch operations, see below. > > Gary, please clarify a bit more. > For eg, if a user wishes to do batch-copy on 15 entries (out of 97 entries), > so would the snapshots be like :: > > > <First row of text widget> Selected 15 of 97 > <Second row of text widget> Copying 1 of 15 <title> > > > <First row of text widget> Selected 15 of 97 > <Second row of text widget> Copying 2 of 15 <title> > > > <First row of text widget> Selected 15 of 97 > <Second row of text widget> Copying 3 of 15 <title> > > > <First row of text widget> Selected 15 of 97 > <Second row of text widget> Copying 4 of 15 <title> > > .. > .. > .. > .. > > > <First row of text widget> Selected 15 of 97 > <Second row of text widget> Copying 14 of 15 <title> > > > <First row of text widget> Selected 15 of 97 > <Second row of text widget> Copying 15 of 15 <title> > > > > OR WOULD IT BE SIMPLY > > > > <First row of text widget> Copying 1 of 15 <title> > > > <First row of text widget> Copying 2 of 15 <title> > > > <First row of text widget> Copying 3 of 15 <title> > > > <First row of text widget> Copying 4 of 15 <title> > > .. > .. > .. > .. > > > <First row of text widget> Copying 14 of 15 <title> > > > <First row of text widget> Copying 15 of 15 <title> > > > [Gary ACTION 4] : Please clarify. > > > I think I understood what is required. > > * The widget is supposed to display only one line, at ANY time. > > * Usually, while in "multi-select" mode, it will display "<x> of 97 > selected", where "x" is the number of entries currently selected. > Here, as we select/deselect by single-click, or "select all" / "deselect > all" button, the update happens consequently. > > So, as is obvious, this modification helps show the number of selected > entries, even when entries are selected/deselected one at a time > (previously, the status was shown, only when "select all" or "deselect all" > was done). > > * During batch-copy, or batch-erase, this widget shows the running status of > the entry currently being processed. > > * This seems to be a sleeker design, as it does do away with showing the > running status as an alert. > After all, alerts are meant to convey a potentially major action .. > > > So, modified action for Gary :D :: > [Gary ACTION 4] : Please confirm, as to if my understanding is > correct. Yes, that's it! :) Regards, --Gary > > > Sorry for the inconvenience. > > Thanks and Regards, > Ajay > > > > > > > - FEEDBACK. {confirmation_before, progress, confirmation_after} > ... select_none {N, N, N} > ... select_all {N, N, N} > ... erase {Y, N, N} > ... copying {Y, N, N} > > Ok. Got it :) > > [Ajay ACTION 4] : Will make the changes. > > > > > - FEEDBACK. We should allow a user to abort a batch operation when an error > occurs. Use cases, encountering many errors during a batch operation when a > volume runs out of space, or becomes unavailable. One solution on other > platforms is a check box for in the error dialogues "[√] Apply to all" (to > ignore future errors of this type during this batch process), and/or an > additional button "Stop". I'd suggest our batch operation errors dialogues > add a "Stop" button to allow aborting the batch process, and that the current > "Ok" button is renamed "Continue" to be more clear. > > Ok. > So, > * [Ajay ACTION 5] : We add a "Stop" button, which occurs > on any error alert message. > If the user clicks the "Stop" button, the > batch-operations ends there ans then. > > * [Ajay ACTION 6] : "Ok" button will be renamed to > "Continue" button. > > > - UNRESOLVED DESIGN QUESTION. Do we want to allow a user to abort a batch > operation while it is in progress? Use case, copying/erasing many items over > a slow network, or usb device, and deciding if it is not worth the wait. I > think, for now, we can avoid this extra UI work as the batch features do > provide the option to cancel before they begin. We should revisit this if it > turns out to be a frustration for users. The UI design would likely be to add > the cancel icon (X) to the primary toolbar while a batch operation is in > progress. > > +1. > Anish too had suggested the same, but then we forfeited the idea, as this > would make this (unnecessarily?) complex. > > Anyways, in-field experiences are the real teachers :D :D > > > > Regards, > --Gary > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > > Gary, waiting for your responses :) > > Thanks again. > > Thanks and Regards, > Ajay >
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
