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 <[email protected]> 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 <[email protected]>wrote: > >> Hi Ajay, >> >> >> On 4 Aug 2012, at 10:21, Ajay Garg <[email protected]> wrote: >> >> On Fri, Aug 3, 2012 at 8:53 PM, Ajay Garg <[email protected]>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 >>> <[email protected]>wrote: >>> >>>> Hi Ajay/Anish, >>>> >>>> On 18 Jul 2012, at 11:57, Anish Mangal <[email protected]> >>>> 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 >>>> [email protected] >>>> http://lists.sugarlabs.org/listinfo/sugar-devel >>>> >>> >>> >>> Gary, waiting for your responses :) >>> >>> Thanks again. >>> >>> Thanks and Regards, >>> Ajay >>> >> >> >
_______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
