[Sugar-devel] [DESIGN] Proposal: Multi-Selection and Batch Operations on Journal entries
Ajay Garg
ajay at activitycentral.com
Mon Aug 27 09:06:14 EDT 2012
Hi all.
Today, I did "git pull" on the sugar master branch.
After that, unfortunately, I could not apply the patch at
http://patchwork.sugarlabs.org/patch/1662/
Thus, it is my sincere request to take a call on this ASAP, so that any
last minute hurdles are avoided.
Thanks and Regards,
Ajay
On Mon, Aug 20, 2012 at 1:35 AM, Ajay Garg <ajay at activitycentral.com> wrote:
> Hi all.
>
> Just saw Simon's patch at http://patchwork.sugarlabs.org/patch/1670/
>
> Thereby, it's a gentle request ::
>
> * to get this multi-select feature approved (with all
> the latest feedback-changes/bug-fixes).
> * to get the multi-select patch(es) reviewed.
> * to get the multi-select patch(es) pushed (if all ok).
>
>
> so that any such enhancements (confirmation alert before erasing,
> currently in single-mode) can be easily merged (for single- AND
> batch-mode); and there is minimal slogging involved that comes in with
> merging patches :)
>
>
> Thanks and Regards,
> Ajay
>
>
>
>
>
> On Fri, Aug 17, 2012 at 11:33 PM, Ajay Garg <ajay at activitycentral.com>wrote:
>
>> Hi Gary, Simon, Manu and others.
>>
>> Please find below the links for the rpms, that contain the multi-select
>> feature, on F17.
>> Also, find accompanied the corresponding patches, ported to mainline for
>> the corresponding repo(s).
>>
>>
>> a)
>> Sugar ::
>>
>>
>> http://people.sugarlabs.org/ajay/root/multi-select-f17-rpms/sugar-0.96.3-1.fc17.noarch.rpm
>> http://patchwork.sugarlabs.org/patch/1662/
>>
>>
>>
>> b)
>> Sugar-Toolkit ::
>>
>>
>> http://people.sugarlabs.org/ajay/root/multi-select-f17-rpms/sugar-toolkit-0.96.3-2.fc17.i386.rpm
>> http://patchwork.sugarlabs.org/patch/1663/
>>
>>
>>
>> c)
>> Sugar-Artwork ::
>>
>>
>> http://people.sugarlabs.org/ajay/root/multi-select-f17-rpms/sugar-artwork-0.96.5-1.fc17.i386.rpm
>> http://patchwork.sugarlabs.org/patch/1664/
>>
>>
>>
>> I have tested this feature extensively in the last 3 days on XO-1 image
>> for F17.
>>
>> In particular, all issues reported by Gary have been fixed.
>> Please see the last few commits at http://git.sugarlabs.org/~ajaygarg
>>
>>
>>
>>
>> All credit needs to go to Gary, courtesy whom this feature has reached
>> this level of robustness :)
>> In particular, following things are intended via the above 3 patches ::
>>
>> * Solves the basic purpose ( of course :P
>> )
>>
>>
>> * There should be no sequence of events, that renders the UI in an unusable state.
>> * There should never be an instance, wherein the user may act "impatient", and may cause
>> an undesirable sequence of actions (may/may-not be leading to an unusable state).
>> * Speed optimisation, as far, and as logically, as possible.
>>
>>
>> Again, all credit goes to Gary, for having rendered this feature such robustness !!!
>>
>> Also, thanks to
>>
>> * Walter Bender and Gonalo Odiard (for the awesome feature design).
>>
>> * Martin Abente (from whose efforts the code-patch(es) are derived :P).
>>
>>
>> * Anish (who was instrumental in pushing for this feature to be re-visited, and included in the 0.98 cycle).
>>
>>
>>
>> Please test, so that this feature may, in fact, be included in the 0.98
>> cycle :) :)
>>
>>
>>
>> Thanks and Regards,
>> Ajay
>>
>>
>>
>>
>>
>>
>> On Tue, Aug 14, 2012 at 10:16 PM, Gary Martin <garycmartin at googlemail.com
>> > wrote:
>>
>>> Hi Ajay,
>>>
>>> On 14 Aug 2012, at 11:51, Ajay Garg <ajay at 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 <gonzalo at 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 <
>>> anish at 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 <
>>> garycmartin at googlemail.com> wrote:
>>> > > Thanks Ajay,
>>> > >
>>> > > On 13 Aug 2012, at 07:05, Ajay Garg <ajay at 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 <
>>> garycmartin at googlemail.com> wrote:
>>> > >> Hi Ajay,
>>> > >>
>>> > >> On 12 Aug 2012, at 20:30, Gary Martin <garycmartin at gmail.com>
>>> wrote:
>>> > >>
>>> > >> > Hi Ajay,
>>> > >> >
>>> > >> > On 8 Aug 2012, at 10:42, Ajay Garg <ajay at 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 <
>>> ajay at 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 <
>>> ajay at 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 <
>>> garycmartin at googlemail.com> wrote:
>>> > >> >> Hi Ajay,
>>> > >> >>
>>> > >> >>
>>> > >> >> On 4 Aug 2012, at 10:21, Ajay Garg <ajay at activitycentral.com>
>>> wrote:
>>> > >> >>
>>> > >> >>> On Fri, Aug 3, 2012 at 8:53 PM, Ajay Garg <
>>> ajay at 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 <
>>> garycmartin at googlemail.com> wrote:
>>> > >> >>> Hi Ajay/Anish,
>>> > >> >>>
>>> > >> >>> On 18 Jul 2012, at 11:57, Anish Mangal <
>>> anish at 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 at 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 at lists.sugarlabs.org
>>> > http://lists.sugarlabs.org/listinfo/sugar-devel
>>> >
>>> >
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20120827/f7e7f1e5/attachment-0001.html>
More information about the Sugar-devel
mailing list