The Trunk: Tools-mt.622.mcz
Locked
 
|
Marcel Taeumel uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-mt.622.mcz ==================== Summary ==================== Name: Tools-mt.622 Author: mt Time: 8 May 2015, 11:01:04.067 am UUID: d6bbe089-6caa-bb48-8823-ac746a9fc3f1 Ancestors: Tools-mt.621 Fixed regression in Message Names tool. Support multi-line search pattern input again. =============== Diff against Tools-mt.621 =============== Item was changed: ----- Method: MessageNames>>buildSearchPaneWith: (in category 'toolbuilder') ----- buildSearchPaneWith: builder | panelSpec textSpec buttonSpec | panelSpec := builder pluggablePanelSpec new layout: #horizontal; children: OrderedCollection new; yourself. + textSpec := builder pluggableTextSpec new. - textSpec := builder pluggableInputFieldSpec new. textSpec model: searchString; help: 'Type here, then hit Search.' translated; getText: #contents; setText: #contents:. panelSpec children add: textSpec. buttonSpec := builder pluggableActionButtonSpec new. buttonSpec model: self; label: 'Search'; action: #doSearch; horizontalResizing: #shrinkWrap. panelSpec children add: buttonSpec. ^ panelSpec! Item was changed: ----- Method: MessageNames>>buildWith: (in category 'toolbuilder') ----- buildWith: builder "ToolBuilder open: MessageNames new" | windowSpec max searchHeight | max := self wantsOptionalButtons ifTrue:[0.42] ifFalse:[0.5]. searchHeight := Preferences standardDefaultTextFont height * 2. windowSpec := self buildWindowWith: builder specs: { + (0@0 corner: 0.5@0.1) -> [self buildSearchPaneWith: builder]. + (0@0.1 corner: 0.5 @ max) -> [self buildSelectorListWith: builder]. - (self topConstantHeightFrame: searchHeight fromLeft: 0 width: 0.5) -> [self buildSearchPaneWith: builder]. - (self frameOffsetFromTop: searchHeight fromLeft: 0 width: 0.5 bottomFraction: max) -> [self buildSelectorListWith: builder]. (0.5@0.0 corner: 1.0@max) -> [self buildMessageListWith: builder]. (0@max corner: 1@1) -> [self buildCodePaneWith: builder]. }. ^ builder build: windowSpec! |
|
|
Can you add the menu also to ease copy pasting with mouse in text field ? Karl On Fri, May 8, 2015 at 11:01 AM, <[hidden email]> wrote: Marcel Taeumel uploaded a new version of Tools to project The Trunk: |
Re: The Trunk: Tools-mt.622.mcz
|
Not easily...
Best, Marcel |
|
|
If the model for the searchString in MessageNames was StringHolder instead of ValueHolder it would be easy to add menus. Is there a specific reason to use ValueHolder as model? Karl On Fri, May 8, 2015 at 1:05 PM, marcel.taeumel <[hidden email]> wrote: Not easily... |
Re: The Trunk: Tools-mt.622.mcz
|
|
Good idea, but if you set #contents: in a StringHolder, it does not tell it's dependents about the changed contents. ;-) Scary. But that's how it is. Not usable as a model except when subclassing and extending it.
Best, Marcel |
|
|
Ok On Fri, May 8, 2015 at 4:41 PM, marcel.taeumel <[hidden email]> wrote: Good idea, but if you set #contents: in a StringHolder, it does not tell it's |
|
|
In reply to this post by marcel.taeumel
On Fri, May 8, 2015 at 7:41 AM, marcel.taeumel <[hidden email]> wrote: Good idea, but if you set #contents: in a StringHolder, it does not tell it's Is this a good thing, or should that change? ;-) Scary. But that's how it is. Not |
Re: The Trunk: Tools-mt.622.mcz
|
|
In reply to this post by commits-2
Whoa, I can no longer simply press Return to search..? How does the
"multi-line search pattern" work? On Fri, May 8, 2015 at 4:01 AM, <[hidden email]> wrote: > Marcel Taeumel uploaded a new version of Tools to project The Trunk: > http://source.squeak.org/trunk/Tools-mt.622.mcz > > ==================== Summary ==================== > > Name: Tools-mt.622 > Author: mt > Time: 8 May 2015, 11:01:04.067 am > UUID: d6bbe089-6caa-bb48-8823-ac746a9fc3f1 > Ancestors: Tools-mt.621 > > Fixed regression in Message Names tool. Support multi-line search pattern input again. > > =============== Diff against Tools-mt.621 =============== > > Item was changed: > ----- Method: MessageNames>>buildSearchPaneWith: (in category 'toolbuilder') ----- > buildSearchPaneWith: builder > > | panelSpec textSpec buttonSpec | > panelSpec := builder pluggablePanelSpec new > layout: #horizontal; > children: OrderedCollection new; > yourself. > > + textSpec := builder pluggableTextSpec new. > - textSpec := builder pluggableInputFieldSpec new. > textSpec > model: searchString; > help: 'Type here, then hit Search.' translated; > getText: #contents; > setText: #contents:. > panelSpec children add: textSpec. > > buttonSpec := builder pluggableActionButtonSpec new. > buttonSpec > model: self; > label: 'Search'; > action: #doSearch; > horizontalResizing: #shrinkWrap. > panelSpec children add: buttonSpec. > > ^ panelSpec! > > Item was changed: > ----- Method: MessageNames>>buildWith: (in category 'toolbuilder') ----- > buildWith: builder > "ToolBuilder open: MessageNames new" > > | windowSpec max searchHeight | > max := self wantsOptionalButtons ifTrue:[0.42] ifFalse:[0.5]. > searchHeight := Preferences standardDefaultTextFont height * 2. > > windowSpec := self buildWindowWith: builder specs: { > + (0@0 corner: 0.5@0.1) -> [self buildSearchPaneWith: builder]. > + (0@0.1 corner: 0.5 @ max) -> [self buildSelectorListWith: builder]. > - (self topConstantHeightFrame: searchHeight fromLeft: 0 width: 0.5) -> [self buildSearchPaneWith: builder]. > - (self frameOffsetFromTop: searchHeight fromLeft: 0 width: 0.5 bottomFraction: max) -> [self buildSelectorListWith: builder]. > (0.5@0.0 corner: 1.0@max) -> [self buildMessageListWith: builder]. > (0@max corner: 1@1) -> [self buildCodePaneWith: builder]. > }. > > ^ builder build: windowSpec! > > |
Re: The Trunk: Tools-mt.622.mcz
|
|
You separate patterns with ";". Multi-line just because it now wraps again.
Could you hit return in the past? I thought that's why the "Search" button was there. Best, Marcel |
Re: The Trunk: Tools-mt.622.mcz
|
|
On Sat, May 9, 2015 at 9:16 AM, marcel.taeumel <[hidden email]> wrote:
> You separate patterns with ";". Multi-line just because it now wraps again. > > Could you hit return in the past? Yes, just as you can on virtually any "Search" field of any system anywhere on the planet, including our own Search field on our Docking Bar. > I thought that's why the "Search" button > was there. Would you please start including gesture counts of various use-cases into your UI changes? For MessageNames the use-case is multiple successive searches, as in, I didn't find the results I'm looking for the first or second time, but now you're forcing the user to move their hands back and forth between the keyboard and mouse just to click that Search button. This is significant degradation in the usability of this window. You said search terms are separated by semicolons so what value do CR's provide by being in the input? |
Re: The Trunk: Tools-mt.622.mcz
|
|
Hey, I do account for all of those. It might only be a slip because the documentation is poor. :P
As for Message Names, it should be built with ToolBuilder to also work in MVC. So that rules out (!) all Morph-specific features. What lies in the Tools package, must not assume Morph API. Yes, there might be a need for MorphicTools as a specialization for tools that want to benefit from Morphic-only features. :P As for now, you can trigger the search with CMD+S. That's only one (half) keystroke more. ;) As for the future, yes, we can just implement a flag in PluggableInputFieldSpec to support multi-line input fields if desired. However, I consider the "eye jump" that occurs with multi-line fields on overflow quite distracting for input fields. :-) --- We have code-freeze. So if I should add that now, make a vote. Best, Marcel |
Re: The Trunk: Tools-mt.622.mcz
|
|
On Tue, May 12, 2015 at 3:22 AM, marcel.taeumel <[hidden email]> wrote:
> Hey, I do account for all of those. It might only be a slip because the > documentation is poor. :P > > As for Message Names, it should be built with ToolBuilder to also work in > MVC. So that rules out (!) all Morph-specific features. What lies in the > Tools package, must not assume Morph API. Well, I really don't understand that logic. There is already very little that can be done in a MVC project today compared to a Morphic project, and I find it hard to believe MVC cannot have a field which does something when Return is pressed anyway. And if its true why not improve MVC than restrict Morphic-based UI's? I also think it is good to really ask what is the benefit of having multiple... errr, "two" UI frameworks which do exactly the same thing? Isn't it their _differences_ which would appeal us to choose one over another? Sometimes I think we get too hung up on the idea of "uniformity" -- not only is it never achieved, I'm begining to feel dubious about it as a goal in the first place. Seriously, I'd be suprised if anyone could articulate a compelling reason in one or two sentences.. > Yes, there might be a need for MorphicTools as a specialization for tools > that want to benefit from Morphic-only features. :P > > As for now, you can trigger the search with CMD+S. That's only one (half) > keystroke more. ;) It's not about the required effort, its about the non-standard behavior for a search field. When you use Google, do you actually click the magnifying glass or press Return? Be honest. What would a new user think if Return didn't work? > As for the future, yes, we can just implement a flag in > PluggableInputFieldSpec to support multi-line input fields if desired. > However, I consider the "eye jump" that occurs with multi-line fields on > overflow quite distracting for input fields. :-) --- We have code-freeze. So > if I should add that now, make a vote. We are in feature freeze, not a code freeze. This seems like a unnecessary usability bug for new users. Say, you never said what function CR's serve in that input field. Do they serve a use-case? |
Re: The Trunk: Tools-mt.622.mcz
|
|
> On Tue, May 12, 2015 at 3:22 AM, marcel.taeumel <[hidden email]>
> wrote: >> Hey, I do account for all of those. It might only be a slip because the >> documentation is poor. :P >> >> As for Message Names, it should be built with ToolBuilder to also work >> in >> MVC. So that rules out (!) all Morph-specific features. What lies in the >> Tools package, must not assume Morph API. > > Well, I really don't understand that logic. There is already very > little that can be done in a MVC project today compared to a Morphic > project, and I find it hard to believe MVC cannot have a field which > does something when Return is pressed anyway. And if its true why not > improve MVC than restrict Morphic-based UI's? If you are only every going to have one flavor of UI framework, then you do not need a ToolBuilder in the first place. If you *do* want to have a ToolBuilder, then you had better make sure that it works at some suitable level of abstraction. In practice this means applying it to more than one flavor of UI. I would like to think that we might have more flavors of UI technology in the future (Juan's Morphic3, touch devices, Pharo developments, maybe others). But for now we only Morphic and MVC to work with. The good news is that Morphic and MVC are sufficiently different that they provide a very good basis for validating the ToolBuilder abstractions. Dave |
Re: The Trunk: Tools-mt.622.mcz
|
|
I also plan to add an abstraction for my Widgets project [1] to support ToolBuilder-based tools. :)
Best, Marcel [1] https://github.com/hpi-swa/widgets |
Re: The Trunk: Tools-mt.622.mcz
|
|
In reply to this post by Chris Muller-3
CRs have no purpose in the message name patterns. Fixed here: http://forum.world.st/The-Trunk-Tools-mt-625-mcz-td4826069.html
I find line-wrapping in input fields awkward because of the "gaze jump" there on overflow. In multi-line fields, however, I do account for that... hmmm... Maybe we could span the input field to take the whole width of message names? Would single-line be enough then? Eliot?^^ (After the release, not now...) Still: The button in Message Names is necessary because MVC's PluggableTextView cannot #acceptOnCR and my time is too limited to add all missing features to MVC land right now. :) But I really would like to do that... *sigh* Best, Marcel |
Re: The Trunk: Tools-mt.622.mcz
|
|
In reply to this post by marcel.taeumel
On Tue, May 12, 2015 at 11:43:04AM -0700, marcel.taeumel wrote:
> I also plan to add an abstraction for my Widgets project [1] to support > ToolBuilder-based tools. :) Excellent :-) Dave > > Best, > Marcel > > [1] https://github.com/hpi-swa/widgets > > > > -- > View this message in context: http://forum.world.st/The-Trunk-Tools-mt-622-mcz-tp4825209p4826067.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |