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
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
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:
- 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.
- 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).
- 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 -
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 bert@freudenbergs.dewrote:
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:
- 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.
- 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).
- 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 -
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 <bert@freudenbergs.de mailto:bert@freudenbergs.de> 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 -
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 <bert@freudenbergs.de mailto:bert@freudenbergs.de> 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 -
On 4/1/10 6:17 AM, "Bert Freudenberg" bert@freudenbergs.de 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 ?
On 01.04.2010, at 12:48, Edgar J. De Cleene wrote:
On 4/1/10 6:17 AM, "Bert Freudenberg" bert@freudenbergs.de 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 -
On 4/1/10 10:02 AM, "Bert Freudenberg" bert@freudenbergs.de wrote:
On 01.04.2010, at 12:48, Edgar J. De Cleene wrote:
On 4/1/10 6:17 AM, "Bert Freudenberg" bert@freudenbergs.de 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
On 01.04.2010, at 16:21, Edgar J. De Cleene wrote:
On 4/1/10 10:02 AM, "Bert Freudenberg" bert@freudenbergs.de wrote:
On 01.04.2010, at 12:48, Edgar J. De Cleene wrote:
On 4/1/10 6:17 AM, "Bert Freudenberg" bert@freudenbergs.de 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 -
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
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
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
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
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
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 ken@kencausey.com 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
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
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
On Fri, 2010-04-02 at 22:52 -0700, Andreas Raab wrote:
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
Yes! Thank you very much Bernard! It seems complaining does pay off on occasion. ;)
Ken
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
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
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bernhard Pieber -
Bert Freudenberg -
Casey Ransberger -
Chris Muller -
Edgar J. De Cleene -
Frank Shearar -
Ken Causey