Chris Muller uploaded a new version of ToolBuilder-Morphic to project The Trunk:
http://source.squeak.org/trunk/ToolBuilder-Morphic-cmm.98.mcz ==================== Summary ==================== Name: ToolBuilder-Morphic-cmm.98 Author: cmm Time: 10 March 2015, 5:04:25.508 pm UUID: 88500923-b28a-44b7-929a-9c31485f28ea Ancestors: ToolBuilder-Morphic-mt.97 - Introduce "Filterable Lists by labels only" option for hierarchical list filtering so that collections of objects can easily be "collected". - Default the "Maximum tree search depth" to 1 for performance, safety and so that the default behavior of this feature is as a navigation tool rather than like a search-engine tool. =============== Diff against ToolBuilder-Morphic-mt.97 =============== Item was changed: SimpleHierarchicalListMorph subclass: #PluggableTreeMorph instanceVariableNames: 'rootWrappers selectedWrapper getRootsSelector getChildrenSelector hasChildrenSelector getLabelSelector getIconSelector getSelectedPathSelector setSelectedParentSelector getHelpSelector dropItemSelector wantsDropSelector dragItemSelector nodeClass lastKeystrokeTime lastKeystrokes' + classVariableNames: 'FilterByLabelsOnly MaximumSearchDepth' - classVariableNames: 'MaximumSearchDepth' poolDictionaries: '' category: 'ToolBuilder-Morphic'! !PluggableTreeMorph commentStamp: 'ar 2/12/2005 04:38' prior: 0! A pluggable tree morph.! Item was added: + ----- Method: PluggableTreeMorph class>>filterByLabelsOnly (in category 'preferences') ----- + filterByLabelsOnly + <preference: 'Filterable Lists by labels only' + category: 'scrolling' + description: 'When using the Filterable Lists option, set this to only match the labels, not the contents, of hierarchical lists. Otherwise, search both labels and contents will be matched.' + type: #Boolean> + ^ FilterByLabelsOnly ifNil: [ false ]! Item was added: + ----- Method: PluggableTreeMorph class>>filterByLabelsOnly: (in category 'preferences') ----- + filterByLabelsOnly: aBoolean + FilterByLabelsOnly := aBoolean! Item was changed: ----- Method: PluggableTreeMorph class>>maximumSearchDepth (in category 'preferences') ----- maximumSearchDepth - <preference: 'Maximum tree search depth' category: 'scrolling' + description: 'When using the Filterable Lists option, this specifies the maximum depth that will be searched below the current selection in of the hierarchy.' - description: 'When list filtering is active, this will determine the maximum depth where items should be searched for in a tree.' type: #Number> + ^ MaximumSearchDepth ifNil: [ 1 ]! - ^ MaximumSearchDepth ifNil: [ 3 ]! |
Hi Marcel, is this adding the "Filterable Lists" capability to
SimpleHierarchy's now? Great!! May I collaborate? First, I noticed a giant bug has been introduced. :) It seems all of the command-keys in the object explorer no longer work. For example, I can no longer press Command+h (browse hierarchy) or Command+b (open system browser) or Command+Shift+I (open new explorer on the selected item). These are very important. I hope you don't mind I changed the MaximumSearchDepth default from to 3 to 1. 3 is concerning not only from a performance perspective, but safety too. For example, when I Explore an object from a database, the references directly under the surface are only Proxy's, so accidently pressing a keystroke would invoke DB calls over the network, on every keystroke from the user..! Defaulting the max-depth to 1 mitigates these concerns, while also presenting it as navigation tool (which is what hierarchical list morph is traditionally about). If the user wishes to use it as a "search-engine" type of tool, the depth could be increased. What do you think? Finally, it would be really great if there were some way to invoke the selection in the model based on the first-matching filtered item, like in the normal PluggableListMorphs. I looked at that for about 5 minutes but didn't find a simple and obvious solution, do you think its possible? On Tue, Mar 10, 2015 at 5:07 PM, <[hidden email]> wrote: > Chris Muller uploaded a new version of ToolBuilder-Morphic to project The Trunk: > http://source.squeak.org/trunk/ToolBuilder-Morphic-cmm.98.mcz > > ==================== Summary ==================== > > Name: ToolBuilder-Morphic-cmm.98 > Author: cmm > Time: 10 March 2015, 5:04:25.508 pm > UUID: 88500923-b28a-44b7-929a-9c31485f28ea > Ancestors: ToolBuilder-Morphic-mt.97 > > - Introduce "Filterable Lists by labels only" option for hierarchical list filtering so that collections of objects can easily be "collected". > - Default the "Maximum tree search depth" to 1 for performance, safety and so that the default behavior of this feature is as a navigation tool rather than like a search-engine tool. > > =============== Diff against ToolBuilder-Morphic-mt.97 =============== > > Item was changed: > SimpleHierarchicalListMorph subclass: #PluggableTreeMorph > instanceVariableNames: 'rootWrappers selectedWrapper getRootsSelector getChildrenSelector hasChildrenSelector getLabelSelector getIconSelector getSelectedPathSelector setSelectedParentSelector getHelpSelector dropItemSelector wantsDropSelector dragItemSelector nodeClass lastKeystrokeTime lastKeystrokes' > + classVariableNames: 'FilterByLabelsOnly MaximumSearchDepth' > - classVariableNames: 'MaximumSearchDepth' > poolDictionaries: '' > category: 'ToolBuilder-Morphic'! > > !PluggableTreeMorph commentStamp: 'ar 2/12/2005 04:38' prior: 0! > A pluggable tree morph.! > > Item was added: > + ----- Method: PluggableTreeMorph class>>filterByLabelsOnly (in category 'preferences') ----- > + filterByLabelsOnly > + <preference: 'Filterable Lists by labels only' > + category: 'scrolling' > + description: 'When using the Filterable Lists option, set this to only match the labels, not the contents, of hierarchical lists. Otherwise, search both labels and contents will be matched.' > + type: #Boolean> > + ^ FilterByLabelsOnly ifNil: [ false ]! > > Item was added: > + ----- Method: PluggableTreeMorph class>>filterByLabelsOnly: (in category 'preferences') ----- > + filterByLabelsOnly: aBoolean > + FilterByLabelsOnly := aBoolean! > > Item was changed: > ----- Method: PluggableTreeMorph class>>maximumSearchDepth (in category 'preferences') ----- > maximumSearchDepth > - > <preference: 'Maximum tree search depth' > category: 'scrolling' > + description: 'When using the Filterable Lists option, this specifies the maximum depth that will be searched below the current selection in of the hierarchy.' > - description: 'When list filtering is active, this will determine the maximum depth where items should be searched for in a tree.' > type: #Number> > + ^ MaximumSearchDepth ifNil: [ 1 ]! > - ^ MaximumSearchDepth ifNil: [ 3 ]! > > |
Yes, you may collaborate. :)
I am working on the model-based selection like lists can do. There is a hook for that (#selectMorphByFilter or such). Command keys will be back soon. Actually, it were never command keys but simple key presses such as $i for inspect. I want to change them to CMD+i so that both can work at the same time. For the search, I think about considering the current selection and search that subtree after typing stuff. Backspace could remove only the filter for the selected sub-tree. How does that sound? You could use the feature as a whole tree exploration tool. Depth of 1 is fine for me. I did not collect much experience with this feature yet. Best, Marcel |
> I am working on the model-based selection like lists can do. There is a hook
> for that (#selectMorphByFilter or such). That's great! This would allow the user to "navigate" by their fingers from the home row. > Command keys will be back soon. Actually, it were never command keys but > simple key presses such as $i for inspect. I want to change them to CMD+i so > that both can work at the same time. Ha! All these years I was pressing the Command+key unnecessarily. Good so now I've got the right habits established for this new feature. :) > For the search, I think about considering the current selection and search > that subtree after typing stuff. Backspace could remove only the filter for > the selected sub-tree. How does that sound? You could use the feature as a > whole tree exploration tool. That sounds very powerful, I love it! We are dealing with a hierarchy, so there are a couple of different ways to approach this isn't there? For example, another approach I thought about was, it would only search whatever nodes were actually *visible* (the already-expanded subtrees), regardless of what level they were at. This would eliminate the need for the MaxDepth preference, but the shortcoming is that the user would have to expand a bunch of nodes in advance just to "prepare it" for filtering -- so this works against the navigation use-case. So, I think your idea provides the best of all worlds: navigation, subselection, and filtering. Well done! > Depth of 1 is fine for me. I did not collect much experience with this > feature yet. Me neither and maybe we'll want to bump it to 2 but I thought it would be good to start conservative and see how well it works. You are really rocking, thanks! |
Free forum by Nabble | Edit this page |