Squeak-dev May 2018

squeak-dev@lists.squeakfoundation.org

44 participants
189 discussions

Cursor woe in 6.0 alpha
by Stéphane Rollandin 11 May '18

11 May '18

Hello, Still in the latest downloadable 6.0 trunk image (17967), when clicking in the welcome window the cursor becomes a blinking text one, but then it keeps this shape even over the menu one gets via a right-click. I also noticed when loading muO into that same image that the cursor does not adapt over morphs embedded in text, which is not a proper behaviour since these morphs can have their own requirement as per the cursor shape. Stef

2 2

The Trunk: Morphic-mt.1428.mcz
by commits＠source.squeak.org 11 May '18

11 May '18

Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1428.mcz ==================== Summary ==================== Name: Morphic-mt.1428 Author: mt Time: 11 May 2018, 10:02:42.214977 am UUID: 843c8d82-5e60-8746-b610-418f2d5619fd Ancestors: Morphic-mt.1427 Reset mouse cursor for pop-up menus. =============== Diff against Morphic-mt.1427 =============== Item was changed: ----- Method: MenuMorph>>popUpAt:forHand:in:allowKeyboard: (in category 'control') ----- popUpAt: aPoint forHand: hand in: aWorld allowKeyboard: aBoolean "Present this menu at the given point under control of the given hand." | evt | aWorld submorphs select: [:each | (each isKindOf: MenuMorph) and: [each stayUp not]] thenCollect: [:menu | menu delete]. self items isEmpty ifTrue: [^ self]. MenuIcons decorateMenu: self. (self submorphs select: [:m | m isKindOf: UpdatingMenuItemMorph]) do: [:m | m updateContents]. "precompute width" self positionAt: aPoint relativeTo: (selectedItem ifNil: [self items first]) inWorld: aWorld. aWorld addMorphFront: self. "Acquire focus for valid pop up behavior" + hand + newMouseFocus: self; + showTemporaryCursor: nil. - hand newMouseFocus: self. aBoolean ifTrue: [ originalFocusHolder := hand keyboardFocus. hand newKeyboardFocus: self. self showKeyboardHelp]. evt := hand lastEvent. (evt isKeyboard or: [evt isMouse and: [evt anyButtonPressed not]]) ifTrue: ["Select first item if button not down" self moveSelectionDown: 1 event: evt "Select first item if button not down"]. self updateColor. self changed!

1 0

The Trunk: EToys-mt.327.mcz
by commits＠source.squeak.org 11 May '18

11 May '18

Marcel Taeumel uploaded a new version of EToys to project The Trunk: http://source.squeak.org/trunk/EToys-mt.327.mcz ==================== Summary ==================== Name: EToys-mt.327 Author: mt Time: 11 May 2018, 9:59:07.436977 am UUID: fd205533-1369-ee42-9cbb-85a0980378ff Ancestors: EToys-mt.326 Consistency. =============== Diff against EToys-mt.326 =============== Item was changed: ----- Method: BroomMorph>>justDroppedInto:event: (in category 'dropping/grabbing') ----- justDroppedInto: aMorph event: anEvent super justDroppedInto: aMorph event: anEvent. aMorph isPlayfieldLike ifFalse: [ ^self delete ]. self centered: anEvent hand lastEvent yellowButtonPressed. self transient ifFalse: [ ^self ]. self reset. self hotspot: (start := anEvent position). + anEvent hand newMouseFocus: self. + anEvent hand newKeyboardFocus: self. - anEvent hand mouseFocus: self. - anEvent hand keyboardFocus: self. "Cursor blank show."! Item was changed: ----- Method: BroomMorph>>mouseDown: (in category 'event handling') ----- mouseDown: evt self reset. self resetFilter. self hotspot: (start := evt position). + evt hand newMouseFocus: self. + evt hand newKeyboardFocus: self. - evt hand mouseFocus: self. - evt hand keyboardFocus: self. "Cursor blank show."!

1 0

Re: [squeak-dev] The Trunk: Morphic-mt.1182.mcz
by H. Hirzel 11 May '18

11 May '18

Hello Marcel, could you please give some more background information about the method #translateTo: which seems to have been introduced with this change? I loaded BabySRE-hjh.44 (http://wiki.squeak.org/squeak/2551) into Squeak6.0alpha #17970 (current trunk) and got the error AConnectorSRE (a morph) does not understand #translateTo: --Hannes ........................................................................................................................... translateTo: messages in current trunk: ............................................................................................................................ UserEvent>>translateTo: point position := point. DropEvent>>translateTo: point position := point. MorphicEvent>>translateTo: point "empty method body" On Mon, 20 Jun 2016 15:14:05.567 0000, commits(a)source.squeak.org <commits(a)source.squeak.org> wrote: > Marcel Taeumel uploaded a new version of Morphic to project The Trunk: > http://source.squeak.org/trunk/Morphic-mt.1182.mcz > > ==================== Summary ==================== > > Name: Morphic-mt.1182 > Author: mt > Time: 20 June 2016, 5:13:55.570796 pm > UUID: 825d8e52-1878-af49-9f7a-437b23e68d8c > Ancestors: Morphic-mt.1181 > > Moves implementation of focus event dispatching from various places into > MorphicEventDispatcher. This will ensure consistency in the future because > MorphicEventDispatcher encode the tree iteration with capturing and > bubbling. Doing a focus event is just a shortcut into the tree. TextMorphs > use that. Pop-up menus use that. Modal dialogs use that. > > Fixes missing coordinate transformations when capturing and bubbling for > focus events. > > Simplify focus-related code in MenuMorph, UserDialogBoxMorph, and > DockingBarMorph. > > At the time of writing, there seems to be no need anymore for Morph >> > #handleFocusEvent:. Still, keep it for compatibility to other projects. > > =============== Diff against Morphic-mt.1181 =============== > > Item was removed: > - ----- Method: DockingBarMorph>>handleFocusEvent: (in category > 'events-processing') ----- > - handleFocusEvent: evt > - "Handle focus events. Valid menu transitions are determined based on the > menu currently holding the focus after the mouse went down on one of its > children." > - > - | result filteredEvent | > - (evt isMouse and:[ evt isMouseUp ]) ifTrue:[^ evt]. > - > - result := self processEvent: evt. > - filteredEvent := result == #rejected ifTrue: [evt] ifFalse: [result]. > - > - "Need to handle keyboard input if we have the focus." > - filteredEvent isKeyboard ifTrue: [^ super handleFocusEvent: > filteredEvent]. > - > - "We need to handle button clicks outside and transitions to local popUps > so throw away everything else" > - (filteredEvent isMouseOver or:[filteredEvent isMouse not]) > ifTrue:[^filteredEvent]. > - "What remains are mouse buttons and moves" > - filteredEvent isMove ifFalse:[^super handleFocusEvent: filteredEvent]. > "handle clicks outside by regular means" > - "Now it's getting tricky. On #mouseMove we might transfer control to > *either* the currently active submenu or the pop up owner, if any. Since the > active sub menu is always displayed upfront check it first." > - selectedItem ifNotNil:[(selectedItem activateSubmenu: filteredEvent) > ifTrue:[^filteredEvent]]. > - ! > > Item was added: > + ----- Method: DockingBarMorph>>mouseMove: (in category > 'events-processing') ----- > + mouseMove: evt > + "We might transfer control to *either* the currently active submenu or > the pop up owner, if any. Since the active sub menu is always displayed > upfront check it first." > + > + selectedItem ifNotNil:[selectedItem activateSubmenu: evt].! > > Item was added: > + ----- Method: DockingBarMorph>>processFocusEvent:using: (in category > 'events-processing') ----- > + processFocusEvent: evt using: dispatcher > + > + ^ dispatcher dispatchFocusEventFully: evt with: self! > > Item was added: > + ----- Method: DockingBarMorph>>wantsEveryMouseMove (in category > 'events-processing') ----- > + wantsEveryMouseMove > + ^ true! > > Item was changed: > ----- Method: HandMorph>>sendFocusEvent:to:clear: (in category 'private > events') ----- > sendFocusEvent: anEvent to: focusHolder clear: aBlock > "Send the event to the morph currently holding the focus" > + > | result w | > w := focusHolder world ifNil:[aBlock value. ^ anEvent]. > w becomeActiveDuring:[ > ActiveHand := self. > ActiveEvent := anEvent. > + result := focusHolder processFocusEvent: anEvent. > - result := focusHolder handleFocusEvent: > - (anEvent transformedBy: (focusHolder transformedFrom: self)). > ]. > + ^ result == #rejected ifTrue: [anEvent] ifFalse: [result "filtered > event"]! > - ^result == #rejected ifTrue: [anEvent] ifFalse: [result "filtered > event"]! > > Item was removed: > - ----- Method: MenuMorph>>handleFocusEvent: (in category 'events') ----- > - handleFocusEvent: evt > - "Handle focus events. Valid menu transitions are determined based on the > menu currently holding the focus after the mouse went down on one of its > children." > - | result filteredEvent | > - result := self processEvent: evt. > - filteredEvent := result == #rejected ifTrue: [evt] ifFalse: [result]. > - > - "Need to handle keyboard input if we have the focus." > - filteredEvent isKeyboard ifTrue: [^ super handleFocusEvent: > filteredEvent]. > - > - "We need to handle button clicks outside and transitions to local popUps > so throw away everything else" > - (filteredEvent isMouseOver or:[filteredEvent isMouse not]) > ifTrue:[^filteredEvent]. > - "What remains are mouse buttons and moves" > - filteredEvent isMove ifFalse:[^super handleFocusEvent: filteredEvent]. > "handle clicks outside by regular means" > - "Now it's getting tricky. On #mouseMove we might transfer control to > *either* the currently active submenu or the pop up owner, if any. Since the > active sub menu is always displayed upfront check it first." > - selectedItem ifNotNil: [ > - (selectedItem activateSubmenu: filteredEvent) > - ifTrue: [ ^filteredEvent ] > - ifFalse: [ > - (self containsPoint: filteredEvent position) ifFalse: [ > - self selectItem: nil event: filteredEvent ] ] ]. > - "Note: The following does not traverse upwards but it's the best I can do > for now" > - popUpOwner ifNotNil:[(popUpOwner activateOwnerMenu: filteredEvent) > ifTrue:[^filteredEvent]]. > - ^ filteredEvent! > > Item was removed: > - ----- Method: MenuMorph>>handleMouseMove: (in category 'events') ----- > - handleMouseMove: evt > - " If the mouse moves over an item not selected, we try to set it as > selected. > - If this happens depends on that the current selected item wants to > release > - its selection. " > - > - self selectedItem ifNil: [ ^super handleMouseMove: evt ]. > - (self selectedItem containsPoint: evt position) ifTrue: [ ^super > handleMouseMove: evt ]. > - self > - selectItem: ( > - self items > - detect: [ :each | each containsPoint: evt position ] > - ifNone: [ nil ]) > - event: evt. > - super handleMouseMove: evt! > > Item was added: > + ----- Method: MenuMorph>>mouseMove: (in category 'events') ----- > + mouseMove: evt > + " If the mouse moves over an item not selected, we try to set it as > selected. > + If this happens depends on that the current selected item wants to > release > + its selection. " > + > + self selectedItem ifNil: [ ^ self ]. > + (self selectedItem containsPoint: evt position) ifTrue: [ ^ self ]. > + self > + selectItem: ( > + self items > + detect: [ :each | each containsPoint: evt position ] > + ifNone: [ nil ]) > + event: evt. > + > + "Transfer control to *either* the currently active submenu or the pop up > owner, if any. Since the active sub menu is always displayed upfront check > it first." > + selectedItem ifNotNil: [ > + (selectedItem activateSubmenu: evt) > + ifTrue: [ ^self ] > + ifFalse: [ > + (self containsPoint: evt position) ifFalse: [ > + self selectItem: nil event: evt ] ] ]. > + > + "Note: The following does not traverse upwards but it's the best I can do > for now" > + popUpOwner ifNotNil:[popUpOwner activateOwnerMenu: evt]! > > Item was added: > + ----- Method: MenuMorph>>processFocusEvent:using: (in category 'events') > ----- > + processFocusEvent: evt using: dispatcher > + > + ^ dispatcher dispatchFocusEventFully: evt with: self! > > Item was added: > + ----- Method: MenuMorph>>wantsEveryMouseMove (in category 'events') ----- > + wantsEveryMouseMove > + ^ true! > > Item was changed: > ----- Method: Morph>>handleFocusEvent: (in category 'events-processing') > ----- > handleFocusEvent: anEvent > + "Handle the given event. This message is sent if the receiver currently > has the focus and is therefore receiving events directly from some hand. > However, it might already have been handled due to overrides in > #processFocusEvent:using:. We might want to get rid of this call-back in the > future..." > - "Handle the given event. This message is sent if the receiver currently > has the focus and is therefore receiving events directly from some hand. > > + ^ anEvent wasHandled > + ifTrue: [anEvent] > + ifFalse: [self handleEvent: anEvent]! > - 1) Event bubbling. Do event bubbling known from MorphicEventDispatcher by > calling #handleEvent: also on all owners. > - 2) Event capture filters. Walk along the owner chain in reverse order and > apply capture filters as known from MorphicEventDispatcher. > - > - If you want to overwrite this in a subclass (for example to implement > modal dialogs) ensure to call super instead if #handleEvent: directly." > - > - | filteredEvent | > - filteredEvent := anEvent. > - > - "TODO: Add a check to ensure that our event dispatcher is actually of > kind MorphicEventDispatcher?!! We do copy its behavior though... like self > defaultEventDispatcher class == MorphicEventDispatcher? Or #isKindOf:? > Anyway, the outermost morph determines the event dispatcher. See HandMorph >>> #sendEvent:focus:clear: and PasteUpMorph >> #processEvent:." > - > - "Event capturing. Filters only because the capturing phase was bypassed > by using the keyboard/mouse focus." > - self withAllOwners reverseDo: [:morph | "reverse order to comply with > default MorphEventDispatcher" > - morph == anEvent hand ifFalse: [ "Fixes drag-and-drop bug." > - filteredEvent := morph sendFilterEventCapture: filteredEvent for: > morph. > - filteredEvent wasIgnored ifTrue: [^ filteredEvent]]]. > - > - "Event bubbling. Filters are processed in #handleEvent:." > - self withAllOwnersDo: [:morph | > - morph == anEvent hand ifFalse: [ "Fixes drag-and-drop bug." > - filteredEvent := morph handleEvent: filteredEvent. > - filteredEvent wasIgnored ifTrue: [^ filteredEvent]]]. > - > - ^ filteredEvent! > > Item was added: > + ----- Method: Morph>>processFocusEvent: (in category 'events-processing') > ----- > + processFocusEvent: anEvent > + > + ^self processFocusEvent: anEvent using: self defaultEventDispatcher! > > Item was added: > + ----- Method: Morph>>processFocusEvent:using: (in category > 'events-processing') ----- > + processFocusEvent: anEvent using: defaultDispatcher > + "Event dispatching shortcut." > + > + ^ defaultDispatcher dispatchFocusEvent: anEvent with: self! > > Item was changed: > + ----- Method: MorphicEventDispatcher>>dispatchEvent:toSubmorphsOf: (in > category 'support') ----- > - ----- Method: MorphicEventDispatcher>>dispatchEvent:toSubmorphsOf: (in > category 'private') ----- > dispatchEvent: anEvent toSubmorphsOf: aMorph > "Dispatch the given event to the submorphs of the given morph. For > coordinate transformations, work only with copies. Either return the given > event or a copy of any filtered event to employ immutability to some extent. > --- PRIVATE!!" > > | localEvent filteredEvent | > aMorph submorphsDo: [:child | > localEvent := anEvent transformedBy: (child transformedFrom: aMorph). > filteredEvent := child > processEvent: localEvent > using: self. "use same dispatcher" > filteredEvent == #rejected ifFalse: [ "some event or #rejected symbol" > self flag: #overlappingChildren. "mt: We cannot give two overlapping > siblings the chance to handle the event!!" > + ^ self nextFromOriginal: anEvent local: localEvent filtered: > filteredEvent]]. > - filteredEvent == localEvent > - ifTrue: [ > - localEvent wasHandled ifTrue: [anEvent copyHandlerState: > localEvent]. > - anEvent wasIgnored: localEvent wasIgnored. > - ^ anEvent] > - ifFalse: [ > - filteredEvent := filteredEvent copy. > - filteredEvent translateTo: anEvent position. "restore to > untransformed coordinates" > - filteredEvent wasHandled ifFalse: [filteredEvent copyHandlerState: > anEvent]. "restore handler if needed" > - ^ filteredEvent]]]. > > ^ #rejected! > > Item was changed: > + ----- Method: MorphicEventDispatcher>>dispatchEvent:withHandler:withMorph: > (in category 'support') ----- > - ----- Method: MorphicEventDispatcher>>dispatchEvent:withHandler:withMorph: > (in category 'private') ----- > dispatchEvent: anEvent withHandler: aHandler withMorph: aMorph > "Perform the actual event dispatch. Use the given object as handler. Ask > submorphs first to handle the event. Then bubble up. Stop if ignored. Note > that event rejection and event filters are two separete concepts. Filters > come from the outside. Rejection is a morph's decision. > > * The top-most chain of visible, unlocked morphs containing the event > position will get a chance to handle the event. > * When travelling up, the prospective handler is always executed. The > handler needs to check if the event was handled before as well as checking > if somebody else's handler has been installed. > * If another handler has been installed but the event was not handled it > means that somebody up in the hierarchy wants to handle the event." > > | result filteredEvent | > > result := self dispatchEvent: anEvent toSubmorphsOf: aMorph. > > result == #rejected "Anybody?" > ifFalse: [filteredEvent := result] > ifTrue: [ > "My submorphs did not want it. Do I want it anyway? It's about locked > children..." > (aMorph containsPoint: anEvent position event: anEvent) > ifFalse: [^ #rejected]. > filteredEvent := anEvent "there was no filtering, only basic > rejects"]. > > "Receiver is in the top-most unlocked, visible chain." > (aHandler notNil and: [filteredEvent wasIgnored not]) > ifTrue: [filteredEvent := aHandler handleEvent: filteredEvent]. > > ^ filteredEvent! > > Item was added: > + ----- Method: MorphicEventDispatcher>>dispatchFocusEvent:with: (in > category 'focus events') ----- > + dispatchFocusEvent: anEventWithGlobalPosition with: focusMorph > + "Dispatch the given event to the given morph. Simulate capturing phase, > handle the event, then do bubbling." > + > + | currentEvent | > + "1) Capturing phase." > + currentEvent := self doCapturingForFocusEvent: anEventWithGlobalPosition > with: focusMorph. > + currentEvent == #rejected ifTrue: [^ #rejected]. > + currentEvent wasIgnored ifTrue: [^ currentEvent]. > + > + "2) No sub-tree processing here. Use #dispatchFocusEventFully:with: if > you want that, too." > + > + "3) Let the focus morph handle the event." > + currentEvent := self doHandlingForFocusEvent: currentEvent with: > focusMorph. > + currentEvent wasIgnored ifTrue: [^ currentEvent]. > + > + "4) Bubbling phase" > + ^ self doBubblingForFocusEvent: currentEvent with: focusMorph! > > Item was added: > + ----- Method: MorphicEventDispatcher>>dispatchFocusEventFully:with: (in > category 'focus events') ----- > + dispatchFocusEventFully: anEventWithGlobalPosition with: focusMorph > + "Dispatch the given event to the given morph. Do capturing, processing in > sub-tree, and bubbling." > + > + | currentEvent | > + "1) Capturing phase." > + currentEvent := self doCapturingForFocusEvent: anEventWithGlobalPosition > with: focusMorph. > + currentEvent == #rejected ifTrue: [^ #rejected]. > + currentEvent wasIgnored ifTrue: [^ currentEvent]. > + > + "2) Sub-tree processing." > + currentEvent := self doProcessingForFocusEvent: currentEvent with: > focusMorph. > + currentEvent wasIgnored ifTrue: [^ currentEvent]. > + > + "3) Let the focus morph handle the event. Usually no effect because > previous sub-tree processing involved the focus morph already -- at least in > the bubbling phase. Skip it?" > + currentEvent := self doHandlingForFocusEvent: currentEvent with: > focusMorph. > + currentEvent wasIgnored ifTrue: [^ currentEvent]. > + > + "4) Bubbling phase." > + ^ self doBubblingForFocusEvent: currentEvent with: focusMorph! > > Item was added: > + ----- Method: MorphicEventDispatcher>>doBubblingForFocusEvent:with: (in > category 'support') ----- > + doBubblingForFocusEvent: anEvent with: focusMorph > + "Simulate real event bubbling up to the focused morph's outermost owner. > Applies event bubble filters via Morph >> #handleEvent:. Watch out for > coordinate transformations and some globals (ActiveWorld, ...)." > + > + | currentEvent filteredEvent localEvent referenceMorph | > + currentEvent := anEvent. > + referenceMorph := anEvent hand. > + > + focusMorph allOwnersDo: [:ownerMorph | > + ownerMorph == anEvent hand ifFalse: [ "Never bubble up to the hand morph > but only up to the world." > + localEvent := currentEvent transformedBy: (ownerMorph transformedFrom: > referenceMorph). > + filteredEvent := ownerMorph handleEvent: localEvent. > + currentEvent := self nextFromOriginal: currentEvent local: localEvent > filtered: filteredEvent. > + currentEvent wasIgnored ifTrue: [^ currentEvent]]]. > + > + ^ currentEvent! > > Item was added: > + ----- Method: MorphicEventDispatcher>>doCapturingForFocusEvent:with: (in > category 'support') ----- > + doCapturingForFocusEvent: anEvent with: focusMorph > + "Simulate real event capturing down to the focused morph. Apply event > capture filters. Watch out for coordinate transformations. Keep the > filter-ignore-reject order like in Morph >> #processEvent:using:." > + > + | currentEvent filteredEvent localEvent referenceMorph | > + currentEvent := anEvent. > + referenceMorph := anEvent hand. > + > + "Event capturing. Filters only because the capturing phase was bypassed > by using the keyboard/mouse focus." > + focusMorph withAllOwners reverseDo: [:ownerMorph | "reverse order to > comply with regular dispatching" > + ownerMorph == anEvent hand ifFalse: [ "Never dispatch the hand morph. It > already did so." > + localEvent := currentEvent transformedBy: (ownerMorph transformedFrom: > referenceMorph). > + > + filteredEvent := ownerMorph sendFilterEventCapture: localEvent for: > ownerMorph. > + > + "Ignoring has higher priority but the reject-check must be with local > event coodinates." > + (filteredEvent wasIgnored not and: [ownerMorph rejectsEvent: > filteredEvent]) > + ifTrue: [^ #rejected]. > + > + currentEvent := self nextFromOriginal: currentEvent local: localEvent > filtered: filteredEvent. > + currentEvent wasIgnored ifTrue: [^ currentEvent]]]. > + > + ^ currentEvent! > > Item was added: > + ----- Method: MorphicEventDispatcher>>doHandlingForFocusEvent:with: (in > category 'support') ----- > + doHandlingForFocusEvent: currentEvent with: focusMorph > + > + | localEvent filteredEvent | > + localEvent := currentEvent transformedBy: (focusMorph transformedFrom: > currentEvent hand). > + filteredEvent := focusMorph handleFocusEvent: localEvent. > + ^ self nextFromOriginal: currentEvent local: localEvent filtered: > filteredEvent.! > > Item was added: > + ----- Method: MorphicEventDispatcher>>doProcessingForFocusEvent:with: (in > category 'support') ----- > + doProcessingForFocusEvent: currentEvent with: focusMorph > + "Sub-tree processing (including capturing from focus morph down to > something and bubbling up back to focus morph). Never reject in the end." > + > + | localEvent filteredEvent | > + localEvent := currentEvent transformedBy: (focusMorph transformedFrom: > currentEvent hand). > + filteredEvent := focusMorph processEvent: localEvent using: self. > + ^ filteredEvent == #rejected > + ifTrue: [currentEvent] "Can happen if you click, e.g., outside the > bounds of the focus morph" > + ifFalse: [self nextFromOriginal: currentEvent local: localEvent > filtered: filteredEvent]! > > Item was added: > + ----- Method: MorphicEventDispatcher>>nextFromOriginal:local:filtered: (in > category 'support') ----- > + nextFromOriginal: originalEvent local: localEvent filtered: filteredEvent > + "Take the filtered event if different but always keep the original > coordinates." > + > + filteredEvent == localEvent > + ifTrue: [ "Use original event but keep track of ignored flag." > + localEvent wasHandled ifTrue: [originalEvent copyHandlerState: > localEvent]. > + originalEvent wasIgnored: localEvent wasIgnored. > + ^ originalEvent] > + ifFalse: [ "There was an event transformation. Copy, revert coordinates, > keep handler state." > + | result | > + result := filteredEvent copy. "Never mutate position without copying. > MouseClickState etc. will break otherwise." > + result translateTo: originalEvent position. "restore to untransformed > coordinates" > + result wasHandled ifFalse: [result copyHandlerState: originalEvent]. > + ^ result]. > + ! > > Item was removed: > - ----- Method: UserDialogBoxMorph>>handleFocusEvent: (in category > 'constructing') ----- > - handleFocusEvent: evt > - "Handle focus events. Valid menu transitions are determined based on the > menu currently holding the focus after the mouse went down on one of its > children. Need to handle keyboard input if we have the focus." > - > - | result filteredEvent | > - result := self processEvent: evt. > - filteredEvent := result == #rejected ifTrue: [evt] ifFalse: [result]. > - > - ^ super handleFocusEvent: filteredEvent! > > Item was added: > + ----- Method: UserDialogBoxMorph>>processFocusEvent:using: (in category > 'events') ----- > + processFocusEvent: evt using: dispatcher > + > + ^ dispatcher dispatchFocusEventFully: evt with: self! > > >

2 1

The Trunk: Tools-tpr.814.mcz
by commits＠source.squeak.org 11 May '18

11 May '18

tim Rowledge uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-tpr.814.mcz ==================== Summary ==================== Name: Tools-tpr.814 Author: tpr Time: 10 May 2018, 3:46:56.604043 pm UUID: 51286010-27d3-4475-88e1-381c5e1c8319 Ancestors: Tools-tpr.813 Remove spurious 'browse class' menu entry and keypress response, replace with correct opening of a full browser based on the selected item in the Inspector. =============== Diff against Tools-tpr.813 =============== Item was added: + ----- Method: Inspector>>browseClass (in category 'menu commands') ----- + browseClass + "Open a full browser on the class of the selected item" + + ToolSet browseClass: self selectedClass! Item was changed: ----- Method: Inspector>>inspectorKey:from: (in category 'menu commands') ----- inspectorKey: aChar from: view "Respond to a Command key issued while the cursor is over my field list" aChar == $i ifTrue: [^ self selection inspect]. aChar == $I ifTrue: [^ self selection explore]. + aChar == $b ifTrue: [^ self browseClass]. - aChar == $b ifTrue: [^ self browseMethodFull]. aChar == $h ifTrue: [^ self classHierarchy]. aChar == $c ifTrue: [^ self copyName]. aChar == $p ifTrue: [^ self browseFullProtocol]. aChar == $N ifTrue: [^ self browseClassRefs]. aChar == $t ifTrue: [^ self tearOffTile]. aChar == $v ifTrue: [^ self viewerForValue]. ^ self arrowKey: aChar from: view! Item was changed: ----- Method: Inspector>>mainFieldListMenu: (in category 'menu commands') ----- mainFieldListMenu: aMenu "Arm the supplied menu with items for the field-list of the receiver" <fieldListMenu> "gets overriden by subclasses, _whithout_ the <fieldListMenu>" aMenu addStayUpItemSpecial. aMenu addList: #( ('inspect (i)' inspectSelection) ('explore (I)' exploreSelection)). self addCollectionItemsTo: aMenu. aMenu addList: #( - ('method refs to this inst var' referencesToSelection) ('methods storing into this inst var' defsOfSelection) ('objects pointing to this value' objectReferencesToSelection) ('chase pointers' chasePointers) ('explore pointers' explorePointers) - + ('browse full (b)' browseClass) + ('browse hierarchy (h)' classHierarchy) - ('browse full (b)' browseMethodFull) - ('browse class' browseClass) - ('browse hierarchy (h)' classHierarchy) ('browse protocol (p)' browseFullProtocol) - ('references... (r)' browseVariableReferences) + ('assignments... (a)' browseVariableAssignments) - ('assignments... (a)' browseVariableAssignments) ('class refs (N)' browseClassRefs) - ('copy name (c)' copyName) ('basic inspect' inspectBasic)). Smalltalk isMorphic ifTrue: [aMenu addList: #( - ('tile for this value (t)' tearOffTile) ('viewer for this value (v)' viewerForValue))]. ^ aMenu " - ('alias for this value' aliasForValue) ('watcher for this slot' watcherForSlot)" !

1 0

Broken menu in explorer
by Stéphane Rollandin 11 May '18

11 May '18

Hello, In the Squeak6.0alpha-17967-32bit image, open an explorer and attempt to use the "browse class" item. You'll get a DNU from PluggableTreeMorph on #browseCass. It works in an inspector, though. Stef

5 11

The Trunk: 60Deprecated-tpr.19.mcz
by commits＠source.squeak.org 10 May '18

10 May '18

tim Rowledge uploaded a new version of 60Deprecated to project The Trunk: http://source.squeak.org/trunk/60Deprecated-tpr.19.mcz ==================== Summary ==================== Name: 60Deprecated-tpr.19 Author: tpr Time: 10 May 2018, 2:52:18.56558 pm UUID: d97f4ebe-21aa-43d6-92f8-8e13d7564217 Ancestors: 60Deprecated-mt.18 deprecate an annoyingly (mis)named method. See also Tools-tpr.813 for the replacement =============== Diff against 60Deprecated-mt.18 =============== Item was added: + ----- Method: ObjectExplorer>>classHierarchy (in category '*60Deprecated-Tools') ----- + classHierarchy + "Create and schedule a class list browser on the receiver's hierarchy." + + self deprecated: 'Use #browseClassHierarchy instead'. + self browseClassHierarchy + !

1 0

The Trunk: Tools-cmm.812.mcz
by commits＠source.squeak.org 10 May '18

10 May '18

Chris Muller uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-cmm.812.mcz ==================== Summary ==================== Name: Tools-cmm.812 Author: cmm Time: 8 May 2018, 10:59:15.586524 pm UUID: d05b5ccd-cc99-4f00-85b1-264218092ef2 Ancestors: Tools-dtl.811 - Integrate newly-defined classes into the hierarchy list of a HierarchyBrowser without muting the other classes. If it's outside the hierarchy, spawn it in a new window. - Bug reports can contain sensitive and/or private information (variable values), so use care when sending them electronically. 'copy bug report to clipboard' replaced 'mail out bug report' on the debugger menu. =============== Diff against Tools-dtl.811 =============== Item was changed: ----- Method: Browser>>defineClass:notifying: (in category 'class functions') ----- defineClass: defString notifying: aController "The receiver's textual content is a request to define a new class. The source code is defString. If any errors occur in compilation, notify aController." | oldClass class newClassName defTokens keywdIx envt | oldClass := self selectedClassOrMetaClass. defTokens := defString findTokens: Character separators. ((defTokens first = 'Trait' and: [defTokens second = 'named:']) or: [defTokens second = 'classTrait']) ifTrue: [^self defineTrait: defString notifying: aController]. keywdIx := defTokens findFirst: [:x | x beginsWith: 'category']. envt := self selectedEnvironment. keywdIx := defTokens findFirst: [:x | '*subclass*' match: x]. newClassName := (defTokens at: keywdIx+1) copyWithoutAll: '#()'. ((oldClass isNil or: [oldClass theNonMetaClass name asString ~= newClassName]) and: [envt includesKey: newClassName asSymbol]) ifTrue: ["Attempting to define new class over existing one when not looking at the original one in this browser..." (self confirm: ((newClassName , ' is an existing class in this system. Redefining it might cause serious problems. Is this really what you want to do?') asText makeBoldFrom: 1 to: newClassName size)) ifFalse: [^ false]]. "ar 8/29/1999: Use oldClass superclass for defining oldClass since oldClass superclass knows the definerClass of oldClass." oldClass ifNotNil:[oldClass := oldClass superclass]. class := envt beCurrentDuring: [oldClass subclassDefinerClass evaluate: defString in: envt notifying: aController logged: false]. (class isKindOf: Behavior) + ifTrue: [self changed: #systemCategoryList; changed: #classList. + self clearUserEditFlag; spawnOrNavigateTo: class. - ifTrue: [self changed: #systemCategoryList. - self changed: #classList. - self clearUserEditFlag. - self setClass: class selector: nil. - "self clearUserEditFlag; editClass." ^ true] ifFalse: [^ false]! Item was added: + ----- Method: Browser>>spawnOrNavigateTo: (in category 'private') ----- + spawnOrNavigateTo: aClass + self setClass: aClass selector: nil! Item was changed: ----- Method: Debugger>>mainContextStackMenu: (in category 'context stack menu') ----- mainContextStackMenu: aMenu "Set up the menu appropriately for the context-stack-list, unshifted" <contextStackMenuShifted: false> ^ aMenu addList: #( ('fullStack (f)' fullStack) ('restart (r)' restart) ('proceed (p)' proceed) ('step (t)' doStep) ('step through (T)' stepIntoBlock) ('send (e)' send) ('where (w)' where) ('peel to first like this' peelToFirst) - ('return entered value' returnValue) - ('toggle break on entry' toggleBreakOnEntry) ('senders of (n)' browseSendersOfMessages) ('implementors of (m)' browseMessages) ('inheritance (i)' methodHierarchy) - ('versions (v)' browseVersions) - ('references (r)' browseVariableReferences) ('assignments (a)' browseVariableAssignments) - ('class refs (N)' browseClassRefs) ('browse full (b)' browseMethodFull) ('file out ' fileOutMessage) - + ('copy bug report to clipboard' copyBugReportToClipboard)); - ('mail out bug report' mailOutBugReport) - ('bug report to clipboard' copyBugReportToClipboard)); yourself ! Item was changed: ----- Method: HierarchyBrowser>>setClass: (in category 'initialization') ----- + setClass: aClass + self initHierarchyForClass: (centralClass ifNil: [ aClass ]). + super setClass: aClass! - setClass: aClass - - self initHierarchyForClass: aClass. - super setClass: aClass.! Item was added: + ----- Method: HierarchyBrowser>>spawnOrNavigateTo: (in category 'private') ----- + spawnOrNavigateTo: aClass + (aClass inheritsFrom: centralClass) + ifTrue: [ super spawnOrNavigateTo: aClass ] + ifFalse: [ self systemNavigation browseHierarchy: aClass ]! Item was changed: ----- Method: HierarchyBrowser>>updateAfterClassChange (in category 'initialization') ----- updateAfterClassChange "It is possible that some the classes comprising the hierarchy have changed, so reinitialize the entire browser." + | priorSelection | + priorSelection := self selectedClassName. + (centralClass notNil and: [centralClass isObsolete not]) + ifTrue: [self initHierarchyForClass: centralClass]. + + (self classListIndexOf: priorSelection) > 0 + ifTrue: [self selectClassNamed: priorSelection].! - ifTrue: [self initHierarchyForClass: centralClass]!

5 7

Re: [squeak-dev] [Pharo-users] Personal Programming onPharo
by H. Hirzel 10 May '18

10 May '18

Hello Trygve I am interested in an updated zip file of http://fulloo.info/Downloads/BabyIDE.zip (Squeak 3.10) Includes Squeak BabyIDE image and Win7-VM. As you write a new Squeak version will come later. --Hannes On 5/10/18, Trygve Reenskaug <trygver(a)ifi.uio.no> wrote: > Hi Hannes, > It's great that you consider spending time on BabyIDE. Porting BabyIDE > to Pharo needs to be done sooner or later, but it may be harder to find > somebody who will actually use the results.(BabyIDE was first released > 10 years ago. AFAIK I am still the only user of the ST version.) > > A plan for creating an alpha version of PP could be > > 1. Establish a project with funding and people (including project > manager and lead programmer). > 2. Use present BabyIDE to create a new and clean Squeak version with > DCI architecture. > 3. Port new BabyIDE to Pharo. > 4. ... > > We will then have a platform that extends Pharo with the new > programming paradigm for programming system behavior (use cases). This > will be a valuable addition to Pharo as a tool for professional > programmers. We will also have a platform for building an alpha version > of PP. > > /But before I do anything else, I have to finish my PP documentation on > my home page > http://folk.uio.no/trygver/ > ./ > > More about DCI at > http://fulloo.info > http://fulloo.info/Examples/SqueakExamples/index.html Includes code > for examples > http://fulloo.info/Downloads/BabyIDE.zip Includes Squeak BabyIDE > image and Win7-VM. > I'll update the ZIP if anybody is interested in > actually running BabyIDE > --Trygve > > > > > On 08.05.2018 20:06, H. Hirzel wrote: >> On 5/6/18, Trygve Reenskaug<trygver(a)ifi.uio.no> wrote: >>> I'm working on a programing paradigm and IDE for the personal programmer >>> who wants to control his or her IoT. The size of the target audience I >>> have in mind is >100 million. I gave up Squeak long ago as a platform >>> because they obsolete my code faster than I can write it. I have now >>> frozen Squeak 3.10.2 and hope its runtime will survive until I find a >>> better foundation. My hope is that Pharo has a stable kernel that I can >>> build on. >> Hello Tryge >> >> Good to see that you reconsider to use Smalltalk in 2018, this time >> Pharo. >> >> Am I assuming correctly that you want to continue to work on your IDE >> which the supports the DCI (Data-Context-Interaction) programming >> style [1]? The IDE was called "BabyIDE" [2]. >> >> In 2015 you wrote to the Squeak mailing list that you are abandoning >> Squeak (Squeak 3.8, 4.5 or 4.6 at that time and Smalltalk as a whole) >> in favour of JavaScript, a mainstream language. That you now at least >> reconsider to use Smalltalk (Pharo) is an interesting result as it >> reinforces the idea that doing things the Smalltalk way is more >> promising than going for JavaScript directly [6]. >> >> As for loading the BabyIDE into Squeak: It is noteworthy that after 10 >> years (done around Squeak version 3.8) of maintaining a fork the >> Squeakland (Etoys) image has been merged back into Squeak 6.0a trunk. >> [5] >> >> I could actually load some of your tools last year into Squeak 6.0a >> with very modest fixes last year. [2]. >> >> It seems that splitting your IDE enhancements into different parts >> which can be treated independently will probably help. >> >> And in addition helpful would be IMHO to write HOW you construct >> these tools and WHY you do it. These will help people to maintain your >> code even if the underlying system changes. >> >> It seems worthwhile to try out how it goes with the most recent Squeak >> version, Squeak 6.0a trunk [8]. >> >> Another option is to wait a few months and look for the bootstrap >> version of Pharo 7. >> All the code is in readable format on github and various types of >> image files may be built build from it [7]. >> >> And the third option is to check out if Cuis (the third Smalltalk >> which runs on the OpenSmalltalk [3] VM) suits your needs. [4] >> >> >> Kind regards >> >> Hannes Hirzel >> >> >> ------------------- >> >> [1] Data-Context-Interactionhttp://wiki.squeak.org/squeak/6048 >> [2] BabySREhttp://wiki.squeak.org/squeak/2550 >> [3]http://www.opensmalltalk.org/ >> [4] Cuis Smalltalk >> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev ; there is a Cuis >> mailing list. >> [5] Etoys in 2017http://wiki.squeak.org/squeak/6531 >> [6] Of course these days JavaScript cannot be avoided. But it is >> preferable to generate it with a Smalltalk tool. >> [7] The file format used in Pharo 7 is called Tonel (no exclamation >> marks!) >> [8] Squeak 6.0a trunk downloadhttp://files.squeak.org/6.0alpha/ >> >> > > -- > > /The essence of object orientation is that objects collaborateto achieve > a goal. / > Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> > Morgedalsvn. 5A http://folk.uio.no/trygver/ > N-0378 Oslo http://fullOO.info > Norway Tel: (+47) 22 49 57 27 > >

1 0

Re: [squeak-dev] [Pharo-users] Personal Programming onPharo
by H. Hirzel 10 May '18

10 May '18

Hello Trygve I think you have written an excellent summary about the challenge presented by object-oriented programming. GOF book on Design Patterns …, it's clear that code won't reveal everything about how a system will work. [ibid.p.23] And the development of Pharo and Squeak the last 10..15 years exemplifies that this is indeed still a challenge though there are some examples and ideas how to cope with it. So is this a case for promoting DCI and related tools (which by itself goes back 10 years)? --Hannes On 5/10/18, Trygve Reenskaug <trygver(a)ifi.uio.no> wrote: > At 87, I'm an old man. I'm told that I don't understand modern software, > which is true. I use some programs daily: WIN7, Pharo, Thunderbird, ... > From time to time, I am told that a new version of the program that > fixes bugs and improves security is available. Press the button to > install it. So I wonder: Is modern software out of control? Does > /anybody /understand it, or is it so complicated that it is beyond human > comprehension? Why didn't they get it right the first time? Most of us > have the GOF book on Design Patterns on our bookshelf. In the > introduction, they write: > > /An object-oriented program's runtime structure often bears little > resemblance to its code structure. The code structure is frozen at > compile-time; it consists of classes in fixed inheritance > relationships. The runtime structure consists of rapidly changing > networks of communicating objects.[GOF-95] p. 22./ > > and > > /…, it's clear that code won't reveal everything about how a system > will work. [ibid.p.23]/ > > Modern programmers are thus reduced to relying on testing the code. In > the words of Edsger Dijstra: > > /"Program testing can be used to show the presence of bugs, but > never to show their absence!"[REF] / > > Modern programmers know all this but accept it as an unavoidable part of > progress. Some may have seen it as a challenge, but they are up against > the enormous inertia of a community who haven't changed their > fundamental model of programming since the advent of the von Neumann > stored program computer in 1948. > > I can't resist another quote; this time from Tony Hoare's TuringAward > lecture: > > /“There are two ways of constructing a software design: One way is > to make it so simple that there are obviously no deficiencies and > the other is to make it so complicated that there are no obvious > deficiencies. The first method is far more difficult. …[Hoare-81]/ > > In the lecture, Hoare was bemoaning his unsuccessful fight for > simplicity. Developers, particularly committees of developers, seem to > love complexity for its own sake. I have never accepted that bugs are an > unavoidable part of software.(See "2. Get it Right the First Time" > in the draft article). Bugs are parts of the facts of life but they are > not an acceptable part of it. Ideally, my software should be /so simple > that there are obviously no deficiencies. /One of my attempts at coming > to grips with the problem is the DCI programming paradigm. Here, /the > runtime structure of rapidly changing networks of communicating objects/ > is specified in explicit code that says (almost) everything about what > happens at runtime. Wouldn't it be wonderful if Pharo were to become > first to overcome the GOF limitation? I challenge you to play with > BabyIDE on Squeak and become convinced that it is a step in the right > direction. > > I won't reread this message before I send it. I suppose it's > controversial and should probably delete some or all of it to avoid > angry answers. Another reason why I probably shouldn't send it is that I > do not have time to engage in a discussion. I /must /give priority to > finishing my article on DCI and PP. (A ~50 page draft is on my home > page; it will be updated from time to time) > > I press the SEND button with a shaking hand > --Trygve > > > > On 09.05.2018 15:53, Richard O'Keefe wrote: >> I have a C++ program written in the late 80s by someone >> else. It used to run fine under cfront 2.0 and early g++. >> Ten years after it was written it was impossible to compile. >> >> *Since* that there have been changes to streams and strings, >> amongst other things. >> >> The 1989 C standard changed the semantics of mixed signed/unsigned >> integer arithmetic. It also inadvertently rendered illegal a >> widely used technique. It is notoriously the case these days >> that compilers taking the C standards literally have "broken" >> quite a lot of code that worked with less ambitious compilers. >> I have been watching this phenomenon with considerable >> nervousness. See for example >> http://www.eng.utah.edu/~cs5785/slides-f10/Dangerous+Optimizations.pdf >> <http://www.eng.utah.edu/%7Ecs5785/slides-f10/Dangerous+Optimizations.pdf> >> >> I have certainly had previously acceptable C89 code be rejected >> by compilers as not being legal C11. It is true that compilers >> tend to have command line/IDE switches to ask that old code be >> compiled under old rules, but you cannot say that *in* the program. >> There is no way to mark the language version, no >> #pragma stdc version iso99 >> >> >> >> As for Java, I could rant about the floods of deprecation warnings >> from old code. I shall content myself with one observation. >> Read http://java-performance.info/changes-to-string-java-1-7-0_06/ >> Before Java 1.7, the substring operation in Java took O(1) time >> and space. From Java 1.7 on, it takes time and space linear in the >> size of the result. The syntax and abstract semantics did not >> change but the pragmatics did. Code that had adequate performance >> could suddenly start crawling. >> >> Oracle do a tolerably thorough job of describing compatibility >> issues between JDK releases. See for example >> http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366… >> where we learned that the 'apt' tool was gone, the JDBC-ODBC bridge >> was gone, 32-bit Solaris support (and yes, I was still using 32-bit >> code in SPARC Solaris and Intel Solaris) was gone, and the type >> inference algorithm had changed in a way that could break things. >> I am still somewhat peeved about some of the rewriting I've had to >> do over the last several releases. >> >> Then there is the simple fact that porting code from one release of >> an OS to another can be a pain. Solaris 10 to OpenSolaris was easy. >> OpenSolaris to Solaris 11 was not as painless. Solaris 11 to >> OpenIndiana was not a happy time for me. OpenBSD changes forced >> rework. I'd finally got my program to port smoothly between Solaris, >> Darwin, and Linux. And then I had trouble porting to the next major >> release of Linux. And with Ubuntu 17, I've got another problem I >> still haven't tracked down. All of this in a C program that gets >> regularly (sp)linted and checked all sorts of ways, written with >> the intention of producing portable code. >> >> EVERYTHING BREAKS. >> >> >> On 7 May 2018 at 22:42, Trygve Reenskaug <trygver(a)ifi.uio.no >> <mailto:trygver@ifi.uio.no>> wrote: >> >> Please tell me when Java, C, C++, etc programs stopped working >> because their runtime systems had changed. >> Please tell me when Java, C, C++, etc compilers stopped compiling >> old code because the languages had changed. >> >> >> On 07.05.2018 11:57, Norbert Hartl wrote: >>> I understand what you are saying but it contains some >>> misconceptions about the modern software world. >>> >>> „The earth is not stopping to turn just because you want to stay >>> on the sunny side“ >>> >>> There is two funny concepts going on in the modern software >>> industry. The one tells you that because you want to do a product >>> everything else around you should come to a full stop so can >>> comfortably build your software not disturbed by other things. >>> The second one tells you that you _have to upgrade_ … there is >>> this magical force preventing you from staying where you are. >>> Both notions are funny alone but they come combined and then they >>> turn out to be a non-sensical monster. >>> >>> Let’s take a different approach. Put in everything you say about >>> software, libraries, etc the word version. So you can build upon >>> Pharo version 3 your own product. You can stay at that version >>> and it won’t change. If the software you sell is not 80% pharo >>> but your own you should not have a problem just to stay on that >>> version because you develop your own stuff. But still the world >>> did not stop turning and there is pharo 4. You decide there are a >>> few nice features but the work to adjust is too big to take the >>> risk. Then there is pharo 5 and you … nahhh not this time….Then >>> there is pharo6 and they not only changed the image but also the >>> way source code is managed. That prevents you further from >>> adjusting. But hey you can still be happy with pharo3 and it does >>> not change. >>> >>> So what is the real problem? Yes, money/time is not enough. I >>> think there are a lot of people risking their health to promote >>> pharo and now we have a consortium that can pay engineers to do >>> work on pharo. So let me tell you a future story: >>> >>> You see what pharo is doing and you think it is good. You can >>> also see that there are too less resources to proceed in the way >>> you need it to go. So you decide to show pharo to the world >>> inspiring people with some kind of a vision. The result is that >>> more people pay into the consortium and we hire more engineers. >>> And then one day the consortium has enough money to pay engineers >>> that can care about a LTS (long term support) version of pharo. >>> So you can stay on pharo version 3 and still get those annoying >>> bugs fixed. And hey this team has also enough time to provide you >>> with tools that make a migration to pharo version 4 more easy and >>> less annoying for you. And then you have your own product based >>> on pharo version 4. And then for version 5, version 6,…. Sounds >>> like a dream…but hey…it is indeed realistic. It just depends on >>> how the people approach it >>> >>> How does this sound? >>> >>> Norbert >>> >>>> Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug >>>> <trygver(a)ifi.uio.no <mailto:trygver@ifi.uio.no>>: >>>> >>>> Thanks for your quick answer. I have only a fleeting knowledge >>>> of Pharo but liked what I saw. The Squeak class library has seen >>>> organic growth since 1978 or earlier. Pharo gave it a thorough >>>> overhaul. At the Pharo kernel was a minimal image with a minimal >>>> class library. The rest of the functionality was partitioned >>>> into packages that could be added to the kernel image as >>>> required. Beautiful. But only my dream? >>>> >>>> /Matthew 7:24-27: And the rain fell, and the floods came, >>>> and the winds blew and beat on that house, but it did not >>>> fall, because it had been founded on the rock. And everyone >>>> who hears these words of mine and does not do them will be >>>> like a foolish man who built his house on the sand."/ >>>> >>>> I am developing an IDE for non-programmers called BabyIDE, a >>>> non-intrusive extension of Squeak. Where the Class Browser in >>>> Squeak is used to work with one class at the time, the BabyIDE >>>> browser is used to work with structures of collaborating >>>> objects, ignoring their classes. I would like to develop a >>>> BabyIDE image that gets broad usage and long life. I'm looking >>>> for a rock to build on and hoped it could be what I thought was >>>> the Pharo kernel+ a few selected packages. In your answer, I >>>> read that if I build BabyIDE on Pharo, I will be building on sand. >>>> >>>> pharo.org <http://pharo.org/>writes: "/Pharo is a pure >>>> object-oriented programming language.../". The only language I >>>> can see is defined by the release image. A Pharo programmer >>>> builds application programs in this language. He or she can add >>>> new classes, change existing ones, subclass them, add or change >>>> methods, change the Smalltalk dictionary, etc. etc. An >>>> extremely flexible and powerful language. >>>> >>>> A tale from the future when Pharo is a mainstream >>>> language:Business customers benefit from end users using >>>> applications that are written by Pharo programmers who built on >>>> the Pharo language and environment that had been developed by >>>> the Pharo community. One day there is a happy announcement: A >>>> new version of Pharo will be launched tomorrow. It is truly cool >>>> and includes any number of improvements, some of them >>>> documented. And, by the way, applications written in the current >>>> Pharo will no longer work. So please inform your customers that >>>> you will not be able to serve them for a while. We are confident >>>> that all your application programmers will be happy to drop >>>> whatever they are doing in order to adapt their applications to >>>> the new Pharo so that you can start serving your customers again. >>>> >>>> Cheers >>>> --Trygve >>>> >>>> >>>> >>>> On 06.05.2018 13:00, Norbert Hartl wrote: >>>>> Can you elaborate on what you consider as a kernel? There are >>>>> always things moving in the pharo world. The last years the >>>>> virtual machine got some iterations and it is still not fully >>>>> stable. For pharo it is hard to have it stable because we feel >>>>> the need that a lot of the existing parts need to be replaced >>>>> to be useful in these times. Furthermore pharo is also >>>>> prototyping platform for programming language features. All of >>>>> these are counter-stability measures. So if you need a stable >>>>> kernel from native ground up to UI pharo won‘t be that thing >>>>> you are looking for the coming years (if at all). You always >>>>> need to adopt to change so you need to define your required >>>>> scope better in order to get an estimate. >>>>> >>>>> Norbert >>>>> >>>>> Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug >>>>> <trygver(a)ifi.uio.no <mailto:trygver@ifi.uio.no>>: >>>>> >>>>>> I'm working on a programing paradigm and IDE for the personal >>>>>> programmer who wants to control his or her IoT. The size of >>>>>> the target audience I have in mind is >100 million. I gave up >>>>>> Squeak long ago as a platform because they obsolete my code >>>>>> faster than I can write it. I have now frozen Squeak 3.10.2 >>>>>> and hope its runtime will survive until I find a better >>>>>> foundation. My hope is that Pharo has a stable kernel that I >>>>>> can build on. According to Stephan, this is not so. Is there >>>>>> any plan for creating a stable Pharo kernel that people can >>>>>> use for building software of lasting value for millions of >>>>>> non-expert users? >>>>>> --Thanks, Trygve >>>>>> >>>>>> On 05.05.2018 13:53, Stephan Eggermont wrote: >>>>>>> I’ve taken a look at what would be needed to >>>>>>> support magma on pharo a few years ago. Chris always told us he >>>>>>> uses it >>>>>>> professionally on squeak and/*has not enough capacity to keep up >>>>>>> with changes in pharo >>>>>>> without having a customer/maintainer for it.*/ Twice a year >>>>>>> or so someone asks about magma on pharo and takes a look. AFAIK >>>>>>> there are >>>>>>> no real obstacles to a port, but magma uses a lot of deep >>>>>>> implementation >>>>>>> specifics that will take an experienced smalltalker to deal with, >>>>>>> and a lot >>>>>>> of mailing list archeology as pharo changed a lot since magma >>>>>>> worked on >>>>>>> pharo last >>>>>>> >>>>>>> Stephan >>>>>> >>>>>> -- >>>>>> /The essence of object orientation is that >>>>>> objectscollaboratetoachieve a goal./ >>>>>> TrygveReenskaug mailto: trygver(a)ifi.uio.no >>>>>> <mailto:%20trygver@ifi.uio.no> >>>>>> Morgedalsvn. 5A http://folk.uio.no/trygver/ >>>>>> <http://folk.uio.no/trygver/> >>>>>> N-0378 Oslo http://fullOO.info <http://fulloo.info/> >>>>>> Norway Tel: (+47) 22 49 57 27 >>>> >>>> -- >>>> /The essence of object orientation is that >>>> objectscollaboratetoachieve a goal./ >>>> TrygveReenskaug mailto: trygver(a)ifi.uio.no >>>> <mailto:%20trygver@ifi.uio.no> >>>> Morgedalsvn. 5A http://folk.uio.no/trygver/ >>>> <http://folk.uio.no/trygver/> >>>> N-0378 Oslo http://fullOO.info <http://fulloo.info/> >>>> Norway Tel: (+47) 22 49 57 27 >>> >> >> -- >> >> /The essence of object orientation is that objects collaborateto >> achieve a goal. / >> Trygve Reenskaug mailto: trygver(a)ifi.uio.no >> <mailto:%20trygver@ifi.uio.no> >> Morgedalsvn. 5A http://folk.uio.no/trygver/ >> <http://folk.uio.no/trygver/> >> N-0378 Oslo http://fullOO.info <http://fullOO.info> >> Norway Tel: (+47) 22 49 57 27 >> >> > > -- > > /The essence of object orientation is that objects collaborateto achieve > a goal. / > Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> > Morgedalsvn. 5A http://folk.uio.no/trygver/ > N-0378 Oslo http://fullOO.info > Norway Tel: (+47) 22 49 57 27 > >

1 0

← Newer
1
...
11
12
13
14
15
16
17
18
19
Older →

Jump to page: