Smalltalk › Squeak › Squeak - Dev

MessageNames: clicking on class names

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

22 messages Options

Frank Shearar

MessageNames: clicking on class names

Hi,

I'm not entirely sure how to contribute to the inbox. Well, I know
enough to commit a change to the inbox :) I mean the social process
aspect of things. So anyway, feel free to correct me on etiquette and
protocol.

I noticed that the new search morph in the docking bar will bring up
class names as well as selector names. For instance, searching for "obj"
will show things like "AbstractObjectsAsMethod".

If you hit the browse button on these entries, though, nothing happens.

Tools-fbs.221.mcz allows you to browse the class.

(221 fixes a bug in 220, which otherwise holds the feature. I hadn't
realised that if your search returns NO hits that MessageNames'
selectorListIndex instvar would be nil.)

frank

Ken Causey-3

Re: MessageNames: clicking on class names

On Wed, 2010-03-31 at 22:52 +0200, Frank Shearar wrote:
> Hi,
>
> I'm not entirely sure how to contribute to the inbox. Well, I know
> enough to commit a change to the inbox :) I mean the social process
> aspect of things. So anyway, feel free to correct me on etiquette and
> protocol.

I have nothing to correct really, but I thought I would comment on the
etiquette since you brought it up. I may be overlooking something but
the only things I would suggest for inbox committers is:

1. Update completely to current trunk before submitting to the inbox.
This ensure that your submission's ancestor will be the most recent
version in the trunk and is about the best you can do to make it easier
on core developers to merge your changes.

2. Write a good comment. Try to keep it terse but touch on the main
points and if there is a Mantis issue, note the relevant issue
number(s).

3. Another I've thought of which is purely optional but I think we
should consider strongly suggesting is that you create an account at
source.squeak.org and login before committing. Certainly the repository
is world-writable but submitting it with your account helps to ensure
proper attribution and also gives us a point to ensure that submitters
have agreed to the MIT licensing.

Truthfully I would advocate requiring signing in, but this would require
changes to SqueakSource to enforce I believe and may be considered an
unnecessary hurdle.

That's all I can think of at the moment anyway,

Ken

signature.asc (197 bytes) Download Attachment

Bert Freudenberg

Re: MessageNames: clicking on class names

On 31.03.2010, at 23:45, Ken Causey wrote:

>
> On Wed, 2010-03-31 at 22:52 +0200, Frank Shearar wrote:
>> Hi,
>>
>> I'm not entirely sure how to contribute to the inbox. Well, I know
>> enough to commit a change to the inbox :) I mean the social process
>> aspect of things. So anyway, feel free to correct me on etiquette and
>> protocol.
>
> I have nothing to correct really, but I thought I would comment on the
> etiquette since you brought it up. I may be overlooking something but
> the only things I would suggest for inbox committers is:
>
> 1. Update completely to current trunk before submitting to the inbox.
> This ensure that your submission's ancestor will be the most recent
> version in the trunk and is about the best you can do to make it easier
> on core developers to merge your changes.
>
> 2. Write a good comment. Try to keep it terse but touch on the main
> points and if there is a Mantis issue, note the relevant issue
> number(s).
>
> 3. Another I've thought of which is purely optional but I think we
> should consider strongly suggesting is that you create an account at
> source.squeak.org and login before committing. Certainly the repository
> is world-writable but submitting it with your account helps to ensure
> proper attribution and also gives us a point to ensure that submitters
> have agreed to the MIT licensing.
>
> Truthfully I would advocate requiring signing in, but this would require
> changes to SqueakSource to enforce I believe and may be considered an
> unnecessary hurdle.
>
> That's all I can think of at the moment anyway,
>
> Ken

I've been thinking about your third point too. The change necessary to the source server would not be too hard I think. But identifying uploaders would be helpful IMHO. It's also good for bragging, since only if you are logged in are commits counted for you :)

Does anyone think it would be too much of a burden to create an account?

- Bert -

Casey Ransberger-2

Re: MessageNames: clicking on class names

I'd rather we all had accounts too I think. Sometimes I'm not clear on what came from who by initials alone. It's nice to see what different people are working on.

On Wed, Mar 31, 2010 at 2:53 PM, Bert Freudenberg <[hidden email]> wrote:

On 31.03.2010, at 23:45, Ken Causey wrote:
>
> On Wed, 2010-03-31 at 22:52 +0200, Frank Shearar wrote:
>> Hi,
>>
>> I'm not entirely sure how to contribute to the inbox. Well, I know
>> enough to commit a change to the inbox :) I mean the social process
>> aspect of things. So anyway, feel free to correct me on etiquette and
>> protocol.
>
> I have nothing to correct really, but I thought I would comment on the
> etiquette since you brought it up. I may be overlooking something but
> the only things I would suggest for inbox committers is:
>
> 1. Update completely to current trunk before submitting to the inbox.
> This ensure that your submission's ancestor will be the most recent
> version in the trunk and is about the best you can do to make it easier
> on core developers to merge your changes.
>
> 2. Write a good comment. Try to keep it terse but touch on the main
> points and if there is a Mantis issue, note the relevant issue
> number(s).
>
> 3. Another I've thought of which is purely optional but I think we
> should consider strongly suggesting is that you create an account at
> source.squeak.org and login before committing. Certainly the repository
> is world-writable but submitting it with your account helps to ensure
> proper attribution and also gives us a point to ensure that submitters
> have agreed to the MIT licensing.
>
> Truthfully I would advocate requiring signing in, but this would require
> changes to SqueakSource to enforce I believe and may be considered an
> unnecessary hurdle.
>
> That's all I can think of at the moment anyway,
>
> Ken

I've been thinking about your third point too. The change necessary to the source server would not be too hard I think. But identifying uploaders would be helpful IMHO. It's also good for bragging, since only if you are logged in are commits counted for you :)

Does anyone think it would be too much of a burden to create an account?

- Bert -

Frank Shearar

Re: MessageNames: clicking on class names

Can we make it so that the tools log in for us? Well, yes, I suppose it
can by one updating one's repository string?

MCHttpRepository
location: 'http://www.squeaksource.com/'
user: 'myaccount'
password: 'mypassword'

I'm happy to have a required login, and I'd like to avoid having to
manually log in anywhere too.

frank

Casey Ransberger wrote:

> I'd rather we all had accounts too I think. Sometimes I'm not clear on
> what came from who by initials alone. It's nice to see what different
> people are working on.
>
> +1
>
> On Wed, Mar 31, 2010 at 2:53 PM, Bert Freudenberg <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> On 31.03.2010, at 23:45, Ken Causey wrote:
> >
> > On Wed, 2010-03-31 at 22:52 +0200, Frank Shearar wrote:
> >> Hi,
> >>
> >> I'm not entirely sure how to contribute to the inbox. Well, I know
> >> enough to commit a change to the inbox :) I mean the social process
> >> aspect of things. So anyway, feel free to correct me on
> etiquette and
> >> protocol.
> >
> > I have nothing to correct really, but I thought I would comment
> on the
> > etiquette since you brought it up. I may be overlooking
> something but
> > the only things I would suggest for inbox committers is:
> >
> > 1. Update completely to current trunk before submitting to the inbox.
> > This ensure that your submission's ancestor will be the most recent
> > version in the trunk and is about the best you can do to make it
> easier
> > on core developers to merge your changes.
> >
> > 2. Write a good comment. Try to keep it terse but touch on the main
> > points and if there is a Mantis issue, note the relevant issue
> > number(s).
> >
> > 3. Another I've thought of which is purely optional but I think we
> > should consider strongly suggesting is that you create an account at
> > source.squeak.org <http://source.squeak.org> and login before
> committing. Certainly the repository
> > is world-writable but submitting it with your account helps to ensure
> > proper attribution and also gives us a point to ensure that
> submitters
> > have agreed to the MIT licensing.
> >
> > Truthfully I would advocate requiring signing in, but this would
> require
> > changes to SqueakSource to enforce I believe and may be considered an
> > unnecessary hurdle.
> >
> > That's all I can think of at the moment anyway,
> >
> > Ken
>
> I've been thinking about your third point too. The change necessary
> to the source server would not be too hard I think. But identifying
> uploaders would be helpful IMHO. It's also good for bragging, since
> only if you are logged in are commits counted for you :)
>
> Does anyone think it would be too much of a burden to create an account?
>
> - Bert -
>
>
>
>
>
> ------------------------------------------------------------------------
>
>

Bert Freudenberg

Login for Inbox submissions

On 01.04.2010, at 10:18, Frank Shearar wrote:
>
> Can we make it so that the tools log in for us? Well, yes, I suppose it can by one updating one's repository string?

Yes, like this:

MCHttpRepository
location: 'http://source.squeak.org/inbox'
user: 'myinitials'
password: 'mypassword'

Once you do that it will remember the password and log you in automatically.

- Bert -

>
> I'm happy to have a required login, and I'd like to avoid having to manually log in anywhere too.
>
> frank
>
> Casey Ransberger wrote:
>> I'd rather we all had accounts too I think. Sometimes I'm not clear on what came from who by initials alone. It's nice to see what different people are working on.
>> +1
>> On Wed, Mar 31, 2010 at 2:53 PM, Bert Freudenberg <[hidden email] <mailto:[hidden email]>> wrote:
>> On 31.03.2010, at 23:45, Ken Causey wrote:
>> >
>> > 3. Another I've thought of which is purely optional but I think we
>> > should consider strongly suggesting is that you create an account at
>> > source.squeak.org <http://source.squeak.org> and login before
>> committing. Certainly the repository
>> > is world-writable but submitting it with your account helps to ensure
>> > proper attribution and also gives us a point to ensure that
>> submitters
>> > have agreed to the MIT licensing.
>> >
>> > Truthfully I would advocate requiring signing in, but this would
>> require
>> > changes to SqueakSource to enforce I believe and may be considered an
>> > unnecessary hurdle.
>> >
>> > That's all I can think of at the moment anyway,
>> >
>> > Ken
>> I've been thinking about your third point too. The change necessary
>> to the source server would not be too hard I think. But identifying
>> uploaders would be helpful IMHO. It's also good for bragging, since
>> only if you are logged in are commits counted for you :)
>> Does anyone think it would be too much of a burden to create an account?
>> - Bert -
>> ------------------------------------------------------------------------
>
>

Edgar De Cleene

Re: Login for Inbox submissions

On 4/1/10 6:17 AM, "Bert Freudenberg" <[hidden email]> wrote:

>
> Yes, like this:
>
> MCHttpRepository
> location: 'http://source.squeak.org/inbox'
> user: 'myinitials'
> password: 'mypassword'
>
> Once you do that it will remember the password and log you in automatically.
>
> - Bert -

That means the squeak source image of trunk running the repositories let
some guy log once he/ she change to his name / pass ?

Example:

Cassandra Lopez log as mynitials / mypassword
Then she changes to cassandra matrix2010
The image running the repositories save his name / pass
Next time she logs as cassandra matrix2010

Or ?

Bert Freudenberg

Re: Login for Inbox submissions

On 01.04.2010, at 12:48, Edgar J. De Cleene wrote:

>
>
>
>
> On 4/1/10 6:17 AM, "Bert Freudenberg" <[hidden email]> wrote:
>
>>
>> Yes, like this:
>>
>> MCHttpRepository
>> location: 'http://source.squeak.org/inbox'
>> user: 'myinitials'
>> password: 'mypassword'
>>
>> Once you do that it will remember the password and log you in automatically.
>>
>> - Bert -
>
> That means the squeak source image of trunk running the repositories let
> some guy log once he/ she change to his name / pass ?
>
> Example:
>
> Cassandra Lopez log as mynitials / mypassword
> Then she changes to cassandra matrix2010
> The image running the repositories save his name / pass
> Next time she logs as cassandra matrix2010
>
> Or ?

She edits the repository info

and enters her initials and password:

then saves the image.

If Cassandra is worried about saving the password in the image, she can leave it empty. Then MC will ask every time the password is needed.

If she finds all this too inconvenient, she can store her initials and password in the external "prefs/mcSettings" file instead. Then she never has to enter them manually, even after downloading a new image. The file format is documented in the "userAndPasswordFromSettingsDo:" method:

- Bert -

PastedGraphic-8.png (26K) Download Attachment

PastedGraphic-9.png (15K) Download Attachment

PastedGraphic-11.png (17K) Download Attachment

Edgar De Cleene

Re: Login for Inbox submissions

On 4/1/10 10:02 AM, "Bert Freudenberg" <[hidden email]> wrote:

> On 01.04.2010, at 12:48, Edgar J. De Cleene wrote:
>>
>>
>>
>>
>> On 4/1/10 6:17 AM, "Bert Freudenberg" <[hidden email]> wrote:
>>
>>>
>>> Yes, like this:
>>>
>>> MCHttpRepository
>>> location: 'http://source.squeak.org/inbox'
>>> user: 'myinitials'
>>> password: 'mypassword'
>>>
>>> Once you do that it will remember the password and log you in automatically.
>>>
>>> - Bert -
>>
>> That means the squeak source image of trunk running the repositories let
>> some guy log once he/ she change to his name / pass ?
>>
>> Example:
>>
>> Cassandra Lopez log as mynitials / mypassword
>> Then she changes to cassandra matrix2010
>> The image running the repositories save his name / pass
>> Next time she logs as cassandra matrix2010
>>
>> Or ?
>
> She edits the repository info
>
> ?
> ?
> ?
>
>
> and enters her initials and password:
>
> ?
> ?
> ?
>
>
> then saves the image.
>
> If Cassandra is worried about saving the password in the image, she can leave
> it empty. Then MC will ask every time the password is needed.
>
> If she finds all this too inconvenient, she can store her initials and
> password in the external "prefs/mcSettings" file instead. Then she never has
> to enter them manually, even after downloading a new image. The file format is
> documented in the "userAndPasswordFromSettingsDo:" method:
>
> ?
> ?
> ?
>
> - Bert -
>
>
> ?

Very clear but...

This is for the client image, the one any have in his/her machine

How about the server image, the giant one running and having thousands of
packages, etc.

Viele danke

Bert Freudenberg

Re: Login for Inbox submissions

On 01.04.2010, at 16:21, Edgar J. De Cleene wrote:

>
>
>
>
> On 4/1/10 10:02 AM, "Bert Freudenberg" <[hidden email]> wrote:
>
>> On 01.04.2010, at 12:48, Edgar J. De Cleene wrote:
>>>
>>>
>>>
>>>
>>> On 4/1/10 6:17 AM, "Bert Freudenberg" <[hidden email]> wrote:
>>>
>>>>
>>>> Yes, like this:
>>>>
>>>> MCHttpRepository
>>>> location: 'http://source.squeak.org/inbox'
>>>> user: 'myinitials'
>>>> password: 'mypassword'
>>>>
>>>> Once you do that it will remember the password and log you in automatically.
>>>>
>>>> - Bert -
>>>
>>> That means the squeak source image of trunk running the repositories let
>>> some guy log once he/ she change to his name / pass ?
>>>
>>> Example:
>>>
>>> Cassandra Lopez log as mynitials / mypassword
>>> Then she changes to cassandra matrix2010
>>> The image running the repositories save his name / pass
>>> Next time she logs as cassandra matrix2010
>>>
>>> Or ?
>>
>> She edits the repository info
>>
>> ?
>> ?
>> ?
>>
>>
>> and enters her initials and password:
>>
>> ?
>> ?
>> ?
>>
>>
>> then saves the image.
>>
>> If Cassandra is worried about saving the password in the image, she can leave
>> it empty. Then MC will ask every time the password is needed.
>>
>> If she finds all this too inconvenient, she can store her initials and
>> password in the external "prefs/mcSettings" file instead. Then she never has
>> to enter them manually, even after downloading a new image. The file format is
>> documented in the "userAndPasswordFromSettingsDo:" method:
>>
>> ?
>> ?
>> ?
>>
>> - Bert -
>>
>>
>> ?
>
> Very clear but...
>
> This is for the client image, the one any have in his/her machine
>
> How about the server image, the giant one running and having thousands of
> packages, etc.
>
> Viele danke

I don't understand the question. What do you want to know about the server image?

It's just a regular trunk image that has the squeaksource package and its dependencies loaded. Those are publicly available at
http://source.squeak.org/ss.html

And I would not call a 30 MB image "giant".

- Bert -

Chris Muller-3

Re: MessageNames: clicking on class names

In reply to this post by Frank Shearar

> I noticed that the new search morph in the docking bar will bring up class
> names as well as selector names. For instance, searching for "obj" will show
> things like "AbstractObjectsAsMethod".
>
> If you hit the browse button on these entries, though, nothing happens.

This is because the preference, #alternativeBrowseIt is disabled, by
default. Crazy isn't it? If just enable that and you can (b)rowse
hierarchy's, i(m)plementors, or se(n)ders with those keys..

- Chris

Ken Causey-3

Re: MessageNames: clicking on class names

On Thu, 2010-04-01 at 13:20 -0600, Chris Muller wrote:

> > I noticed that the new search morph in the docking bar will bring up class
> > names as well as selector names. For instance, searching for "obj" will show
> > things like "AbstractObjectsAsMethod".
> >
> > If you hit the browse button on these entries, though, nothing happens.
>
> This is because the preference, #alternativeBrowseIt is disabled, by
> default. Crazy isn't it? If just enable that and you can (b)rowse
> hierarchy's, i(m)plementors, or se(n)ders with those keys..
>
> - Chris

It's not that simple. There is another clearly related problem that
this does not address (oh, and your solution does not fix the problem,
it simply leaves out the most glaring instance of the problem). The
'instance', '?', 'class' buttons have the same problem as the alternate
browser buttons. Even more fun because they are in a subpane of the
upper frame, try to enlarge just the source code pane by pulling the
main divider up...the instance/?/class button pane is squashed and once
it reaches it's lower limit you can't move the main divider up any
farther. Instead you have to start by dragging up the divider between
the pane listing the classes and the button pane then drag up the
overall divider leaving enough space for the buttons. Not intuitive in
my book.

Ken

signature.asc (197 bytes) Download Attachment

Ken Causey-3

Re: MessageNames: clicking on class names

Oops, it seems I really need to work on my reading comprehension. I
somehow mistook Chris' response for being part of my 'Why do the
buttons...' thread when it has in fact nothing to do with it. My
apologies Chris. With the exception of the first sentence or two, my
points below are still accurate, just not relevant for this thread.

Sorry,

Ken

On Thu, 2010-04-01 at 14:59 -0500, Ken Causey wrote:

> On Thu, 2010-04-01 at 13:20 -0600, Chris Muller wrote:
> > > I noticed that the new search morph in the docking bar will bring up class
> > > names as well as selector names. For instance, searching for "obj" will show
> > > things like "AbstractObjectsAsMethod".
> > >
> > > If you hit the browse button on these entries, though, nothing happens.
> >
> > This is because the preference, #alternativeBrowseIt is disabled, by
> > default. Crazy isn't it? If just enable that and you can (b)rowse
> > hierarchy's, i(m)plementors, or se(n)ders with those keys..
> >
> > - Chris
>
> It's not that simple. There is another clearly related problem that
> this does not address (oh, and your solution does not fix the problem,
> it simply leaves out the most glaring instance of the problem). The
> 'instance', '?', 'class' buttons have the same problem as the alternate
> browser buttons. Even more fun because they are in a subpane of the
> upper frame, try to enlarge just the source code pane by pulling the
> main divider up...the instance/?/class button pane is squashed and once
> it reaches it's lower limit you can't move the main divider up any
> farther. Instead you have to start by dragging up the divider between
> the pane listing the classes and the button pane then drag up the
> overall divider leaving enough space for the buttons. Not intuitive in
> my book.
>
> Ken

signature.asc (197 bytes) Download Attachment

Frank Shearar

Re: MessageNames: clicking on class names

In reply to this post by Ken Causey-3

Ken Causey wrote:

> On Thu, 2010-04-01 at 13:20 -0600, Chris Muller wrote:
>>> I noticed that the new search morph in the docking bar will bring up class
>>> names as well as selector names. For instance, searching for "obj" will show
>>> things like "AbstractObjectsAsMethod".
>>>
>>> If you hit the browse button on these entries, though, nothing happens.
>> This is because the preference, #alternativeBrowseIt is disabled, by
>> default. Crazy isn't it? If just enable that and you can (b)rowse
>> hierarchy's, i(m)plementors, or se(n)ders with those keys..
>>
>> - Chris
>
> It's not that simple. There is another clearly related problem that
> this does not address (oh, and your solution does not fix the problem,
> it simply leaves out the most glaring instance of the problem). The
> 'instance', '?', 'class' buttons have the same problem as the alternate
> browser buttons. Even more fun because they are in a subpane of the
> upper frame, try to enlarge just the source code pane by pulling the
> main divider up...the instance/?/class button pane is squashed and once
> it reaches it's lower limit you can't move the main divider up any
> farther. Instead you have to start by dragging up the divider between
> the pane listing the classes and the button pane then drag up the
> overall divider leaving enough space for the buttons. Not intuitive in
> my book.

Ah, now that I play around with the Browser, I see what you mean. The
behaviour is... not ideal.

I'd like to see the instance/?/class buttons resize like the
browse/send/implementor/etc buttons: constant size up until a point, and
then decreasing proportional to their containing panel.

I think you'd get this by putting both the instance/?/class buttons'
PluggablePanel and the class list's PluggableListMorphPlus inside a
common parent PluggablePanel.

I'll try play around with it tonight and see what I can do. (Given that
my total ToolBuilder experience is the hour I spent on
Tools-fbs.(220|221).mcz, I look forward to gentle pointers on how to not
make a hash of things!)

frank

Ken Causey-3

Re: UI Buttons (was Re: [squeak-dev] MessageNames: clicking on class names)

On Fri, 2010-04-02 at 18:38 +0200, Frank Shearar wrote:

> Ken Causey wrote:
> > On Thu, 2010-04-01 at 13:20 -0600, Chris Muller wrote:
> >>> I noticed that the new search morph in the docking bar will bring up class
> >>> names as well as selector names. For instance, searching for "obj" will show
> >>> things like "AbstractObjectsAsMethod".
> >>>
> >>> If you hit the browse button on these entries, though, nothing happens.
> >> This is because the preference, #alternativeBrowseIt is disabled, by
> >> default. Crazy isn't it? If just enable that and you can (b)rowse
> >> hierarchy's, i(m)plementors, or se(n)ders with those keys..
> >>
> >> - Chris
> >
> > It's not that simple. There is another clearly related problem that
> > this does not address (oh, and your solution does not fix the problem,
> > it simply leaves out the most glaring instance of the problem). The
> > 'instance', '?', 'class' buttons have the same problem as the alternate
> > browser buttons. Even more fun because they are in a subpane of the
> > upper frame, try to enlarge just the source code pane by pulling the
> > main divider up...the instance/?/class button pane is squashed and once
> > it reaches it's lower limit you can't move the main divider up any
> > farther. Instead you have to start by dragging up the divider between
> > the pane listing the classes and the button pane then drag up the
> > overall divider leaving enough space for the buttons. Not intuitive in
> > my book.
>
> Ah, now that I play around with the Browser, I see what you mean. The
> behaviour is... not ideal.
>
> I'd like to see the instance/?/class buttons resize like the
> browse/send/implementor/etc buttons: constant size up until a point, and
> then decreasing proportional to their containing panel.
>
> I think you'd get this by putting both the instance/?/class buttons'
> PluggablePanel and the class list's PluggableListMorphPlus inside a
> common parent PluggablePanel.
>
> I'll try play around with it tonight and see what I can do. (Given that
> my total ToolBuilder experience is the hour I spent on
> Tools-fbs.(220|221).mcz, I look forward to gentle pointers on how to not
> make a hash of things!)
>
> frank

Thanks Frank,

I'm puzzled. What is the use case for having the buttons resized? It
seems to me that a button has a desirable size and you make it that size
and leave it.

I appreciate your looking into this.

Ken

signature.asc (197 bytes) Download Attachment

Casey Ransberger-2

Re: UI Buttons (was Re: [squeak-dev] MessageNames: clicking on class names)

Check out RealEstateAgent. System tries to decided how big default windows should be based on staggering policy (from prefs) and size of display. The buttons resize dynamically in part to accommodate this (I think.) On my little display, The system browser opens to small that it's unusable. I have a one line "fix" for this in the inbox, but it looks like no one has (or perhaps will) apply it. The deal is, if a default window height is less that 300, it's useless on my box, so I added a check that sets it to 300 hundred at minimum.

FWIW, I hate that the buttons resize, RealEstateAgent is weird, and I can't wait to dig in an rewrite some of this junk. At this point though, my guess is that this stuff will have to wait for 4.2.

On Fri, Apr 2, 2010 at 2:02 PM, Ken Causey <[hidden email]> wrote:

On Fri, 2010-04-02 at 18:38 +0200, Frank Shearar wrote:
> Ken Causey wrote:
> > On Thu, 2010-04-01 at 13:20 -0600, Chris Muller wrote:
> >>> I noticed that the new search morph in the docking bar will bring up class
> >>> names as well as selector names. For instance, searching for "obj" will show
> >>> things like "AbstractObjectsAsMethod".
> >>>
> >>> If you hit the browse button on these entries, though, nothing happens.
> >> This is because the preference, #alternativeBrowseIt is disabled, by
> >> default. Crazy isn't it? If just enable that and you can (b)rowse
> >> hierarchy's, i(m)plementors, or se(n)ders with those keys..
> >>
> >> - Chris
> >
> > It's not that simple. There is another clearly related problem that
> > this does not address (oh, and your solution does not fix the problem,
> > it simply leaves out the most glaring instance of the problem). The
> > 'instance', '?', 'class' buttons have the same problem as the alternate
> > browser buttons. Even more fun because they are in a subpane of the
> > upper frame, try to enlarge just the source code pane by pulling the
> > main divider up...the instance/?/class button pane is squashed and once
> > it reaches it's lower limit you can't move the main divider up any
> > farther. Instead you have to start by dragging up the divider between
> > the pane listing the classes and the button pane then drag up the
> > overall divider leaving enough space for the buttons. Not intuitive in
> > my book.
>
> Ah, now that I play around with the Browser, I see what you mean. The
> behaviour is... not ideal.
>
> I'd like to see the instance/?/class buttons resize like the
> browse/send/implementor/etc buttons: constant size up until a point, and
> then decreasing proportional to their containing panel.
>
> I think you'd get this by putting both the instance/?/class buttons'
> PluggablePanel and the class list's PluggableListMorphPlus inside a
> common parent PluggablePanel.
>
> I'll try play around with it tonight and see what I can do. (Given that
> my total ToolBuilder experience is the hour I spent on
> Tools-fbs.(220|221).mcz, I look forward to gentle pointers on how to not
> make a hash of things!)
>
> frank

Thanks Frank,

I'm puzzled. What is the use case for having the buttons resized? It
seems to me that a button has a desirable size and you make it that size
and leave it.

I appreciate your looking into this.

Ken

bpi

Re: UI Buttons (was Re: [squeak-dev] MessageNames: clicking on class names)

In reply to this post by Ken Causey-3

Dear fellow Squeakers,

I think I solved the issue with resizing button heights which was bothering me for a long time as well. I copied the following package versions to the inbox:
- MorphicTests-bp.14
- ToolBuilder-MVC-bp.19
- Tools-bp.220
- Monticello-bp.387

Please review it and let me know what you think.

Cheers,
Bernhard

Am 02.04.2010 um 23:02 schrieb Ken Causey:

> On Fri, 2010-04-02 at 18:38 +0200, Frank Shearar wrote:
>> Ken Causey wrote:
>>> On Thu, 2010-04-01 at 13:20 -0600, Chris Muller wrote:
>>>>> I noticed that the new search morph in the docking bar will bring up class
>>>>> names as well as selector names. For instance, searching for "obj" will show
>>>>> things like "AbstractObjectsAsMethod".
>>>>>
>>>>> If you hit the browse button on these entries, though, nothing happens.
>>>> This is because the preference, #alternativeBrowseIt is disabled, by
>>>> default. Crazy isn't it? If just enable that and you can (b)rowse
>>>> hierarchy's, i(m)plementors, or se(n)ders with those keys..
>>>>
>>>> - Chris
>>>
>>> It's not that simple. There is another clearly related problem that
>>> this does not address (oh, and your solution does not fix the problem,
>>> it simply leaves out the most glaring instance of the problem). The
>>> 'instance', '?', 'class' buttons have the same problem as the alternate
>>> browser buttons. Even more fun because they are in a subpane of the
>>> upper frame, try to enlarge just the source code pane by pulling the
>>> main divider up...the instance/?/class button pane is squashed and once
>>> it reaches it's lower limit you can't move the main divider up any
>>> farther. Instead you have to start by dragging up the divider between
>>> the pane listing the classes and the button pane then drag up the
>>> overall divider leaving enough space for the buttons. Not intuitive in
>>> my book.
>>
>> Ah, now that I play around with the Browser, I see what you mean. The
>> behaviour is... not ideal.
>>
>> I'd like to see the instance/?/class buttons resize like the
>> browse/send/implementor/etc buttons: constant size up until a point, and
>> then decreasing proportional to their containing panel.
>>
>> I think you'd get this by putting both the instance/?/class buttons'
>> PluggablePanel and the class list's PluggableListMorphPlus inside a
>> common parent PluggablePanel.
>>
>> I'll try play around with it tonight and see what I can do. (Given that
>> my total ToolBuilder experience is the hour I spent on
>> Tools-fbs.(220|221).mcz, I look forward to gentle pointers on how to not
>> make a hash of things!)
>>
>> frank
>
> Thanks Frank,
>
> I'm puzzled. What is the use case for having the buttons resized? It
> seems to me that a button has a desirable size and you make it that size
> and leave it.
>
> I appreciate your looking into this.
>
> Ken
>

Andreas.Raab

Re: UI Buttons (was Re: MessageNames: clicking on class names)

On 4/2/2010 2:50 PM, Bernhard Pieber wrote:
> Dear fellow Squeakers,
>
> I think I solved the issue with resizing button heights which was bothering me for a long time as well. I copied the following package versions to the inbox:
> - MorphicTests-bp.14
> - ToolBuilder-MVC-bp.19
> - Tools-bp.220
> - Monticello-bp.387
>
> Please review it and let me know what you think.

Love it! It's really useful (and long needed :-)

Cheers,
- Andreas

> Am 02.04.2010 um 23:02 schrieb Ken Causey:
>
>> On Fri, 2010-04-02 at 18:38 +0200, Frank Shearar wrote:
>>> Ken Causey wrote:
>>>> On Thu, 2010-04-01 at 13:20 -0600, Chris Muller wrote:
>>>>>> I noticed that the new search morph in the docking bar will bring up class
>>>>>> names as well as selector names. For instance, searching for "obj" will show
>>>>>> things like "AbstractObjectsAsMethod".
>>>>>>
>>>>>> If you hit the browse button on these entries, though, nothing happens.
>>>>> This is because the preference, #alternativeBrowseIt is disabled, by
>>>>> default. Crazy isn't it? If just enable that and you can (b)rowse
>>>>> hierarchy's, i(m)plementors, or se(n)ders with those keys..
>>>>>
>>>>> - Chris
>>>>
>>>> It's not that simple. There is another clearly related problem that
>>>> this does not address (oh, and your solution does not fix the problem,
>>>> it simply leaves out the most glaring instance of the problem). The
>>>> 'instance', '?', 'class' buttons have the same problem as the alternate
>>>> browser buttons. Even more fun because they are in a subpane of the
>>>> upper frame, try to enlarge just the source code pane by pulling the
>>>> main divider up...the instance/?/class button pane is squashed and once
>>>> it reaches it's lower limit you can't move the main divider up any
>>>> farther. Instead you have to start by dragging up the divider between
>>>> the pane listing the classes and the button pane then drag up the
>>>> overall divider leaving enough space for the buttons. Not intuitive in
>>>> my book.
>>>
>>> Ah, now that I play around with the Browser, I see what you mean. The
>>> behaviour is... not ideal.
>>>
>>> I'd like to see the instance/?/class buttons resize like the
>>> browse/send/implementor/etc buttons: constant size up until a point, and
>>> then decreasing proportional to their containing panel.
>>>
>>> I think you'd get this by putting both the instance/?/class buttons'
>>> PluggablePanel and the class list's PluggableListMorphPlus inside a
>>> common parent PluggablePanel.
>>>
>>> I'll try play around with it tonight and see what I can do. (Given that
>>> my total ToolBuilder experience is the hour I spent on
>>> Tools-fbs.(220|221).mcz, I look forward to gentle pointers on how to not
>>> make a hash of things!)
>>>
>>> frank
>>
>> Thanks Frank,
>>
>> I'm puzzled. What is the use case for having the buttons resized? It
>> seems to me that a button has a desirable size and you make it that size
>> and leave it.
>>
>> I appreciate your looking into this.
>>
>> Ken
>>
>
>
>

Frank Shearar

Re: UI Buttons (was Re: [squeak-dev] MessageNames: clicking on class names)

In reply to this post by Ken Causey-3

Ken Causey wrote:

> On Fri, 2010-04-02 at 18:38 +0200, Frank Shearar wrote:
>> Ken Causey wrote:
>>> On Thu, 2010-04-01 at 13:20 -0600, Chris Muller wrote:
>>>>> I noticed that the new search morph in the docking bar will bring up class
>>>>> names as well as selector names. For instance, searching for "obj" will show
>>>>> things like "AbstractObjectsAsMethod".
>>>>>
>>>>> If you hit the browse button on these entries, though, nothing happens.
>>>> This is because the preference, #alternativeBrowseIt is disabled, by
>>>> default. Crazy isn't it? If just enable that and you can (b)rowse
>>>> hierarchy's, i(m)plementors, or se(n)ders with those keys..
>>>>
>>>> - Chris
>>> It's not that simple. There is another clearly related problem that
>>> this does not address (oh, and your solution does not fix the problem,
>>> it simply leaves out the most glaring instance of the problem). The
>>> 'instance', '?', 'class' buttons have the same problem as the alternate
>>> browser buttons. Even more fun because they are in a subpane of the
>>> upper frame, try to enlarge just the source code pane by pulling the
>>> main divider up...the instance/?/class button pane is squashed and once
>>> it reaches it's lower limit you can't move the main divider up any
>>> farther. Instead you have to start by dragging up the divider between
>>> the pane listing the classes and the button pane then drag up the
>>> overall divider leaving enough space for the buttons. Not intuitive in
>>> my book.
>> Ah, now that I play around with the Browser, I see what you mean. The
>> behaviour is... not ideal.
>>
>> I'd like to see the instance/?/class buttons resize like the
>> browse/send/implementor/etc buttons: constant size up until a point, and
>> then decreasing proportional to their containing panel.
>>
>> I think you'd get this by putting both the instance/?/class buttons'
>> PluggablePanel and the class list's PluggableListMorphPlus inside a
>> common parent PluggablePanel.
>>
>> I'll try play around with it tonight and see what I can do. (Given that
>> my total ToolBuilder experience is the hour I spent on
>> Tools-fbs.(220|221).mcz, I look forward to gentle pointers on how to not
>> make a hash of things!)
>>
>> frank
>
> Thanks Frank,
>
> I'm puzzled. What is the use case for having the buttons resized? It
> seems to me that a button has a desirable size and you make it that size
> and leave it.
>
> I appreciate your looking into this.

I agree, Ken. That'd be my first prize. But as a less ambitious goal I
just want all the buttons to work in the same way.

But I think what I was TRYING to say was what you were describing.
Playing around some more this evening, I found the main annoyance was
not resizing the Browser (the basis of my want-to-have description
above) but when moving the divider between the lists and the code pane.
That's when the makes-Ken-sad behaviour really kicks in.

I did try play around with Browser this evening (see my other mail), and
realised that I need to read a lot more ToolBuilder code before I can
properly address the issue. Which is fine: I find debugging a great tool
for learning a codebase.

frank

Frank Shearar

Re: UI Buttons (was Re: [squeak-dev] MessageNames: clicking on class names)

In reply to this post by bpi

Nice!

So it's the use of #offset in the LayoutFrame that lets you define a
fixed size, yes?

frank

Bernhard Pieber wrote:

> Dear fellow Squeakers,
>
> I think I solved the issue with resizing button heights which was bothering me for a long time as well. I copied the following package versions to the inbox:
> - MorphicTests-bp.14
> - ToolBuilder-MVC-bp.19
> - Tools-bp.220
> - Monticello-bp.387
>
> Please review it and let me know what you think.
>
> Cheers,
> Bernhard
>
> Am 02.04.2010 um 23:02 schrieb Ken Causey:
>
>> On Fri, 2010-04-02 at 18:38 +0200, Frank Shearar wrote:
>>> Ken Causey wrote:
>>>> On Thu, 2010-04-01 at 13:20 -0600, Chris Muller wrote:
>>>>>> I noticed that the new search morph in the docking bar will bring up class
>>>>>> names as well as selector names. For instance, searching for "obj" will show
>>>>>> things like "AbstractObjectsAsMethod".
>>>>>>
>>>>>> If you hit the browse button on these entries, though, nothing happens.
>>>>> This is because the preference, #alternativeBrowseIt is disabled, by
>>>>> default. Crazy isn't it? If just enable that and you can (b)rowse
>>>>> hierarchy's, i(m)plementors, or se(n)ders with those keys..
>>>>>
>>>>> - Chris
>>>> It's not that simple. There is another clearly related problem that
>>>> this does not address (oh, and your solution does not fix the problem,
>>>> it simply leaves out the most glaring instance of the problem). The
>>>> 'instance', '?', 'class' buttons have the same problem as the alternate
>>>> browser buttons. Even more fun because they are in a subpane of the
>>>> upper frame, try to enlarge just the source code pane by pulling the
>>>> main divider up...the instance/?/class button pane is squashed and once
>>>> it reaches it's lower limit you can't move the main divider up any
>>>> farther. Instead you have to start by dragging up the divider between
>>>> the pane listing the classes and the button pane then drag up the
>>>> overall divider leaving enough space for the buttons. Not intuitive in
>>>> my book.
>>> Ah, now that I play around with the Browser, I see what you mean. The
>>> behaviour is... not ideal.
>>>
>>> I'd like to see the instance/?/class buttons resize like the
>>> browse/send/implementor/etc buttons: constant size up until a point, and
>>> then decreasing proportional to their containing panel.
>>>
>>> I think you'd get this by putting both the instance/?/class buttons'
>>> PluggablePanel and the class list's PluggableListMorphPlus inside a
>>> common parent PluggablePanel.
>>>
>>> I'll try play around with it tonight and see what I can do. (Given that
>>> my total ToolBuilder experience is the hour I spent on
>>> Tools-fbs.(220|221).mcz, I look forward to gentle pointers on how to not
>>> make a hash of things!)
>>>
>>> frank
>> Thanks Frank,
>>
>> I'm puzzled. What is the use case for having the buttons resized? It
>> seems to me that a button has a desirable size and you make it that size
>> and leave it.
>>
>> I appreciate your looking into this.
>>
>> Ken
>>
>
>
>
>