[squeak-dev] The Trunk: Monticello-fbs.581.mcz

Chris Muller asqueaker at gmail.com
Wed Jan 22 01:29:02 UTC 2014


> How is what you want different than simply selecting the "Changes"
> button on the MC browser?

Answering my own question, "because I might be in the History browser
and that should work."  NP, it should be there..

But this blow up isn't obvious to me and something suggests a timing
issue that might be the sign of a bug exposed, than created.

Putting

      100 milliSeconds asDelay wait.

at the top of MCVersionHistoryBrowser>>#getMenu: avoids blow up.
Something causing the #selectedInfo to not be there immediately -- so
maybe this is related to the pre-selection thingy?  (What is that BTW?
-- I know, something to indicate clicked but before it highlights
while it works on the task -- but I never saw it render unless it's
subtle and I missed it).



and when I try to debug it it works.  looks like it might even be a
timing issue with the selection

>
>
> On Tue, Jan 21, 2014 at 4:52 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
>> It's to fix a serious flaw in the History workflow :) I keep selecting
>> the top item, wanting to know "how does it differ compared to its
>> ancestor" and failing. Selecting the _second_ item does _not_ yield
>> the same information: it yields the _inverse_ change. OK, so I know
>> you said you know that.
>>
>> You say "blow up" - what do you mean? Do you see an error?
>>
>> frank
>>
>> On 21 January 2014 21:36, Chris Muller <asqueaker at gmail.com> wrote:
>>> Ok, I see.  It's so you can select the working copy and still get a
>>> context menu.  But everything on that menu is available from the first
>>> ancestor (2nd item in the list).  I know, doing that presents the
>>> changes from the other viewpoint, but I'd rather not have the blow
>>> up..
>>>
>>> On Tue, Jan 21, 2014 at 3:23 PM, Chris Muller <asqueaker at gmail.com> wrote:
>>>> Could you help me understand what this change is about?  Without
>>>> trying to understand the code, I see no difference in the behavior,
>>>> except that now it blows up when yellow-clicking when nothing is
>>>> selected.
>>>>
>>>> Thanks.
>>>>
>>>> On Sat, Jan 18, 2014 at 10:58 AM,  <commits at source.squeak.org> wrote:
>>>>> Frank Shearar uploaded a new version of Monticello to project The Trunk:
>>>>> http://source.squeak.org/trunk/Monticello-fbs.581.mcz
>>>>>
>>>>> ==================== Summary ====================
>>>>>
>>>>> Name: Monticello-fbs.581
>>>>> Author: fbs
>>>>> Time: 18 January 2014, 4:58:44.499 pm
>>>>> UUID: bd327588-05f4-cf4c-87cd-1f5039cb4b04
>>>>> Ancestors: Monticello-cmm.580
>>>>>
>>>>> When browsing the history of a version, you may now select the current version and find out its changes relative to its ancestor.
>>>>>
>>>>> =============== Diff against Monticello-cmm.580 ===============
>>>>>
>>>>> Item was changed:
>>>>>   ----- Method: MCVersionHistoryBrowser>>getMenu: (in category 'morphic ui') -----
>>>>>   getMenu: aMenu
>>>>> +       | menuSpecs |
>>>>> +       menuSpecs := (self selectedInfo ancestors collect: [:parent |
>>>>> -       self selection < 2 ifTrue: [^ aMenu].
>>>>> -       self fillMenu: aMenu fromSpecs:
>>>>> -               {{'view changes to ', ancestry name . #viewChanges}},
>>>>> -               (self selectedInfo ancestors collect: [:parent |
>>>>>                         {'view changes from ', parent name . #viewChanges: . parent}]),
>>>>>                 #(('spawn history' spawnHistory)
>>>>>                 ('search history' searchHistory)).
>>>>> +       self selection > 1 ifTrue: [
>>>>> +               menuSpecs := {{'view changes to ', ancestry name . #viewChanges}}, menuSpecs].
>>>>> +
>>>>> +       self fillMenu: aMenu fromSpecs: menuSpecs.
>>>>>         ^ aMenu!
>>>>>
>>>>>
>>>
>


More information about the Squeak-dev mailing list