[Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

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

[Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

Hannes Hirzel
Hello

A question: Art the ToolBuilder in Squeak 4.1 and Pharo 1.0 the same?
Or if there is a difference what is the impact of it?

Or put the question in another way. If I code an UI using the
ToolBuilder in Squeak 4.1 will it run in Pharo?

Regards
Hannes

Reply | Threaded
Open this post in threaded view
|

Re: [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

Andreas.Raab
On 4/21/2010 4:32 AM, Hannes Hirzel wrote:
> A question: Art the ToolBuilder in Squeak 4.1 and Pharo 1.0 the same?
> Or if there is a difference what is the impact of it?
>
> Or put the question in another way. If I code an UI using the
> ToolBuilder in Squeak 4.1 will it run in Pharo?

They are mostly the same but not identical. If there is interest in the
Pharo community we should merge the versions upstream in
http://www.squeaksource.com/ToolBuilder.html (contact me if you're
interested).

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

stephane ducasse-2
Yes we are.
Even if there was some discussions about the usefulness of toolbuilder spec - I would be in favor.

Stef

> On 4/21/2010 4:32 AM, Hannes Hirzel wrote:
>> A question: Art the ToolBuilder in Squeak 4.1 and Pharo 1.0 the same?
>> Or if there is a difference what is the impact of it?
>>
>> Or put the question in another way. If I code an UI using the
>> ToolBuilder in Squeak 4.1 will it run in Pharo?
>
> They are mostly the same but not identical. If there is interest in the Pharo community we should merge the versions upstream in http://www.squeaksource.com/ToolBuilder.html (contact me if you're interested).
>
> Cheers,
>  - Andreas
>


Reply | Threaded
Open this post in threaded view
|

Re: [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

Casey Ransberger-2
This is one of the things that made pulling current Polymorph stuff into Squeak painful. If we shared a common ToolBuilder implementation, I would image that other pain points might disappear too.

+1

On Thu, Apr 22, 2010 at 12:32 AM, stephane ducasse <[hidden email]> wrote:
Yes we are.
Even if there was some discussions about the usefulness of toolbuilder spec - I would be in favor.

Stef

> On 4/21/2010 4:32 AM, Hannes Hirzel wrote:
>> A question: Art the ToolBuilder in Squeak 4.1 and Pharo 1.0 the same?
>> Or if there is a difference what is the impact of it?
>>
>> Or put the question in another way. If I code an UI using the
>> ToolBuilder in Squeak 4.1 will it run in Pharo?
>
> They are mostly the same but not identical. If there is interest in the Pharo community we should merge the versions upstream in http://www.squeaksource.com/ToolBuilder.html (contact me if you're interested).
>
> Cheers,
>  - Andreas
>





Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

Henrik Sperre Johansen
In reply to this post by Andreas.Raab

On Apr 22, 2010, at 5:25 29AM, Andreas Raab wrote:

> On 4/21/2010 4:32 AM, Hannes Hirzel wrote:
>> A question: Art the ToolBuilder in Squeak 4.1 and Pharo 1.0 the same?
>> Or if there is a difference what is the impact of it?
>>
>> Or put the question in another way. If I code an UI using the
>> ToolBuilder in Squeak 4.1 will it run in Pharo?
>
> They are mostly the same but not identical. If there is interest in the Pharo community we should merge the versions upstream in http://www.squeaksource.com/ToolBuilder.html (contact me if you're interested).
>
> Cheers,
>  - Andreas

ToolBuilder is one of the projects I believe deserve to stay fork-agnostic.

Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :)

With ToolBuilder, I also include the protocol of UIManagers.
In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels.

Cheers,
Henry
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

Henrik Sperre Johansen

On Apr 22, 2010, at 10:21 20AM, Henrik Johansen wrote:


On Apr 22, 2010, at 5:25 29AM, Andreas Raab wrote:

On 4/21/2010 4:32 AM, Hannes Hirzel wrote:
A question: Art the ToolBuilder in Squeak 4.1 and Pharo 1.0 the same?
Or if there is a difference what is the impact of it?

Or put the question in another way. If I code an UI using the
ToolBuilder in Squeak 4.1 will it run in Pharo?

They are mostly the same but not identical. If there is interest in the Pharo community we should merge the versions upstream in http://www.squeaksource.com/ToolBuilder.html (contact me if you're interested).

Cheers,
- Andreas

ToolBuilder is one of the projects I believe deserve to stay fork-agnostic.

Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :)

With ToolBuilder, I also include the protocol of UIManagers.
In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels.

Cheers,
Henry


Should of course be noted, if you take a look in a Pharo image, this change has not been reflected in the ToolBuilder UIManager comment, nor the MorphicUIManager, just in the PSUIManager which is the default manager in Pharo. (Don't see that changing anytime soon though :) )

Cheers,
Henry


Reply | Threaded
Open this post in threaded view
|

Re: [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

Andreas.Raab
In reply to this post by Henrik Sperre Johansen
On 4/22/2010 1:21 AM, Henrik Johansen wrote:
> ToolBuilder is one of the projects I believe deserve to stay fork-agnostic.
>
> Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :)

That's not so difficult. Let's start by just merging the code bases, and
see where this leads. I expect few, if any difficulties here. Let's add
some test to document the changes (like the one Torsten was bitten by)
and we should be pretty much covered.

Further out, I don't expect us to stay closely in sync. The whole issue
of upstream vs. downstream packages is an open one, so my opinion is
that we should merge when it makes sense (i.e., new features being
added) but otherwise let each project have its own choices.

> With ToolBuilder, I also include the protocol of UIManagers.
> In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels.

What can I say ... I actually said in that discussion that the right
choice is to introduce a different protocol, i.e., request:onCancel: or
something similar. Now we'll end up with a new protocol anyways - I
don't expect Pharo to change (too much pride involved) and I don't
expect Squeak to change (too much legacy code involved) so a new
protocol for the people who care about compatibility going forward is
really the only option (which can also be back-ported if necessary). The
end result will be that we'll declare the return value of #request: to
be "undefined" if the dialog is canceled and recommend using the new
protocol.

It's a great lesson about how not to break an existing protocol. If
Pharo had introduced a new protocol we could have just implemented it in
Squeak and be done. Instead, the end result will be that a new protocol
is introduced anyway and that nobody will be able to reliably use the
the old protocol. Consider it a lesson for the next time an issue like
this comes up - if you're interested in compatibility breaking an
existing protocol isn't the smart choice, in particular when it comes to
cross-platform / cross-dialect protocols.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

Stéphane Ducasse

On Apr 22, 2010, at 11:10 AM, Andreas Raab wrote:

> On 4/22/2010 1:21 AM, Henrik Johansen wrote:
>> ToolBuilder is one of the projects I believe deserve to stay fork-agnostic.
>>
>> Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :)
>
> That's not so difficult. Let's start by just merging the code bases, and see where this leads. I expect few, if any difficulties here. Let's add some test to document the changes (like the one Torsten was bitten by) and we should be pretty much covered.
>
> Further out, I don't expect us to stay closely in sync. The whole issue of upstream vs. downstream packages is an open one, so my opinion is that we should merge when it makes sense (i.e., new features being added) but otherwise let each project have its own choices.

Agreed.

>
>> With ToolBuilder, I also include the protocol of UIManagers.
>> In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels.
>
> What can I say ... I actually said in that discussion that the right choice is to introduce a different protocol, i.e., request:onCancel: or something similar. Now we'll end up with a new protocol anyways - I don't expect Pharo to change (too much pride involved) and I don't expect Squeak to change (too much legacy code involved) so a new protocol for the people who care about compatibility going forward is really the only option (which can also be back-ported if necessary). The end result will be that we'll declare the return value of #request: to be "undefined" if the dialog is canceled and recommend using the new protocol.

I know you remember I was in favor of your solution.

> It's a great lesson about how not to break an existing protocol. If Pharo had introduced a new protocol we could have just implemented it in Squeak and be done. Instead, the end result will be that a new protocol is introduced anyway and that nobody will be able to reliably use the the old protocol. Consider it a lesson for the next time an issue like this comes up - if you're interested in compatibility breaking an existing protocol isn't the smart choice, in particular when it comes to cross-platform / cross-dialect protocols.
>
> Cheers,
>  - Andreas
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

Henrik Sperre Johansen
In reply to this post by Andreas.Raab

On Apr 22, 2010, at 11:10 47AM, Andreas Raab wrote:

> On 4/22/2010 1:21 AM, Henrik Johansen wrote:
>> ToolBuilder is one of the projects I believe deserve to stay fork-agnostic.
>>
>> Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :)
>
> That's not so difficult. Let's start by just merging the code bases, and see where this leads. I expect few, if any difficulties here. Let's add some test to document the changes (like the one Torsten was bitten by) and we should be pretty much covered.
>
> Further out, I don't expect us to stay closely in sync. The whole issue of upstream vs. downstream packages is an open one, so my opinion is that we should merge when it makes sense (i.e., new features being added) but otherwise let each project have its own choices.
>
>> With ToolBuilder, I also include the protocol of UIManagers.
>> In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels.
>
> What can I say ... I actually said in that discussion that the right choice is to introduce a different protocol, i.e., request:onCancel: or something similar. Now we'll end up with a new protocol anyways - I don't expect Pharo to change (too much pride involved) and I don't expect Squeak to change (too much legacy code involved) so a new protocol for the people who care about compatibility going forward is really the only option (which can also be back-ported if necessary). The end result will be that we'll declare the return value of #request: to be "undefined" if the dialog is canceled and recommend using the new protocol.
>
> It's a great lesson about how not to break an existing protocol. If Pharo had introduced a new protocol we could have just implemented it in Squeak and be done. Instead, the end result will be that a new protocol is introduced anyway and that nobody will be able to reliably use the the old protocol. Consider it a lesson for the next time an issue like this comes up - if you're interested in compatibility breaking an existing protocol isn't the smart choice, in particular when it comes to cross-platform / cross-dialect protocols.
>
> Cheers,
>  - Andreas
No arguments from me, I strongly defended the approach you suggested at the time.
Sadly, (in my eyes) discussion just died, and everything got changed anyways.

Cheers,
Henry

(Link to thread in question, for those interested)
http://smalltalk.1294792.n4.nabble.com/Fwd-Issue-1129-in-pharo-UIManager-request-and-multilineRequest-do-not-distinguish-between-empty-and-l-td1301670.html
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

Stéphane Ducasse
We could rollback and introduce a new message and deprecates the other.
This is just that I do not have the energy for that.
Now this is also important that we do not get bound to existing API for the sake of them.
Stef


>>
>>> ToolBuilder is one of the projects I believe deserve to stay fork-agnostic.
>>>
>>> Exactly how we should go about coordinating so they stay in synch I'm interested in hearing :)
>>
>> That's not so difficult. Let's start by just merging the code bases, and see where this leads. I expect few, if any difficulties here. Let's add some test to document the changes (like the one Torsten was bitten by) and we should be pretty much covered.
>>
>> Further out, I don't expect us to stay closely in sync. The whole issue of upstream vs. downstream packages is an open one, so my opinion is that we should merge when it makes sense (i.e., new features being added) but otherwise let each project have its own choices.
>>
>>> With ToolBuilder, I also include the protocol of UIManagers.
>>> In that regard, one of the changes I think would be hard to get "Pharoers" to back down from, is the change of nil instead of '' return for request: dialog cancels.
>>
>> What can I say ... I actually said in that discussion that the right choice is to introduce a different protocol, i.e., request:onCancel: or something similar. Now we'll end up with a new protocol anyways - I don't expect Pharo to change (too much pride involved) and I don't expect Squeak to change (too much legacy code involved) so a new protocol for the people who care about compatibility going forward is really the only option (which can also be back-ported if necessary). The end result will be that we'll declare the return value of #request: to be "undefined" if the dialog is canceled and recommend using the new protocol.
>>
>> It's a great lesson about how not to break an existing protocol. If Pharo had introduced a new protocol we could have just implemented it in Squeak and be done. Instead, the end result will be that a new protocol is introduced anyway and that nobody will be able to reliably use the the old protocol. Consider it a lesson for the next time an issue like this comes up - if you're interested in compatibility breaking an existing protocol isn't the smart choice, in particular when it comes to cross-platform / cross-dialect protocols.
>>
>> Cheers,
>> - Andreas
> No arguments from me, I strongly defended the approach you suggested at the time.
> Sadly, (in my eyes) discussion just died, and everything got changed anyways.
>
> Cheers,
> Henry
>
> (Link to thread in question, for those interested)
> http://smalltalk.1294792.n4.nabble.com/Fwd-Issue-1129-in-pharo-UIManager-request-and-multilineRequest-do-not-distinguish-between-empty-and-l-td1301670.html
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

Stéphane Ducasse
In reply to this post by Andreas.Raab
Just a meta remark

> What can I say ... I actually said in that discussion that the right choice is to introduce a different protocol, i.e., request:onCancel: or something similar. Now we'll end up with a new protocol anyways - I don't expect Pharo to change (too much pride involved)

This is not a question of pride.
        do not imply that we do not have serious users that would like to avoid move :)
        do not imply that we do actions based on pride, this was not the case. Since the old
        protocol was wrong people preferred to see it fixed - at that time it was not clear that compatibility with squeak
        could make sense. The deprecation only works if you add a different name. And this was not what we wanted at that time.
        I contacted damien to see what he is thinking and if there is something we could do.
        Because we may introduce request:onCancel: and rewrite the old senders.


Stef
Reply | Threaded
Open this post in threaded view
|

squeaking along

Squeak List
In reply to this post by Andreas.Raab
very cool,

or, if "cool" is the "wrong" word, how about something like: "thank you"?

http://squeakingalong.wordpress.com/

thanx,

ken


     


Reply | Threaded
Open this post in threaded view
|

Re: squeaking along

Hannes Hirzel
On 4/30/10, Squeak List <[hidden email]> wrote:

> very cool,
>
> or, if "cool" is the "wrong" word, how about something like: "thank you"?
>
> http://squeakingalong.wordpress.com/
>
> thanx,
>
> ken
>

Yes, I'd like to join saying thank you to Andreas for taking the
energy for the two design criteria write-ups this week which elaborate
on and summarize the discussions we had

1) Annotations for Service Discovery
April 27, 2010 by andreasraab

There has been an interesting discussion going on in squeak-dev about
“annotations for service discovery”. Stated simply, the problem is how
a third party package can safely extend system-level services in the
face of rapid evolution of the underlying system. In Squeak, this
mostly affects the following three areas:

    * Preferences. Packages often want to show preferences in the
standard preferences tools.
    * File services. Packages that provide services to operate on
files, need to register these.
    * Menu items. Packages providing UI elements want to register
these with the proper menus.


2) Measuring Simplicity
April 30, 2010 by andreasraab

    * Conceptual Simplicity, measuring how many entities we need to
understand what the software does,
    * Interface Simplicity, measuring how many entities we need to
understand how to use the software, and
    * Implementation Simplicity, measuring how many entities we need
to understand how the software does it.


-- HJH

Reply | Threaded
Open this post in threaded view
|

Re: squeaking along

Chris Muller-3
Me too, the Annotations for Service Discovery was enlightening.  I
like it now.  Measuring Simplicity is something I have long cared
about; especially API simplicity.  I do hope "cool" will not subvert
simplicity at the UI level either, as we continue to refine Squeak's
UI..

On Fri, Apr 30, 2010 at 4:00 AM, Hannes Hirzel <[hidden email]> wrote:

> On 4/30/10, Squeak List <[hidden email]> wrote:
>> very cool,
>>
>> or, if "cool" is the "wrong" word, how about something like: "thank you"?
>>
>> http://squeakingalong.wordpress.com/
>>
>> thanx,
>>
>> ken
>>
>
> Yes, I'd like to join saying thank you to Andreas for taking the
> energy for the two design criteria write-ups this week which elaborate
> on and summarize the discussions we had
>
> 1) Annotations for Service Discovery
> April 27, 2010 by andreasraab
>
> There has been an interesting discussion going on in squeak-dev about
> “annotations for service discovery”. Stated simply, the problem is how
> a third party package can safely extend system-level services in the
> face of rapid evolution of the underlying system. In Squeak, this
> mostly affects the following three areas:
>
>    * Preferences. Packages often want to show preferences in the
> standard preferences tools.
>    * File services. Packages that provide services to operate on
> files, need to register these.
>    * Menu items. Packages providing UI elements want to register
> these with the proper menus.
>
>
> 2) Measuring Simplicity
> April 30, 2010 by andreasraab
>
>    * Conceptual Simplicity, measuring how many entities we need to
> understand what the software does,
>    * Interface Simplicity, measuring how many entities we need to
> understand how to use the software, and
>    * Implementation Simplicity, measuring how many entities we need
> to understand how the software does it.
>
>
> -- HJH
>
>