Hi all
I would really to know how to proceed with the ToolBuilder framework. In particular, I would like to know where I can find information about what are the UI policy not to break the work done and how to reinforce it.
For example, should we track all the PopUpMenu that are not issued by the UIManager and replace them by adequate message. Does it make sense? Is is what the toolPlus tools are already proposing?
Should we make a simple analyze to show the difference between a standard tools and its Plus one and migrate the changes to the Plus so that we can get rid of the standard one?
I took for example ObjectExplorer and ObjectExplorerPlus and the difference in the interface is quite large and I do not understand why? I wanted to start to check the changes between ObjectExplorer and its Plus...
ObjectExplorer selectors difference: ObjectExplorerPlus selectors
a Set(#stopMonitoring #explorerFor:withLabel: #openExplorerFor:withLabel: #trash #label #genericMenu: #doItContext #openExplorerFor: #selector #step #initialExtent #shouldGetStepsFrom: #parentObject #monitor: #explorerFor: #doesNotUnderstand: #defsOfSelection #trash: #chasePointers #codePaneMenu:shifted: #monitorList #object #release #objectReferencesToSelection #referencesToSelection #openBrowser: #world #getList #selectedClass #explorerKey:from: #contentsSelection)
So a lot between the version taken to introduce toolbuilder and now. The explorer got a lot more features, step....active monitor list.... Now I would like to know whether the ToolsPlus should be as UI framework specific as possible?
Now the other question: how can we continue to push this effort since I'm afraid that we will start to lose it if we do not do something.
Stef
On 12/20/05, stéphane ducasse ducasse@iam.unibe.ch wrote:
For example, should we track all the PopUpMenu that are not issued by the UIManager and replace them by adequate message. Does it make sense? Is is what the toolPlus tools are already proposing?
A lot of instances in the image have already been replaced. I think that we should try to find the remaining instances and replace them. Then, at the very least, let PopUpMenu (and associates) write messages to the Transcript so others are warned that they are using obsolete code. Maybe do it with a 'self uiObsoleteCode'.
Then in a later version, we find all senders of #uiObsoleteCode and move it to a "Obsolete UI" package, which is put on SqueakMap and removed from the core distribution.
(because it is really about time that we start showing some cruft the door, folk ;-)).
Now I would like to know whether the ToolsPlus should be as UI framework specific as possible?
Er... no, as UI agnostic as possible. But ToolsPlus should of course offer everything that the current tools use (case in point: the ToolsPlus Morphic workspace is based on StringHolder, which means it loses the local vars functionality that is in Workspace--the latter class wasn't used because that is a known UI specific class, which is fine but then we need to transplant code from Workspace to WorkspacePlus).
Now the other question: how can we continue to push this effort since I'm afraid that we will start to lose it if we do not do something.
Probably by taking small steps at the time - starting with tracking down obsolete code, making Mantis entries for every one of the tools with a message that someone needs to go over it and "merge" functionality, etceterea.
Concretely, I could look at all the references to PopUpMenu and replaces them (when not in the standard tools) with UIManager....
Is it what should be done?
For the explorer I was willing to spend some time to move behavior around but does it make sense to have morphic specific code in the explorerPlus?
I'm not about the vision so this is why I ask.
Stef
On 20 déc. 05, at 12:48, Cees De Groot wrote:
On 12/20/05, stéphane ducasse ducasse@iam.unibe.ch wrote:
For example, should we track all the PopUpMenu that are not issued by the UIManager and replace them by adequate message. Does it make sense? Is is what the toolPlus tools are already proposing?
A lot of instances in the image have already been replaced. I think that we should try to find the remaining instances and replace them. Then, at the very least, let PopUpMenu (and associates) write messages to the Transcript so others are warned that they are using obsolete code. Maybe do it with a 'self uiObsoleteCode'.
Then in a later version, we find all senders of #uiObsoleteCode and move it to a "Obsolete UI" package, which is put on SqueakMap and removed from the core distribution.
(because it is really about time that we start showing some cruft the door, folk ;-)).
Now I would like to know whether the ToolsPlus should be as UI framework specific as possible?
Er... no, as UI agnostic as possible. But ToolsPlus should of course offer everything that the current tools use (case in point: the ToolsPlus Morphic workspace is based on StringHolder, which means it loses the local vars functionality that is in Workspace--the latter class wasn't used because that is a known UI specific class, which is fine but then we need to transplant code from Workspace to WorkspacePlus).
Now the other question: how can we continue to push this effort since I'm afraid that we will start to lose it if we do not do something.
Probably by taking small steps at the time - starting with tracking down obsolete code, making Mantis entries for every one of the tools with a message that someone needs to go over it and "merge" functionality, etceterea.
On 12/20/05, stéphane ducasse ducasse@iam.unibe.ch wrote:
For the explorer I was willing to spend some time to move behavior around but does it make sense to have morphic specific code in the explorerPlus?
No - the PlusTools should be completely UI agnostic. No UI-specific code is allowed in there. So if Morphic-specific code is transported from current tools to PlusTools, it should be split up in code driving ToolBuilder and maybe ToolBuilder enhancements.
Note that ToolBuilder is a maintained package http://kilana.unibe.ch:8888/ToolBuilder/ so patches should go through the upstream.
I'm not sure about PlusTools' status - Andreas, is it an idea to maintain it in the same repository as ToolBuilder?
On 20 déc. 05, at 14:40, Cees De Groot wrote:
On 12/20/05, stéphane ducasse ducasse@iam.unibe.ch wrote:
For the explorer I was willing to spend some time to move behavior around but does it make sense to have morphic specific code in the explorerPlus?
No - the PlusTools should be completely UI agnostic.
Ok this was what I was looking for. For example in the explorer you have morphic specific features.
No UI-specific code is allowed in there. So if Morphic-specific code is transported from current tools to PlusTools, it should be split up in code driving ToolBuilder and maybe ToolBuilder enhancements.
Note that ToolBuilder is a maintained package http://kilana.unibe.ch:8888/ToolBuilder/ so patches should go through the upstream.
Ok my goal is not to change or touch ToolBuilder but to see how we can move the Plus Tool adoption since keeping two separate set of tools is dangerous in the long term.
I'm not sure about PlusTools' status - Andreas, is it an idea to maintain it in the same repository as ToolBuilder?
squeak-dev@lists.squeakfoundation.org
-
Cees De Groot -
stéphane ducasse