Hi Ajay, On 14 Aug 2012, at 11:51, Ajay Garg <a...@activitycentral.com> wrote:
> Hi Gary, Anish, Gonzalo. > > The "impatient" UI-interaction bug has been fixed via :: > http://git.sugarlabs.org/dextrose/mainline/commit/e34ba2bc5554621a7770c8f5960f257bff9787f8 > > The latest sugar-rpm (containing the fix) can be found at :: > http://people.sugarlabs.org/ajay/root/multi-select-latest-sugar-rpm-14th-august/sugar-0.94.1-31.dx3.noarch.rpm > > > Please test on the dextrose image as usual :) Thanks. have just been testing an bumped into this new issue with the Journal UI is locking during a batch operation. You can't interact with error alerts: http://wiki.sugarlabs.org/go/File:Journal_multiselect_lock_prevent_interacting_with_error.png Regards, --Gary > > > Thanks and Regards, > Ajay > > > > On Tue, Aug 14, 2012 at 8:59 AM, Gonzalo Odiard <gonz...@laptop.org> wrote: > Probably have sense blocking the Journal ui (and show a clock cursor) > when doing a slow operation. > > Gonzalo > > > On Mon, Aug 13, 2012 at 11:27 PM, Anish Mangal <an...@activitycentral.com> > wrote: > There seem to be many bugs where something 'ugly' happens when > something is clicked "while" an operation is happening. > > Can't we just lock all UI actions *while* batch operations are taking > place (and only have an abort/cancel button)? Of course, this might be > harder said than done, and might not be the best way codewise (was > just thinking in terms of UX) > > On Tue, Aug 14, 2012 at 4:34 AM, Gary Martin <garycmar...@googlemail.com> > wrote: > > Thanks Ajay, > > > > On 13 Aug 2012, at 07:05, Ajay Garg <a...@activitycentral.com> wrote: > > > >> Hi Gary. > >> > >> Made the change via the patch :: > >> http://git.sugarlabs.org/dextrose/mainline/commit/d9426b3b0be8249110d3073015d2514402734930 > > > > That's a much smaller code change than mine ;) > > > >> The latest sugar-rpm can be found at :: > >> http://people.sugarlabs.org/ajay/root/multi-select-latest-sugar-rpm-13th-august/sugar-0.94.1-31.dx3.noarch.rpm > >> > >> > >> Please test with it, on your dextrose image as usual :) > > > > Have found a new nasty bug. If, while a batch operation is in progress, you > > uncheck some items, multi-select gets rather unhappy. My test case: > > > > 1) copy ~100 items over to the Documents folder > > 2) switch to view the Documents folder > > 3) check an entry and the select all > > 4) scroll down a few pages > > 5) click Erase > > 6) confirm the Erase > > 7) uncheck some entries while the batch is running > > 8) wait for Erase batch to complete > > > > Result: I now see the Toolbar hint that says "Selected 3 of 100" (I > > unchecked 3 items during the Erase batch operation), however all ~100 items > > are still displayed and shown checked. I then clicked Select all and got a > > spinning cursor and a seemingly stalled Journal stuck in multi-select mode. > > As I moved the cursor over the list area the activity icons started to > > redraw in black and white (no more ownership stroke and fill colour, I > > guess due to catching up with erased metadata). Needed to reboot Sugar to > > recover, and on checking Documents all items had been erased. > > > > You can get into similar multi-select stalls by being 'impatient' with the > > UI: > > > > 1) select ~100 items > > 2) click erase > > 3) confirm erase > > 4) click Deselect all while the batch is still running > > > > I'll post the shell log to you in a separate email. > > > > Regards, > > --Gary > > > >> Thanks and Regards, > >> Ajay > >> > >> On Mon, Aug 13, 2012 at 5:24 AM, Gary Martin <garycmar...@googlemail.com> > >> wrote: > >> Hi Ajay, > >> > >> On 12 Aug 2012, at 20:30, Gary Martin <garycmar...@gmail.com> wrote: > >> > >> > Hi Ajay, > >> > > >> > On 8 Aug 2012, at 10:42, Ajay Garg <a...@activitycentral.com> wrote: > >> > > >> >> Hi Gary. > >> >> > >> >> Please find the link, for the latest sugar-rpm, that contains the > >> >> fixes/changes, as per the 3 action-items marked for me, in 7th August's > >> >> design-meeting :: > >> >> http://people.sugarlabs.org/ajay/root/multi-select-with-checkbox-fix-plus-3-more-7th-august-action-items/sugar-0.94.1-31.dx3.noarch.rpm > >> >> > >> >> For brevity, here are the action items, and the corresponding patches :: > >> >> > >> >> #action improve batch tick redraw-intervals (ajay) > >> >> http://git.sugarlabs.org/dextrose/mainline/commit/cdcf2717fe4bdd42cdbb632c51b0b371e2e3352f > >> > > >> > Spotted one case here, in line 96: > >> > > >> > if (current_entry_number % twenty_percent_of_total_items) == 0: > >> > > >> > If there are only a small number of items (e.g. 11) being batched > >> > operated on then it redraws too frequently (in ~2 at a time for 11 > >> > entries), so is quite slow. Batch operations should be in blocks of 10 > >> > or more at a time (unless there are less than 10 items in which case do > >> > them all at once). This also means your test at line 80 isn't being > >> > usefully triggered and I think can be removed (as far as I can tell, > >> > please test). > >> > > >> > The test case at line 96 should be something like: > >> > > >> > if min (total_items, max (10, (current_entry_number % > >> > twenty_percent_of_total_items))) == 0: > >> > >> Sorry that test case for line 96 made little sense! Second attempt: > >> > >> if current_entry_number % max(10, twenty_percent_of_total_items) > >> == max(10, twenty_percent_of_total_items) - 1: > >> > >> So this should refresh the list no more frequently than every 10th entry > >> processed, and when there are > 50 entries the 20% starts to have an > >> effect on the distance between updates so that not too much time is wasted > >> redrawing when there are many entries being batch processed. > >> > >> Your test case at line 80 should stay so that at least the first page of > >> entries gets a reasonably quick update if there are many entries being > >> processes, and your clause at line 86 for redrawing at the last entry > >> covers the case for when there are < 10 items. > >> > >> Apologies, > >> --Gary > >> > >> > > >> > Regards, > >> > --Gary > >> > > >> >> #action change status strings to normal case and remove braces and / > >> >> for friendly language (ajay) > >> >> http://git.sugarlabs.org/dextrose/mainline/commit/767074994a0ea7f8356a1feafb7f2becae1b49f3 > >> >> > >> >> #action make Stop aleart before batch operations really stop the batch > >> >> operation (ajay) > >> >> http://git.sugarlabs.org/dextrose/mainline/commit/f4ab20a311e5090aca2e1d757c6433eb19c5522a > >> >> > >> >> > >> >> Please test as usual, on the dx3ng147 image :) > >> >> > >> >> Also, please let know for further feedback, on the mailing-list itself. > >> >> The next Tuesday is still 6 days away :D :D > >> >> > >> >> > >> >> Thanks and Regards, > >> >> Ajay > >> >> > >> >> > >> >> On Mon, Aug 6, 2012 at 3:13 PM, Ajay Garg <a...@activitycentral.com> > >> >> wrote: > >> >> Hi Gary. > >> >> > >> >> Finally... the checkbox-issue has been solved :) > >> >> > >> >> Please find the "fixed" rpm, containing the checkbox-fix at > >> >> http://people.sugarlabs.org/ajay/root/multi-select-with-checkbox-fix/sugar-0.94.1-31.dx3.noarch.rpm > >> >> > >> >> For brevity, here is the patch link :: > >> >> http://git.sugarlabs.org/dextrose/mainline/commit/381e706de7e7309d27a44ed064794a44d50aad4a > >> >> > >> >> The sugar-toolkit rpm remains the same as before. > >> >> > >> >> > >> >> > >> >> So, in addition to the "a) - i)" points of the previous mail, I add the > >> >> next point :: > >> >> > >> >> j) > >> >> Now there is prompt feedback of checking/unchecking the checkboxes and > >> >> favorite-icons. > >> >> > >> >> However, note that for favorite-icons, there is a logical hinderance to > >> >> true prompt feedback, as described in > >> >> http://bugs.sugarlabs.org/ticket/3147. > >> >> > >> >> Checkboxes' feedbacks work perfectly !! > >> >> > >> >> > >> >> > >> >> Thanks and Regards, > >> >> Ajay > >> >> > >> >> > >> >> > >> >> On Sun, Aug 5, 2012 at 12:02 PM, Ajay Garg <a...@activitycentral.com> > >> >> wrote: > >> >> Hi Gary. > >> >> > >> >> Please find attached the links to the "fixed" rpms. > >> >> Please "--upgrade --force --nodeps" on the dx3ng143 image, on which you > >> >> have been testing. > >> >> > >> >> http://people.sugarlabs.org/ajay/root/multi-select/sugar-0.94.1-31.dx3.noarch.rpm > >> >> http://people.sugarlabs.org/ajay/root/multi-select/sugar-toolkit-0.94.0-20120805.dx3.fc14.i386.rpm > >> >> > >> >> > >> >> For brevity, the patches are at :: > >> >> http://git.sugarlabs.org/dextrose/mainline/commit/38a261887ed44756147bae44277642252cae628f > >> >> http://git.sugarlabs.org/dextrose/mainline/commit/0c71cf00dfb8fe507627109748b5539e0eeba87f > >> >> > >> >> > >> >> > >> >> Following are the changes/fixes :: > >> >> All courtesy you :) > >> >> > >> >> > >> >> > >> >> > >> >> a) > >> >> 'Select none' renamed as 'Deselect all'. > >> >> > >> >> > >> >> > >> >> b) > >> >> Now, a text-widget has been added to the top of EditToolBar. > >> >> This serves the following two purposes :: > >> >> > >> >> > >> >> * 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, > >> >> and 97 is assumed to be the total number of entries. > >> >> > >> >> > >> >> 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. > >> >> > >> >> > >> >> > >> >> c) > >> >> Due to b), the progress-statuses are now NOT shown as alerts; rather as > >> >> texts in the text-widget. > >> >> > >> >> > >> >> > >> >> d) > >> >> However, any errors (such as "Entries without a file cannot be copied") > >> >> are continued to be shown as alerts. > >> >> > >> >> > >> >> > >> >> e) > >> >> Other than the progress-texts, and error-alerts, the only other > >> >> notification shown are the confirmation-alerts before beginning > >> >> with the "Batch-Copy" and "Batch-Erase". > >> >> > >> >> > >> >> > >> >> f) > >> >> During Batch-Operations (almost exclusively Batch-Copy), if an error > >> >> occurs, users are presented with two options :: > >> >> > >> >> * "Stop" - This stops the batch-operation there and then. > >> >> > >> >> * "Continue" - Proceed forward with the next journal entry. > >> >> > >> >> > >> >> > >> >> g) > >> >> As seen in f), the "Ok" of the error-alert has been replaced (only > >> >> textually) by "Continue". > >> >> > >> >> > >> >> > >> >> h) > >> >> There were exceptions of the form "KeyError: 'keep'" occuring in logs. > >> >> This was due to some cases, wherein "keep" property was not present in > >> >> a particular journal entry. > >> >> > >> >> So now, as a fix, we first check if "keep" is a valid metadata-key. If > >> >> yes, we read its value to gauge favorite-status. > >> >> Else, we assume that the journal-entry is an unfavorite by default. > >> >> > >> >> > >> >> > >> >> i) > >> >> VERY IMPORTANT NOTE :: > >> >> > >> >> Renaming a journal-entry (by clicking and modifying the contents of the > >> >> title-cell, has been disabled functionally. > >> >> This is because, the following happens when a rename is done in the > >> >> "Documents" view :: > >> >> > >> >> * Initially, the UID is same as the path of the entry in "Documents". > >> >> > >> >> * User changes the name. The change is written on the DS, and the > >> >> UID changed. > >> >> > >> >> * Now, since refresh is inhibited in multi-select view, we need to > >> >> fetch the new value of the title from the DS. > >> >> This requires the UID, through which the UID could be fetched. > >> >> Since the name of the "Documents" journal-entry has > >> >> changed, so has its UID. But in the memory, the old UID still > >> >> resides. Fetching the "new" title from the "old" UID does not > >> >> work. > >> >> > >> >> Now, I tried disabling the renaming while rendering the listview, > >> >> but that could not be done, as rendering th listview requires > >> >> knowing whether we are in multi-select mode, while multi-select > >> >> mode is set, after the listview is rendered. So, we are in a catch-22 > >> >> situation. > >> >> > >> >> So, the way it works now in multi-select mode :: > >> >> > >> >> * User is apparently able to edit the title, but that is all what > >> >> happens. > >> >> There is no efective change - neither in backend, nor in frontend. > >> >> > >> >> In the normal view, the renaming works as usual. > >> >> > >> >> > >> >> ====================================================== > >> >> > >> >> > >> >> PENDING CHANGES :: > >> >> > >> >> a) > >> >> As explained in point i) above, the renaming will not work, while in > >> >> multi-select mode (however, the bug you reported wherein trying to > >> >> rename in > >> >> "Documents" folder renders the UI unusable, has been duly fixed (of > >> >> course, by not allowing the renaming to happen). > >> >> > >> >> If this is indeed required, this will be a major change in the way we > >> >> deal with UIDs for non-journal mount-points. But given that renaming is > >> >> affected only in multi-select mode (renaming does not work at all in > >> >> multi-select; while it works as usual in normal-mode), I am a bit > >> >> sceptical to regarding this. > >> >> > >> >> > >> >> > >> >> b) > >> >> A solution to the following bug :: > >> >> > >> >> > >> >> 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. > >> >> > >> >> still eludes me :( > >> >> > >> >> This is an important issue, since (although there is no unusable UX, or > >> >> any such major workflow blocker), the select/deselect "visual" > >> >> "feedback" is an important thing, that should be conveyed as soon as > >> >> possible. Though Gary's feedback on adding a text-widget on the top > >> >> EditToolBar, does help show the number of entries selected, and thus > >> >> gives a "textual" "feedback" :) > >> >> > >> >> I would request all sugar-devel members to please post a solution to > >> >> the issue, for which the discussion is going on, in the thread :: > >> >> http://lists.sugarlabs.org/archive/sugar-devel/2012-July/038626.html > >> >> > >> >> > >> >> > >> >> Thanks and Regards, > >> >> Ajay > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> On Sat, Aug 4, 2012 at 9:59 PM, Gary Martin > >> >> <garycmar...@googlemail.com> wrote: > >> >> 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 > > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
