The Trunk: Tools-cmm.689.mcz

Chris Muller uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-cmm.689.mcz

==================== Summary ====================

Name: Tools-cmm.689
Author: cmm
Time: 14 April 2016, 5:45:50.151772 pm
UUID: 83a287db-4e6e-4a0f-a666-68405c7261c7
Ancestors: Tools-mt.688

- Don't blow up just to render an icon in a list.
- Put keyboard shortcut hint into the 'remove from this browser' function of MessageLists.

=============== Diff against Tools-mt.688 ===============

Item was changed:
  ----- Method: Browser>>messageIconAt: (in category 'message list') -----
  messageIconAt: anIndex
 
+ ^ self messageIconFor: (self messageList at: anIndex ifAbsent: [^nil])!
- ^ self messageIconFor: (self messageList at: anIndex)!

Item was changed:
  ----- Method: MessageSet>>addExtraShiftedItemsTo: (in category 'message list') -----
  addExtraShiftedItemsTo: aMenu
  "The shifted selector-list menu is being built.  Add items specific to MessageSet"
  self growable ifTrue:
  [aMenu addList: #(
  -
+ ('remove from this browser (d)' removeMessageFromBrowser)
- ('remove from this browser' removeMessageFromBrowser)
  ('filter message list...' filterMessageList))].
  aMenu
+ add: 'sort by date'
- add: 'sort by date'
  action: #sortByDate!

There seems to be a bug in the list if it calles #messageIconAt: with an invalid index. We should rather investigate and fix that. :-)

Best,
Marcel

Agree, and the best way to do that is for whomever wants to try to fix
it to simply roll back the method and wait for it to blow up.  Its not
easy to reproduce, but it happens even though I don't use icons in
message lists, so
its hard for me to prioritize it above my other obligations at this time.

In the meantime, I do not wish for a feature like this to be
disruptive to anyone else.

PS -- that it is so hard to understand and fix maybe speaks to another
problem with it..?   ;-/

On Fri, Apr 15, 2016 at 3:02 AM, marcel.taeumel <[hidden email]> wrote:

It may be that, after investigating the root cause, this change _is_
the best fix.  Between filtering, smart-splitters, scrolling, lists
that are shorter than the widget height, etc., there ends up to be so
many combinations of conditions a "defensive" style starts to become a
better design for managing this much complexity.  Not for hiding a
problem, of course, but by structuring the method compositions from
the get-go to have, for example, idempotent properties, it becomes
more bullet proof against all the crazy conditions of a complex UI...

Okay, it seems difficult to reproduce the bug. Hmmm...

Btw: You don't need the additional return before nil. You do not actually need nil because empty blocks return nil. However, this seems to be more readable. :-)

Best,
Marcel

Oops, you do. Nevermind.

Best,
Marcel