Chasing Browsers

>
> The situation:
>  In 1.2.2, I get anOBSendersBrowser.
>
>  However in 1.3 rc, from a method definition in OB:
>    - if I choose "Senders" from the menu I get anOBSendersBrowser
>    - but if I hit Cmd-n, I get a FlatMessageListBrowser.
>
> The call stack:
> - without key mapping:
>
>
>> OBTextMorph>>keyStroke:
>> OBTextMorph(TextMorph)>>handleKeystroke:
>> KeyboardEvent>>sentTo:
>> OBTextMorph(Morph)>>handleEvent:
>> OBTextMorph(Morph)>>handleFocusEvent:
>> [ActiveHand := self.
>>       ActiveEvent := anEvent.
>>       result := focusHolder
>>                               handleFocusEvent: (anEvent
>>                                               transformedBy: (focusHolder transformedFrom: self))] in
>> HandMorph>>sendFocusEvent:to:clear:
>>
>
> - with Keymapping:
>
>
>> SmalltalkEditor>>sendersOfIt
>> SmalltalkEditor>>sendersOfIt:
>> [editor sendersOfIt: event] in [:editor :morph :event | morph
>>               handleKeymappingInteraction: [editor sendersOfIt: event]
>>               fromKeyboardEvent: event] in KMEditorsDefaultSettings
>> class>>buildSmalltalkEditorKeymappingsOn:
>> SmalltalkEditor(TextEditor)>>handleKeystrokeAction:
>> SmalltalkEditor(TextEditor)>>handleEditionAction:fromKeyboardEvent:
>> [self editor handleEditionAction: aBlockInteraction fromKeyboardEvent:
>> anEvent] in
>> OBTextMorph(TextMorph)>>handleKeymappingInteraction:fromKeyboardEvent:
>> OBTextMorph(TextMorph)>>handleInteraction:
>> OBTextMorph(TextMorphForEditView)>>handleInteraction:
>> OBTextMorph(TextMorph)>>handleKeymappingInteraction:fromKeyboardEvent:
>> [:editor :morph :event | morph
>>               handleKeymappingInteraction: [editor sendersOfIt: event]
>>               fromKeyboardEvent: event] in KMEditorsDefaultSettings
>> class>>buildSmalltalkEditorKeymappingsOn:
>>
>
> --
> View this message in context: http://forum.world.st/Chasing-Browsers-tp4102608p4157598.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

>
> Lukas Renggli wrote
>>
>> OB. This means, if you select the method and press Cmd+n it should
>>
>
> Bummer, Cmd-n with a method name selected in OB system browser still brings
> up the non-chasing senders browser.
>
> --
> View this message in context: http://forum.world.st/Chasing-Browsers-tp4102608p4159064.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

> Hmm, I'll have a brief look to avoid keymapping to conflict with OB between today and tuesday.
>
> I don't think it makes sense to spend any time integrating it with OB (yet) since it's removed from Pharo 1.4.
>
> Guille
>
> On Mon, Dec 5, 2011 at 3:32 AM, Lukas Renggli <[hidden email]> wrote:
> Ok, then it must be something else.
>
> I don't know why this Keymapping thing, but it is unlikely to work
> with OB if it was not written for OB. As I said, OB managed its
> keybindings itself.
>
> Lukas
>
> On 5 December 2011 03:51, Sean P. DeNigris <[hidden email]> wrote:
>>
>> Lukas Renggli wrote
>>>
>>> OB. This means, if you select the method and press Cmd+n it should
>>>
>>
>> Bummer, Cmd-n with a method name selected in OB system browser still brings
>> up the non-chasing senders browser.
>>
>> --
>> View this message in context: http://forum.world.st/Chasing-Browsers-tp4102608p4159064.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
>

>>  - then that OB can be loaded on top of Pharo. Remember we are not against OB we just do not have
>>    the knowledge to maintain it. So if lukas gets OB working for 1.4 beta then we will probably include in Pharo.
>>    Now if OB is working for 1.4 only three months after 1.4 is released then we will not include it.
>
> Yes please, do not wait for me.
>
> Just to repeat myself: With Pharo 1.4 having uncountable changes in
> core parts of the system and with the system including more and more
> forked and increasingly incompatible versions of packages (AST, RB,
> FS, Shout, Regex, ...) I am unwilling to go through the same pain as
> with Pharo 1.3 again. In the current state, I don't see any of the
> code I am involved with (including Seaside, Magritte, Pier, OB,
> PetitParser, ...) to move forward. I suspect that moving to another
> development platform soon causes less pain than to move to adopt the
> next Pharo :-(
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>

>>  - then that OB can be loaded on top of Pharo. Remember we are not against OB we just do not have
>>    the knowledge to maintain it. So if lukas gets OB working for 1.4 beta then we will probably include in Pharo.
>>    Now if OB is working for 1.4 only three months after 1.4 is released then we will not include it.
>
> Yes please, do not wait for me.
>
> Just to repeat myself: With Pharo 1.4 having uncountable changes in
> core parts of the system and with the system including more and more
> forked and increasingly incompatible versions of packages (AST, RB,
> FS, Shout, Regex, ...) I am unwilling to go through the same pain as
> with Pharo 1.3 again. In the current state, I don't see any of the
> code I am involved with (including Seaside, Magritte, Pier, OB,
> PetitParser, ...) to move forward. I suspect that moving to another
> development platform soon causes less pain than to move to adopt the
> next Pharo :-(
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>

> Thanks for this really bad and sad message.
> So you are implying that Seaside, Magritte, Pier, OB, PetitParser
> will not be maintained on Pharo 1.4.
>
> This is important for us to know that and this is a really nice stab in our back and this will kill
> a lot of the effort we build over the years.
>
> Thanks again lukas!
> At least this is clear.
>
> Stef
>
> On Dec 11, 2011, at 12:33 PM, Lukas Renggli wrote:
>
>>> - then that OB can be loaded on top of Pharo. Remember we are not against OB we just do not have
>>>   the knowledge to maintain it. So if lukas gets OB working for 1.4 beta then we will probably include in Pharo.
>>>   Now if OB is working for 1.4 only three months after 1.4 is released then we will not include it.
>>
>> Yes please, do not wait for me.
>>
>> Just to repeat myself: With Pharo 1.4 having uncountable changes in
>> core parts of the system and with the system including more and more
>> forked and increasingly incompatible versions of packages (AST, RB,
>> FS, Shout, Regex, ...) I am unwilling to go through the same pain as
>> with Pharo 1.3 again. In the current state, I don't see any of the
>> code I am involved with (including Seaside, Magritte, Pier, OB,
>> PetitParser, ...) to move forward. I suspect that moving to another
>> development platform soon causes less pain than to move to adopt the
>> next Pharo :-(
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>
>

> Thanks for this really bad and sad message.
> So you are implying that Seaside, Magritte, Pier, OB, PetitParser
> will not be maintained on Pharo 1.4.
>
> This is important for us to know that and this is a really nice stab in our back and this will kill
> a lot of the effort we build over the years.
>
> Thanks again lukas!
> At least this is clear.
>
> Stef
>
> On Dec 11, 2011, at 12:33 PM, Lukas Renggli wrote:
>
>>> - then that OB can be loaded on top of Pharo. Remember we are not against OB we just do not have
>>>   the knowledge to maintain it. So if lukas gets OB working for 1.4 beta then we will probably include in Pharo.
>>>   Now if OB is working for 1.4 only three months after 1.4 is released then we will not include it.
>>
>> Yes please, do not wait for me.
>>
>> Just to repeat myself: With Pharo 1.4 having uncountable changes in
>> core parts of the system and with the system including more and more
>> forked and increasingly incompatible versions of packages (AST, RB,
>> FS, Shout, Regex, ...) I am unwilling to go through the same pain as
>> with Pharo 1.3 again. In the current state, I don't see any of the
>> code I am involved with (including Seaside, Magritte, Pier, OB,
>> PetitParser, ...) to move forward. I suspect that moving to another
>> development platform soon causes less pain than to move to adopt the
>> next Pharo :-(
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>
>

> Hi Lukas,
>
> I just loaded Magritte2 into Pharo 1.4 and it loads well with all tests in green.
> Also, Magritte-Morph loads and seems to run well... just a small change:
>
> replace:
>
> PluggableListMorphOfMany
>
> with:
>
> PluggableListMorph ...
> beMultipleSelection

> cheers,
> Esteban
>
> El 11/12/2011, a las 10:58a.m., Stéphane Ducasse escribió:
>
>> Thanks for this really bad and sad message.
>> So you are implying that Seaside, Magritte, Pier, OB, PetitParser
>> will not be maintained on Pharo 1.4.
>>
>> This is important for us to know that and this is a really nice stab in our back and this will kill
>> a lot of the effort we build over the years.
>>
>> Thanks again lukas!
>> At least this is clear.
>>
>> Stef
>>
>> On Dec 11, 2011, at 12:33 PM, Lukas Renggli wrote:
>>
>>>> - then that OB can be loaded on top of Pharo. Remember we are not against OB we just do not have
>>>>  the knowledge to maintain it. So if lukas gets OB working for 1.4 beta then we will probably include in Pharo.
>>>>  Now if OB is working for 1.4 only three months after 1.4 is released then we will not include it.
>>>
>>> Yes please, do not wait for me.
>>>
>>> Just to repeat myself: With Pharo 1.4 having uncountable changes in
>>> core parts of the system and with the system including more and more
>>> forked and increasingly incompatible versions of packages (AST, RB,
>>> FS, Shout, Regex, ...) I am unwilling to go through the same pain as
>>> with Pharo 1.3 again. In the current state, I don't see any of the
>>> code I am involved with (including Seaside, Magritte, Pier, OB,
>>> PetitParser, ...) to move forward. I suspect that moving to another
>>> development platform soon causes less pain than to move to adopt the
>>> next Pharo :-(
>>>
>>> Lukas
>>>
>>> --
>>> Lukas Renggli
>>> www.lukas-renggli.ch
>>>
>>
>>
>
>

>> This is important for us to know that and this is a really nice stab
>> in our back and this will kill a lot of the effort we build over the years.
>
> I don't understand why you think this is a stab into your back? I have
> repeated the same concerns over and over again.
>
>> Now how can we make progress if we do not change Pharo?
>
> Again, we already discussed this many times. I think Pharo is totally
> off the track: Pharo should concentrate on getting a stable core and
> enabling distributions on top, not on integrating as much new things
> as possible.
>
>> May be a dead pharo is better for you.
>
> A dead Pharo is not my goal. I need a minimal Pharo with an absolutely
> trusted and stable core; a system where I can load all my code; a
> system that does not force me to use things I don't want to use.
>
>> @Lukas: please, could you point out what are the expected problems?
>> For example, all PetitParser-Tests are green out of the box in the latest 1.4.
>
> Nice, maybe the others also just work?
>
> OB does not work though because Polymorph changed (and the debugger
> doesn't even open in the UI thread anymore either, so it is not
> possible to figure out the problem); and because it expects a
> different version of RB.
>
>> You were against changing RB, so how can we do remote tooling?
>
> I was against chaining RB, because the proposed changes undermined
> design decisions in RB. In general, it feels extremely strange to me
> if people change code (or even class comments) without understanding
> the code.
>
> Also, for that matter, I don't see how you want to use RB for remote
> tooling? If you remember, I pointed out an interview a while ago with
> John where they discuss why remote tooling wouldn't work without
> rewriting most parts.
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>