Dear Squeakers,
At 30 years of Smalltalk there is also near 30 years of a MVC pattern, which was also invented by Smalltalkers and is currently very popular in JavaScript world by client-side frameworks like Ember.js, Backbone.js, Angular.js etc. At this anniversary it would therefore be nice to remember MVC too, but not only that, In Aida/Web (already the MVC framework) we'd like revive MVC more thoroughly for the modern Smalltalk HTML5 apps. What I's like to ask you is any pointer, article, information, testimony about using MVC pattern in Squeak. I'm aware of MVC GUI as alternative to Morphic, anyone know more about it? Best regards Janko -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si |
On Tue, May 7, 2013 at 7:48 PM, Janko Mivšek <[hidden email]> wrote: Dear Squeakers, |
Great, Yanko for coming up with activities regarding this birthday.
There is quite some material on MVC in the mailing list archive. Somebody from China did a nice, clean MVC version of Squeak. I think it would be worth promoting that. Even better to fix the current 4.5. alpha version which had some improvement recently but still needs more. --Hannes On 5/7/13, karl ramberg <[hidden email]> wrote: > Hi > Here is the implementors webpage: > > http://heim.ifi.uio.no/trygver/www-documents-overview.html > > Karl > > > > On Tue, May 7, 2013 at 7:48 PM, Janko Mivšek > <[hidden email]>wrote: > >> Dear Squeakers, >> >> At 30 years of Smalltalk there is also near 30 years of a MVC pattern, >> which was also invented by Smalltalkers and is currently very popular in >> JavaScript world by client-side frameworks like Ember.js, Backbone.js, >> Angular.js etc. >> >> At this anniversary it would therefore be nice to remember MVC too, but >> not only that, In Aida/Web (already the MVC framework) we'd like revive >> MVC more thoroughly for the modern Smalltalk HTML5 apps. >> >> What I's like to ask you is any pointer, article, information, testimony >> about using MVC pattern in Squeak. I'm aware of MVC GUI as alternative >> to Morphic, anyone know more about it? >> >> Best regards >> Janko >> >> >> -- >> Janko Mivšek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> >> > |
Converting the Monticello browsers to use ToolBuilder would make them
available for use within an MVC UI... Just saying! frank On 8 May 2013 21:59, H. Hirzel <[hidden email]> wrote: > Great, Yanko for coming up with activities regarding this birthday. > There is quite some material on MVC in the mailing list archive. > Somebody from China did a nice, clean MVC version of Squeak. I think > it would be worth promoting that. Even better to fix the current 4.5. > alpha version which had some improvement recently but still needs > more. > > --Hannes > > On 5/7/13, karl ramberg <[hidden email]> wrote: >> Hi >> Here is the implementors webpage: >> >> http://heim.ifi.uio.no/trygver/www-documents-overview.html >> >> Karl >> >> >> >> On Tue, May 7, 2013 at 7:48 PM, Janko Mivšek >> <[hidden email]>wrote: >> >>> Dear Squeakers, >>> >>> At 30 years of Smalltalk there is also near 30 years of a MVC pattern, >>> which was also invented by Smalltalkers and is currently very popular in >>> JavaScript world by client-side frameworks like Ember.js, Backbone.js, >>> Angular.js etc. >>> >>> At this anniversary it would therefore be nice to remember MVC too, but >>> not only that, In Aida/Web (already the MVC framework) we'd like revive >>> MVC more thoroughly for the modern Smalltalk HTML5 apps. >>> >>> What I's like to ask you is any pointer, article, information, testimony >>> about using MVC pattern in Squeak. I'm aware of MVC GUI as alternative >>> to Morphic, anyone know more about it? >>> >>> Best regards >>> Janko >>> >>> >>> -- >>> Janko Mivšek >>> Aida/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si >>> >>> >> > |
On Wed, May 08, 2013 at 10:16:39PM +0100, Frank Shearar wrote:
> Converting the Monticello browsers to use ToolBuilder would make them > available for use within an MVC UI... Just saying! > Yes indeed. And we also need to finish getting the existing tools working with MVCToolBuilder. There is a bit more work to be done here, but it is well worth the effort IMHO. There is also a problem with process scheduling in the debugger on MVC that is probably somehow related to the ToolBuilder implementation, though I have not been able to figure out exactly what is going wrong. It's fun figuring this stuff out, so if anyone is interested in ToolBuilder we could use some help on the MVC side. This is important for ToolBuilder itself (not just MVC per se), because making it work in both Morphic and MVC validates the basic design goal of a tool builder that separates the tools from the specifics of the UI environment. Dave > frank > > On 8 May 2013 21:59, H. Hirzel <[hidden email]> wrote: > > Great, Yanko for coming up with activities regarding this birthday. > > There is quite some material on MVC in the mailing list archive. > > Somebody from China did a nice, clean MVC version of Squeak. I think > > it would be worth promoting that. Even better to fix the current 4.5. > > alpha version which had some improvement recently but still needs > > more. > > > > --Hannes > > > > On 5/7/13, karl ramberg <[hidden email]> wrote: > >> Hi > >> Here is the implementors webpage: > >> > >> http://heim.ifi.uio.no/trygver/www-documents-overview.html > >> > >> Karl > >> > >> > >> > >> On Tue, May 7, 2013 at 7:48 PM, Janko Miv??ek > >> <[hidden email]>wrote: > >> > >>> Dear Squeakers, > >>> > >>> At 30 years of Smalltalk there is also near 30 years of a MVC pattern, > >>> which was also invented by Smalltalkers and is currently very popular in > >>> JavaScript world by client-side frameworks like Ember.js, Backbone.js, > >>> Angular.js etc. > >>> > >>> At this anniversary it would therefore be nice to remember MVC too, but > >>> not only that, In Aida/Web (already the MVC framework) we'd like revive > >>> MVC more thoroughly for the modern Smalltalk HTML5 apps. > >>> > >>> What I's like to ask you is any pointer, article, information, testimony > >>> about using MVC pattern in Squeak. I'm aware of MVC GUI as alternative > >>> to Morphic, anyone know more about it? > >>> > >>> Best regards > >>> Janko > >>> > >>> > >>> -- > >>> Janko Miv??ek > >>> Aida/Web > >>> Smalltalk Web Application Server > >>> http://www.aidaweb.si > >>> > >>> > >> > > |
In reply to this post by Frank Shearar-3
I also have a small MVC image, including an MVC version of the Explorer, which was one of the reasons the ToolBuilder port was stalled, if I recall. |
MVC was first implemented in Smalltalk-76: http://folk.uio.no/trygver/themes/mvc/mvc-index.html The Smalltalk-80 MVC implementation missed the essential element that sets up and coordinates several views I have later called it a 'tool' to avoid confusion. Jim Coplien has later renamed it MVC-U to stress the central importance of the end user in the paradigm. --
Trygve Reenskaug mailto: [hidden email] Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway Tel: (+47) 22 49 57 27 |
In reply to this post by Sam Adams-2
I want to be able to do #browseMethodsWithSourceString: with a case-sensitive
search. For example, I want to easily find all methods with source containing BYTESPERWORD, but not those containing bytesPerWord. In MVC, this works by depressing the shift key while selecting "method source with it" from the menu. In Morphic, there seems to be no way to do this because the shift key has other effects in the menu. This condition has existed for a long time, since at least Squeak 3.6. So how should this work in Morphic? Using the shift key is not very intuitive anyway, since the menu item gives no suggestion that the feature is available. So maybe some other mechanism is better, such as a separate menu entry? Dave |
sounds good
On 5/9/13 8:21 AM, David T. Lewis
wrote:
So maybe some other mechanism is better, such as a separate menu entry? |
On Thu, May 09, 2013 at 08:52:45AM -0400, Bob Arning wrote:
> > On 5/9/13 8:21 AM, David T. Lewis wrote: > >So maybe some other mechanism is better, such as a separate menu entry? > > sounds good > I've looked at this a bit more, and there are several other menu items for which case-sensitive matching is controlled by the shift key. I suspect that the original user interface concept here is that the shift key (which one might think of as the "upper case key") controls whether a menu selection should pay attention to case. For someone familiar with the keyboard shortcuts, this would be very efficient and easy to remember. This mechanism does not work in Morphic because the shift key is used for other purposes. So the original concept of controlling case-sensitive searches based on state of the shift key still exists and it still works in MVC, but it has not been translated into something that works for Morphic. I'm not sure that changing this for "method source with it" is a good idea unless that same approach can be applied consistently for "method strings with it", "class comments with it", etc. So I'm still thinking about it... Dave |
In reply to this post by Trygve
On 5/9/13, Trygve Reenskaug <[hidden email]> wrote:
> I have missed the beginning of this thread and may be repeating > something that is well known. > MVC was first implemented in Smalltalk-76: > http://folk.uio.no/trygver/themes/mvc/mvc-index.html > > The Smalltalk-80 MVC implementation missed the essential element that > sets up and coordinates several views I have later called it a 'tool' to > avoid confusion. And editor? or application model? > Jim Coplien has later renamed it MVC-U to stress the central importance > of the end user in the paradigm. You mean this http://www.artima.com/articles/dci_vision.html <citation> Most programmers think of MVC as a fancy composition of several instances of the Observer pattern. Most programming environments provide MVC base classes that can be extended to synchronize the state of the Model, the View, and the Controller. (Model, View and Controller are actually roles that can be played by the objects that the user provides...) So it's just a housekeeping technique, right? To think of it that way is to take a nerd's perspective. We'll call that perspective "Model-View-Controller." More deeply, the framework exists to separate the representation of information from user interaction. In that capacity we'll call it "Model-View-Controller-User," capturing all four of the important actors at work—MVC-U for short. </citation> Is there a more elaborate description of MVC-U than what I just cited and more terse than http://folk.uio.no/trygver/themes/mvc/mvc-index.html and with references to current JavaScript implementations? It would be good to have an article on the Squeak web site summarizing the history and giving references to the relevant work. --Hannes > > Trygve Reenskaug mailto: [hidden email] > Morgedalsvn. 5A http://folk.uio.no/trygver/ > N-0378 Oslo http://fullOO.info > Norway Tel: (+47) 22 49 57 27 > |
In reply to this post by David T. Lewis
It would be nice if the shift key worked as it
once did and I don't know what the "new" shift-key-in-menu
paradigm is or whether it could be plausibly reverted. However, it
does seem useful if the menu could give some indication of when
there were two possibilities for one menu item and which is going
to happen if you click now. Not everyone has that memorized.
Cheers, Bob On 5/9/13 9:35 PM, David T. Lewis
wrote:
On Thu, May 09, 2013 at 08:52:45AM -0400, Bob Arning wrote:On 5/9/13 8:21 AM, David T. Lewis wrote:So maybe some other mechanism is better, such as a separate menu entry?sounds goodI've looked at this a bit more, and there are several other menu items for which case-sensitive matching is controlled by the shift key. I suspect that the original user interface concept here is that the shift key (which one might think of as the "upper case key") controls whether a menu selection should pay attention to case. For someone familiar with the keyboard shortcuts, this would be very efficient and easy to remember. This mechanism does not work in Morphic because the shift key is used for other purposes. So the original concept of controlling case-sensitive searches based on state of the shift key still exists and it still works in MVC, but it has not been translated into something that works for Morphic. I'm not sure that changing this for "method source with it" is a good idea unless that same approach can be applied consistently for "method strings with it", "class comments with it", etc. So I'm still thinking about it... Dave |
Morphic has shift+left-click drag selection of morphs. Karl On Fri, May 10, 2013 at 1:00 PM, Bob Arning <[hidden email]> wrote:
|
Maybe, but what's happening here is in
MenuItemMorph:
mouseDown: evt "Handle a mouse down event. Menu items get activated when the mouse is over them." evt shiftPressed ifTrue: [ ^super mouseDown: evt ]. "enable label editing" evt hand newMouseFocus: owner. "Redirect to menu for valid transitions" owner selectItem: self event: evt I see this code as far back as squeak 3.2 with a 10/10/2000 date and Andreas's initials. If you comment out the first line, you get the behavior David was looking for. It would be interesting to know who might be using this feature. Cheers, Bob On 5/10/13 7:23 AM, karl ramberg wrote:
|
On Fri, May 10, 2013 at 09:38:28AM -0400, Bob Arning wrote:
> Maybe, but what's happening here is in MenuItemMorph: > > mouseDown: evt > "Handle a mouse down event. Menu items get activated when the mouse > is over them." > > evt shiftPressed ifTrue: [ ^super mouseDown: evt ]. "enable label > editing" > evt hand newMouseFocus: owner. "Redirect to menu for valid transitions" > owner selectItem: self event: evt > > I see this code as far back as squeak 3.2 with a 10/10/2000 date and > Andreas's initials. If you comment out the first line, you get the > behavior David was looking for. It would be interesting to know who > might be using this feature. > > Cheers, > Bob Aha! I suspect that no one is using that feature at all. But just commenting it out is not sufficient, because in Morphic the shift state should come from the input event, not from a direct reference to Sensor, which is what ends up getting done in #browseMethodsWithSourceString: later on. I also tried changing the menu selections to have separate selectors for case-sensitive and non-case-sensitive versions of the search, and this works fine. However, I'm not happy with that approach because it will lead to a cluttered menu if we apply the approach consistently to the various searches for "source with it", "comments with it", etc. There is a conflict between the Morphic use of the shift key for selection of morphs, versus the earlier convention (maybe just in MVC) of having the shift state control case sensitive search for a variety of menu selections. I am inclined to think that the earlier convention is more important in this case, and that is reasonable for Morphic menu items to pass shift state to the menu selections rather than use it directly to support editing menu options. Having said that, I do not think it would be good to make the change to MenuItemMorph>>mouseDown: until the direct reference to Sensor in #browseMethodsWithSourceString: can also be eliminated, so I will not change anything in trunk right now. Dave > > On 5/10/13 7:23 AM, karl ramberg wrote: > >Morphic has shift+left-click drag selection of morphs. > > > >Karl > > > > > >On Fri, May 10, 2013 at 1:00 PM, Bob Arning <[hidden email] > ><mailto:[hidden email]>> wrote: > > > > It would be nice if the shift key worked as it once did and I > > don't know what the "new" shift-key-in-menu paradigm is or whether > > it could be plausibly reverted. However, it does seem useful if > > the menu could give some indication of when there were two > > possibilities for one menu item and which is going to happen if > > you click now. Not everyone has that memorized. > > > > Cheers, > > Bob > > > > On 5/9/13 9:35 PM, David T. Lewis wrote: > >> On Thu, May 09, 2013 at 08:52:45AM -0400, Bob Arning wrote: > >>> On 5/9/13 8:21 AM, David T. Lewis wrote: > >>>> So maybe some other mechanism is better, such as a separate menu > >>>> entry? > >>> sounds good > >>> > >> I've looked at this a bit more, and there are several other menu > >> items for > >> which case-sensitive matching is controlled by the shift key. I > >> suspect that > >> the original user interface concept here is that the shift key (which > >> one > >> might think of as the "upper case key") controls whether a menu > >> selection > >> should pay attention to case. For someone familiar with the keyboard > >> shortcuts, > >> this would be very efficient and easy to remember. > >> > >> This mechanism does not work in Morphic because the shift key is used > >> for > >> other purposes. So the original concept of controlling case-sensitive > >> searches > >> based on state of the shift key still exists and it still works in > >> MVC, but > >> it has not been translated into something that works for Morphic. > >> > >> I'm not sure that changing this for "method source with it" is a good > >> idea > >> unless that same approach can be applied consistently for "method > >> strings > >> with it", "class comments with it", etc. So I'm still thinking about > >> it... > >> > >> Dave > >> > >> > >> > > > > > > > > > > > > > > > > |
On 12-05-2013, at 5:48 PM, "David T. Lewis" <[hidden email]> wrote: > > > I also tried changing the menu selections to have separate selectors for > case-sensitive and non-case-sensitive versions of the search, and this > works fine. However, I'm not happy with that approach because it will > lead to a cluttered menu if we apply the approach consistently to the > various searches for "source with it", "comments with it", etc. Any reason not to go with doFooblyCaseSensitive: evt shitPressed ? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Don't sweat petty things....or pet sweaty things. |
On Sun, May 12, 2013 at 05:52:32PM -0700, tim Rowledge wrote:
> > On 12-05-2013, at 5:48 PM, "David T. Lewis" <[hidden email]> wrote: > > > > > > I also tried changing the menu selections to have separate selectors for > > case-sensitive and non-case-sensitive versions of the search, and this > > works fine. However, I'm not happy with that approach because it will > > lead to a cluttered menu if we apply the approach consistently to the > > various searches for "source with it", "comments with it", etc. > > > Any reason not to go with > doFooblyCaseSensitive: evt shitPressed ? > Yes, I think that is the right thing to do. So for example instead of having "browseMethodsWithSourceString: aString" that checks Sensor shiftPressed, we would have "browseMethodsWithSourceString: aString caseSensitive: caseSensitive". That's what I did to try out the idea of separate menu selections for case-sensitive and non-case-sensitive search, and it works fine. It would be good to allow the shift state in the event to control the option. Maybe that is easy to do, I just haven't actually tried it yet. Dave |
An alternative to adding arguments to methods
would be an exception:
------------------------------------- "some event handling method" [ "send message(s) to handle the event" ] on: WhatEventTriggeredMe do: [ :ex | ex resume: event ]. ------------------------------------- "and where the real work gets done" event _ WhatEventTriggeredMe signal. (event notNil and: [event shiftPressed]) ifTrue: [ 'behave differently" ]. ------------------------------------- Cheers, Bob On 5/12/13 9:30 PM, David T. Lewis
wrote:
On Sun, May 12, 2013 at 05:52:32PM -0700, tim Rowledge wrote:On 12-05-2013, at 5:48 PM, "David T. Lewis" [hidden email] wrote:I also tried changing the menu selections to have separate selectors for case-sensitive and non-case-sensitive versions of the search, and this works fine. However, I'm not happy with that approach because it will lead to a cluttered menu if we apply the approach consistently to the various searches for "source with it", "comments with it", etc.Any reason not to go with doFooblyCaseSensitive: evt shitPressed ?Yes, I think that is the right thing to do. So for example instead of having "browseMethodsWithSourceString: aString" that checks Sensor shiftPressed, we would have "browseMethodsWithSourceString: aString caseSensitive: caseSensitive". That's what I did to try out the idea of separate menu selections for case-sensitive and non-case-sensitive search, and it works fine. It would be good to allow the shift state in the event to control the option. Maybe that is easy to do, I just haven't actually tried it yet. Dave |
In reply to this post by David T. Lewis
> I am inclined to think that the earlier convention is more
> important in this case, and that is reasonable for Morphic menu items to > pass shift state to the menu selections rather than use it directly to > support editing menu options +1 Stef |
In reply to this post by David T. Lewis
On 2013-05-13, at 02:48, David T. Lewis <[hidden email]> wrote: > On Fri, May 10, 2013 at 09:38:28AM -0400, Bob Arning wrote: >> Maybe, but what's happening here is in MenuItemMorph: >> >> mouseDown: evt >> "Handle a mouse down event. Menu items get activated when the mouse >> is over them." >> >> evt shiftPressed ifTrue: [ ^super mouseDown: evt ]. "enable label >> editing" >> evt hand newMouseFocus: owner. "Redirect to menu for valid transitions" >> owner selectItem: self event: evt >> >> I see this code as far back as squeak 3.2 with a 10/10/2000 date and >> Andreas's initials. If you comment out the first line, you get the >> behavior David was looking for. It would be interesting to know who >> might be using this feature. >> >> Cheers, >> Bob > > Aha! I suspect that no one is using that feature at all. I use it: shift-click followed by CMD-E is the quickest way to look at the implementation behind a menu item. OTOH, a morphic halo menu entry might be more appropriate for that function. - Bert - |
Free forum by Nabble | Edit this page |