copying to treated - was: The Inbox: Morphic-cbr.392.mcz Breaks PopUpMenu

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

copying to treated - was: The Inbox: Morphic-cbr.392.mcz Breaks PopUpMenu

Chris Muller-3
Does moving to treated also place a copy in the trunk project?  I
think we should do that so that the repository contains all of the
proper history of its ancestors so that diffs can be performed.

I was just confronted with a strange debugger when trying to verify
where the missing method went mentioned in this post below..  The
referenced version is in the trunks history, so it really should be
part of the trunk repository.  I manually copied it there sothat MC
could perform the necessary diff..

Thanks,
  Chris

On Sat, Apr 3, 2010 at 2:22 PM, glenpaling <[hidden email]> wrote:

>
> Removal of morphicStartUpWithCaption:icon:at:allowKeyboard: from PopUpMenu
> breaks StandardFileMenu (try:  StandardFileMenu oldFile). Perhaps you
> removed it because it has no senders. That's because the selector is created
> from the concatenation of 'morphic' and
> startUpWithCaption:icon:at:allowKeyboard in Project (see below). It was
> recently added by David T. Lewis to manage Morphic and MVC compatibility.
>
> dispatchTo: requestor addPrefixAndSend: baseSelector withArguments:
> arguments
>        "Sender wants to perform a method with dependencies on the type of project.
>        Dispatch to an appropriate method for the current project.
>
>        This method is a workaround for lack of proper ToolBuilder support in the
> sender,
>        and should be eliminated when possible (dtl Feb 2010)"
>
>        | selector |
>        "Flag target selectors to help identify senders"
>        self flag: #mvcOpenLabel:in: .
>        self flag: #morphicOpenLabel:in: .
>        self flag: #mvcStartUpLeftFlush .
>        self flag: #morphicStartUpLeftFlush .
>        self flag: #mvcStartUpWithCaption:icon:at:allowKeyboard: .
>        self flag: #morphicStartUpWithCaption:icon:at:allowKeyboard: .
>        self flag: #mvcOpen: .
>        self flag: #morphicOpen: .
>        self flag: #mvcOpen .
>        self flag: #morphicOpen .
>
>        selector := (self selectorPrefixForDispatch, baseSelector) asSymbol.
>        ^ requestor perform: selector withArguments: argumentsglenpaling@...
> commits-2 wrote:
>>
>> A new version of Morphic was added to project The Inbox:
>> http://source.squeak.org/inbox/Morphic-cbr.392.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Morphic-cbr.392
>> Author: cbr
>> Time: 26 March 2010, 1:38:37.423 am
>> UUID: d2ec5332-d31e-40e5-a5b4-f896cea50f20
>> Ancestors: Morphic-mha.391
>>
>> I find it irksome that we have two help menus (one in the main docking
>> bar, one in the world menu.) I also find it irksome that there's so much
>> stuff in the help menu that's in the world menu that's not really
>> help-related.
>>
>> I moved the stuff that's actually help (except for "world menu help" which
>> really isn't that helpful) out of the world menu and into the docking bar.
>> I took everything else that wasn't already exposed somewhere and put it in
>> the Extras menu on the docking bar.
>>
>> I moved telemorphic up to the top of the world menu because I don't know
>> what it's for, because it pops a submenu that wants self to be an instance
>> of TheWorldMenu, and because I didn't really care to mess with
>> transplanting it.
>>
>> BIG snip
>>
>> Item was removed:
>> - ----- Method:
>> PopUpMenu>>morphicStartUpWithCaption:icon:at:allowKeyboard: (in category
>> '*Morphic-Menus') -----
>> - morphicStartUpWithCaption: captionOrNil icon: aForm at: location
>> allowKeyboard: aBoolean
>> -     "Display the menu, with caption if supplied. Wait for the mouse button
>> to go down, then track the selection as long as the button is pressed.
>> When the button is released,
>> -     Answer the index of the current selection, or zero if the mouse is not
>> released over  any menu item. Location specifies the desired topLeft of
>> the menu body rectangle. The final argument indicates whether the menu
>> should seize the keyboard focus in order to allow the user to navigate it
>> via the keyboard."
>> -
>> -     selection := Cursor normal
>> -                             showWhile: [| menuMorph |
>> -                                     menuMorph := MVCMenuMorph from: self title: nil.
>> -                                     (captionOrNil notNil
>> -                                                     or: [aForm notNil])
>> -                                             ifTrue: [menuMorph addTitle: captionOrNil icon: aForm].
>> -                                     MenuIcons decorateMenu: menuMorph.
>> -                                     menuMorph
>> -                                             invokeAt: location
>> -                                             in: ActiveWorld
>> -                                             allowKeyboard: aBoolean].
>> -     ^ selection!
>>
>>
>>
>>
> --
> View this message in context: http://n4.nabble.com/The-Inbox-Morphic-cbr-392-mcz-tp1691850p1750456.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: copying to treated - was: The Inbox: Morphic-cbr.392.mcz Breaks PopUpMenu

Levente Uzonyi-2
On Sun, 4 Apr 2010, Chris Muller wrote:

> Does moving to treated also place a copy in the trunk project?  I
> think we should do that so that the repository contains all of the
> proper history of its ancestors so that diffs can be performed.

That wouldn't work. Imagine that we decide to reject a package version for
some reason. You move it to the Treated Inbox and suddenly a copy appears
in the Trunk...

>
> I was just confronted with a strange debugger when trying to verify
> where the missing method went mentioned in this post below..  The
> referenced version is in the trunks history, so it really should be
> part of the trunk repository.  I manually copied it there sothat MC
> could perform the necessary diff..

Dynamic selector creation should be avoided when possible. If it's not,
then the method with no "direct" sender should be marked somehow.


Levente

>
> Thanks,
>  Chris
>
> On Sat, Apr 3, 2010 at 2:22 PM, glenpaling <[hidden email]> wrote:
>>
>> Removal of morphicStartUpWithCaption:icon:at:allowKeyboard: from PopUpMenu
>> breaks StandardFileMenu (try:  StandardFileMenu oldFile). Perhaps you
>> removed it because it has no senders. That's because the selector is created
>> from the concatenation of 'morphic' and
>> startUpWithCaption:icon:at:allowKeyboard in Project (see below). It was
>> recently added by David T. Lewis to manage Morphic and MVC compatibility.
>>
>> dispatchTo: requestor addPrefixAndSend: baseSelector withArguments:
>> arguments
>>        "Sender wants to perform a method with dependencies on the type of project.
>>        Dispatch to an appropriate method for the current project.
>>
>>        This method is a workaround for lack of proper ToolBuilder support in the
>> sender,
>>        and should be eliminated when possible (dtl Feb 2010)"
>>
>>        | selector |
>>        "Flag target selectors to help identify senders"
>>        self flag: #mvcOpenLabel:in: .
>>        self flag: #morphicOpenLabel:in: .
>>        self flag: #mvcStartUpLeftFlush .
>>        self flag: #morphicStartUpLeftFlush .
>>        self flag: #mvcStartUpWithCaption:icon:at:allowKeyboard: .
>>        self flag: #morphicStartUpWithCaption:icon:at:allowKeyboard: .
>>        self flag: #mvcOpen: .
>>        self flag: #morphicOpen: .
>>        self flag: #mvcOpen .
>>        self flag: #morphicOpen .
>>
>>        selector := (self selectorPrefixForDispatch, baseSelector) asSymbol.
>>        ^ requestor perform: selector withArguments: argumentsglenpaling@...
>> commits-2 wrote:
>>>
>>> A new version of Morphic was added to project The Inbox:
>>> http://source.squeak.org/inbox/Morphic-cbr.392.mcz
>>>
>>> ==================== Summary ====================
>>>
>>> Name: Morphic-cbr.392
>>> Author: cbr
>>> Time: 26 March 2010, 1:38:37.423 am
>>> UUID: d2ec5332-d31e-40e5-a5b4-f896cea50f20
>>> Ancestors: Morphic-mha.391
>>>
>>> I find it irksome that we have two help menus (one in the main docking
>>> bar, one in the world menu.) I also find it irksome that there's so much
>>> stuff in the help menu that's in the world menu that's not really
>>> help-related.
>>>
>>> I moved the stuff that's actually help (except for "world menu help" which
>>> really isn't that helpful) out of the world menu and into the docking bar.
>>> I took everything else that wasn't already exposed somewhere and put it in
>>> the Extras menu on the docking bar.
>>>
>>> I moved telemorphic up to the top of the world menu because I don't know
>>> what it's for, because it pops a submenu that wants self to be an instance
>>> of TheWorldMenu, and because I didn't really care to mess with
>>> transplanting it.
>>>
>>> BIG snip
>>>
>>> Item was removed:
>>> - ----- Method:
>>> PopUpMenu>>morphicStartUpWithCaption:icon:at:allowKeyboard: (in category
>>> '*Morphic-Menus') -----
>>> - morphicStartUpWithCaption: captionOrNil icon: aForm at: location
>>> allowKeyboard: aBoolean
>>> -     "Display the menu, with caption if supplied. Wait for the mouse button
>>> to go down, then track the selection as long as the button is pressed.
>>> When the button is released,
>>> -     Answer the index of the current selection, or zero if the mouse is not
>>> released over  any menu item. Location specifies the desired topLeft of
>>> the menu body rectangle. The final argument indicates whether the menu
>>> should seize the keyboard focus in order to allow the user to navigate it
>>> via the keyboard."
>>> -
>>> -     selection := Cursor normal
>>> -                             showWhile: [| menuMorph |
>>> -                                     menuMorph := MVCMenuMorph from: self title: nil.
>>> -                                     (captionOrNil notNil
>>> -                                                     or: [aForm notNil])
>>> -                                             ifTrue: [menuMorph addTitle: captionOrNil icon: aForm].
>>> -                                     MenuIcons decorateMenu: menuMorph.
>>> -                                     menuMorph
>>> -                                             invokeAt: location
>>> -                                             in: ActiveWorld
>>> -                                             allowKeyboard: aBoolean].
>>> -     ^ selection!
>>>
>>>
>>>
>>>
>> --
>> View this message in context: http://n4.nabble.com/The-Inbox-Morphic-cbr-392-mcz-tp1691850p1750456.html
>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: copying to treated - was: The Inbox: Morphic-cbr.392.mcz Breaks PopUpMenu

Chris Muller-3
>> Does moving to treated also place a copy in the trunk project?  I
>> think we should do that so that the repository contains all of the
>> proper history of its ancestors so that diffs can be performed.
>
> That wouldn't work. Imagine that we decide to reject a package version for
> some reason. You move it to the Treated Inbox and suddenly a copy appears in
> the Trunk...

Well, I'm talking about the case where it is accepted, not rejected.
It becomes part of the MC model's ancestry and therefore it needs to
be in the trunk if we want to enable MC's functionality of diffing
between versions; don't we?

>> I was just confronted with a strange debugger when trying to verify
>> where the missing method went mentioned in this post below..  The
>> referenced version is in the trunks history, so it really should be
>> part of the trunk repository.  I manually copied it there sothat MC
>> could perform the necessary diff..
>
> Dynamic selector creation should be avoided when possible.

I totally agree!  More abstractly, don't do anything that so
fundamentally circumvents the IDE..

> If it's not, then
> the method with no "direct" sender should be marked somehow.

it is marked.  But unfortunately things are still broken..   World
Menu | open... | file...

Reply | Threaded
Open this post in threaded view
|

Re: copying to treated - was: The Inbox: Morphic-cbr.392.mcz Breaks PopUpMenu

Levente Uzonyi-2
On Sun, 4 Apr 2010, Chris Muller wrote:

>>> Does moving to treated also place a copy in the trunk project?  I
>>> think we should do that so that the repository contains all of the
>>> proper history of its ancestors so that diffs can be performed.
>>
>> That wouldn't work. Imagine that we decide to reject a package version for
>> some reason. You move it to the Treated Inbox and suddenly a copy appears in
>> the Trunk...
>
> Well, I'm talking about the case where it is accepted, not rejected.
> It becomes part of the MC model's ancestry and therefore it needs to
> be in the trunk if we want to enable MC's functionality of diffing
> between versions; don't we?
I thought you were talking about some sort of automatic copying when the
package is moved to the Treated Inbox.

>
>>> I was just confronted with a strange debugger when trying to verify
>>> where the missing method went mentioned in this post below..  The
>>> referenced version is in the trunks history, so it really should be
>>> part of the trunk repository.  I manually copied it there sothat MC
>>> could perform the necessary diff..
>>
>> Dynamic selector creation should be avoided when possible.
>
> I totally agree!  More abstractly, don't do anything that so
> fundamentally circumvents the IDE..
>
>> If it's not, then
>> the method with no "direct" sender should be marked somehow.
>
> it is marked.  But unfortunately things are still broken..   World
I see.

> Menu | open... | file...

It works for me.


Levente

>
>

Reply | Threaded
Open this post in threaded view
|

Re: copying to treated - was: The Inbox: Morphic-cbr.392.mcz Breaks PopUpMenu

Chris Muller-4
>> Well, I'm talking about the case where it is accepted, not rejected.
>> It becomes part of the MC model's ancestry and therefore it needs to
>> be in the trunk if we want to enable MC's functionality of diffing
>> between versions; don't we?
>
> I thought you were talking about some sort of automatic copying when the
> package is moved to the Treated Inbox.

My main goal is to avoid MC's confusing unhandled error that occurs
when a version that is part of the ancestry is not in the trunk
repository, and I try to diff with that version.

Whether that is an automatic or manual process, we should do it.

Shouldn't packages in the inbox that were merged directly into the
trunk be moved to the trunk rather than the treated project?  That
way, the real Squeak has a full and complete history and accounting,
and allowing MC to work..

Reply | Threaded
Open this post in threaded view
|

Re: copying to treated - was: The Inbox: Morphic-cbr.392.mcz Breaks PopUpMenu

Levente Uzonyi-2
On Mon, 5 Apr 2010, Chris Muller wrote:

>>> Well, I'm talking about the case where it is accepted, not rejected.
>>> It becomes part of the MC model's ancestry and therefore it needs to
>>> be in the trunk if we want to enable MC's functionality of diffing
>>> between versions; don't we?
>>
>> I thought you were talking about some sort of automatic copying when the
>> package is moved to the Treated Inbox.
>
> My main goal is to avoid MC's confusing unhandled error that occurs
> when a version that is part of the ancestry is not in the trunk
> repository, and I try to diff with that version.
>
> Whether that is an automatic or manual process, we should do it.

Okay, I was trying to point out that it wouldn't work automatically. But
we don't need a copy at all, just move the package to the Trunk instead
of the Treated Inbox after the merge.


Levente

>
> Shouldn't packages in the inbox that were merged directly into the
> trunk be moved to the trunk rather than the treated project?  That
> way, the real Squeak has a full and complete history and accounting,
> and allowing MC to work..
>