The Trunk: Tools-mt.622.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

The Trunk: Tools-mt.622.mcz

commits-2
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!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.622.mcz

Karl Ramberg
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:
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!





Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.622.mcz

marcel.taeumel
Not easily...

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.622.mcz

Karl Ramberg
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...

Best,
Marcel



--
View this message in context: http://forum.world.st/The-Trunk-Tools-mt-622-mcz-tp4825209p4825254.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.




Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.622.mcz

marcel.taeumel
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
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.622.mcz

Karl Ramberg
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
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



--
View this message in context: http://forum.world.st/The-Trunk-Tools-mt-622-mcz-tp4825209p4825304.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.




cbc
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.622.mcz

cbc
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
dependents about the changed contents.
Is this a good thing, or should that change?
 
;-) Scary. But that's how it is. Not
usable as a model except when subclassing and extending it.

Best,
Marcel



--
View this message in context: http://forum.world.st/The-Trunk-Tools-mt-622-mcz-tp4825209p4825304.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.




Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.622.mcz

Chris Muller-3
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!
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.622.mcz

marcel.taeumel
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
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.622.mcz

Chris Muller-3
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?

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.622.mcz

marcel.taeumel
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
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.622.mcz

Chris Muller-3
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?

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.622.mcz

David T. Lewis
> 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



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.622.mcz

marcel.taeumel
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
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.622.mcz

marcel.taeumel
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
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.622.mcz

David T. Lewis
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.