The Trunk: Tools-eem.526.mcz
Locked
 
|
Eliot Miranda uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-eem.526.mcz ==================== Summary ==================== Name: Tools-eem.526 Author: eem Time: 30 July 2014, 7:46:31.551 pm UUID: 458dab1f-dc91-4197-88d2-076aa9c7317b Ancestors: Tools-eem.525 Allow extending selection via shift in ChangeList>>selectMethodsForThisClass. Allow a class to specify its own integer base preference in the inspector and debugger. =============== Diff against Tools-eem.525 =============== Item was changed: ----- Method: ChangeList>>selectMethodsForThisClass (in category 'menu actions') ----- selectMethodsForThisClass - | name | self currentChange ifNil: [ ^self ]. + self currentChange methodClassName ifNotNil: + [:name| + self selectSuchThat: + (Sensor leftShiftDown + ifTrue: [[:change :index| (listSelections at: index) or: [change methodClassName = name]]] + ifFalse: [[:change| change methodClassName = name]])]! - name := self currentChange methodClassName. - name ifNil: [ ^self ]. - ^self selectSuchThat: [ :change | - change methodClassName = name ].! Item was changed: ----- Method: ChangeList>>selectSuchThat: (in category 'menu actions') ----- selectSuchThat: aBlock "select all changes for which block returns true" + listSelections := aBlock numArgs = 2 + ifTrue: [changeList withIndexCollect: aBlock] + ifFalse: [changeList collect: aBlock]. - listSelections := changeList collect: aBlock. self changed: #allSelections! Item was added: + ----- Method: ContextVariablesInspector>>defaultIntegerBase (in category 'selecting') ----- + defaultIntegerBase + "Answer the default base in which to print integers. + Defer to the class the code is compiled in." + ^[object method methodClass defaultIntegerBaseInDebugger] + on: MessageNotUnderstood + do: [:ex| 10]! Item was added: + ----- Method: Inspector>>defaultIntegerBase (in category 'selecting') ----- + defaultIntegerBase + "Answer the default base in which to print integers. + Defer to the class of the instance." + ^[object class defaultIntegerBaseInDebugger] + on: MessageNotUnderstood + do: [:ex| 10]! Item was changed: ----- Method: Inspector>>selectionPrintString (in category 'selecting') ----- selectionPrintString | text | + selectionUpdateTime := [text := [self selection isInteger + ifTrue: [self selection storeStringBase: self defaultIntegerBase] + ifFalse: [self selection printStringLimitedTo: 5000]] - selectionUpdateTime := [text := [(self selection printStringLimitedTo: 5000) asText] on: Error do: [text := self printStringErrorText. text addAttribute: TextColor red from: 1 to: text size. text]] timeToRun. ^ text! |
Re: The Trunk: Tools-eem.526.mcz
|
|
Introducing new dependencies on Sensor is bad practice. We should stick to the event mechanism. I'm not sure what you're trying to do, but did you know we already have AlternatePluggableListMorphOfMany which implements extending selection via Shift key..?
On Thu, Jul 31, 2014 at 12:46 AM, <[hidden email]> wrote: Eliot Miranda uploaded a new version of Tools to project The Trunk: |
Re: The Trunk: Tools-eem.526.mcz
|
|
On Thu, Jul 31, 2014 at 5:38 AM, Chris Muller <[hidden email]> wrote:
No shit. But events are not passed throguh to dispatched menu picks AFAICT. If there's a way to get the event that resulted in the menu pick I'm all ears.
The ChangeList doesn't work that way. It has its own internal boolean array of selected elements. In any case this is about computing a set of selections, not toggling a single selection. The point being that computing a set of selections can either select that set, or add that set to the existing set of selections.
best, Eliot
|
Re: The Trunk: Tools-eem.526.mcz
|
|
> On Thu, Jul 31, 2014 at 5:38 AM, Chris Muller <[hidden email]> wrote:
>> >> Introducing new dependencies on Sensor is bad practice. We should stick >> to the event mechanism. > > No shit. Hey man, you toss in a new Sensor shiftPressed you gotta expect a LITTLE flak. ;-) > But events are not passed throguh to dispatched menu picks AFAICT. > If there's a way to get the event that resulted in the menu pick I'm all > ears. MenuItemMorph>>#mouseUp: calls its #invokeWithEvent:, which checks the number of args of the handler method. So, yes! It appears so! Just add the arg..? Oops, but, the problem is in MenuItemMorph>>#mouseDown:. It usurps the Shift key so the user can "edit" the menu choices. Man, oh man, what a useless waste of such a powerful toggle-gesture otherwise available to all menu items! We should talk about reclaiming that..! >> I'm not sure what you're trying to do, but did you know we already have >> AlternatePluggableListMorphOfMany which implements extending selection via >> Shift key..? > > The ChangeList doesn't work that way. It has its own internal boolean array > of selected elements. In any case this is about computing a set of > selections, not toggling a single selection. The point being that computing > a set of selections can either select that set, or add that set to the > existing set of selections. I see and understand what you're doing and why. Another solution could be to make your shifted behavior the default for all the "select" menu options. The menu already provides deselect all so the user could do that and then "build up" their selection along multiple criteria. That way the whole menu's power is built up without having to check for shiftPressed in all those places. Hey, I saw the new Sensor use and so just trying to bounce some ideas around. - Chris |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |