Toolset vs UIManager

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

Toolset vs UIManager

Stéphane Ducasse
I was reading the change of benjmain to deprecate notifyWithLabel: aString  from Object.
Yes!

Now he was putting it on ToolSet and I thought that I would have put it on UIManager.
Now the relationship and responsibility of this two classes are not clear to me.
Does anybody a clear thought on that?

Stef
Reply | Threaded
Open this post in threaded view
|

Re: Toolset vs UIManager

Igor Stasenko
On 3 December 2010 21:47, Stéphane Ducasse <[hidden email]> wrote:
> I was reading the change of benjmain to deprecate notifyWithLabel: aString  from Object.
> Yes!
>
> Now he was putting it on ToolSet and I thought that I would have put it on UIManager.
> Now the relationship and responsibility of this two classes are not clear to me.
> Does anybody a clear thought on that?
>

they are related but still a bit different.
a toolset provides an access to standard system tools like browser,
inspector debugger etc.
while UI manager provides an access to things like inform:, progress bars etc

My proposal remains same as before. i proposed to unify this API and
use idioms like:

Smalltalk tools browser openOn: aClass

as well as

Smalltalk ui inform: 'you banned'

so, then we don't need to have a distinct classes, but instead a
roles, like 'tools' , 'ui', 'browser' which
should support corresponding protocol.

> Stef
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Toolset vs UIManager

EstebanLM
+1

El 03/12/2010, a las 6:25p.m., Igor Stasenko escribió:

> On 3 December 2010 21:47, Stéphane Ducasse <[hidden email]> wrote:
>> I was reading the change of benjmain to deprecate notifyWithLabel: aString  from Object.
>> Yes!
>>
>> Now he was putting it on ToolSet and I thought that I would have put it on UIManager.
>> Now the relationship and responsibility of this two classes are not clear to me.
>> Does anybody a clear thought on that?
>>
>
> they are related but still a bit different.
> a toolset provides an access to standard system tools like browser,
> inspector debugger etc.
> while UI manager provides an access to things like inform:, progress bars etc
>
> My proposal remains same as before. i proposed to unify this API and
> use idioms like:
>
> Smalltalk tools browser openOn: aClass
>
> as well as
>
> Smalltalk ui inform: 'you banned'
>
> so, then we don't need to have a distinct classes, but instead a
> roles, like 'tools' , 'ui', 'browser' which
> should support corresponding protocol.
>
>> Stef
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>


Reply | Threaded
Open this post in threaded view
|

Re: Toolset vs UIManager

Miguel Cobá
+1

This also will permit to redirect all the messages like inform and
progress bars to log files, instead than  ui windows. This would be
analog to the work Dale did for the Metacello "silent" way of
installing.

Cheers

El vie, 03-12-2010 a las 18:41 -0300, Esteban Lorenzano escribió:

> +1
>
> El 03/12/2010, a las 6:25p.m., Igor Stasenko escribió:
>
> > On 3 December 2010 21:47, Stéphane Ducasse <[hidden email]> wrote:
> >> I was reading the change of benjmain to deprecate notifyWithLabel: aString  from Object.
> >> Yes!
> >>
> >> Now he was putting it on ToolSet and I thought that I would have put it on UIManager.
> >> Now the relationship and responsibility of this two classes are not clear to me.
> >> Does anybody a clear thought on that?
> >>
> >
> > they are related but still a bit different.
> > a toolset provides an access to standard system tools like browser,
> > inspector debugger etc.
> > while UI manager provides an access to things like inform:, progress bars etc
> >
> > My proposal remains same as before. i proposed to unify this API and
> > use idioms like:
> >
> > Smalltalk tools browser openOn: aClass
> >
> > as well as
> >
> > Smalltalk ui inform: 'you banned'
> >
> > so, then we don't need to have a distinct classes, but instead a
> > roles, like 'tools' , 'ui', 'browser' which
> > should support corresponding protocol.
> >
> >> Stef
> >>
> >
> >
> >
> > --
> > Best regards,
> > Igor Stasenko AKA sig.
> >
>
>

--
Miguel Cobá
http://twitter.com/MiguelCobaMtz
http://miguel.leugim.com.mx




Reply | Threaded
Open this post in threaded view
|

Re: Toolset vs UIManager

Francisco Ortiz Peñaloza
In reply to this post by EstebanLM
+2 :)

On Fri, Dec 3, 2010 at 6:41 PM, Esteban Lorenzano <[hidden email]> wrote:
+1

El 03/12/2010, a las 6:25p.m., Igor Stasenko escribió:

> On 3 December 2010 21:47, Stéphane Ducasse <[hidden email]> wrote:
>> I was reading the change of benjmain to deprecate notifyWithLabel: aString  from Object.
>> Yes!
>>
>> Now he was putting it on ToolSet and I thought that I would have put it on UIManager.
>> Now the relationship and responsibility of this two classes are not clear to me.
>> Does anybody a clear thought on that?
>>
>
> they are related but still a bit different.
> a toolset provides an access to standard system tools like browser,
> inspector debugger etc.
> while UI manager provides an access to things like inform:, progress bars etc
>
> My proposal remains same as before. i proposed to unify this API and
> use idioms like:
>
> Smalltalk tools browser openOn: aClass
>
> as well as
>
> Smalltalk ui inform: 'you banned'
>
> so, then we don't need to have a distinct classes, but instead a
> roles, like 'tools' , 'ui', 'browser' which
> should support corresponding protocol.
>
>> Stef
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



Reply | Threaded
Open this post in threaded view
|

Re: Toolset vs UIManager

Benjamin Van Ryseghem (Pharo)
+150 !!

UIManager is the Utilities of Morphic ^^

I sent an email about restructured it but I haven't got any answer.
I think that UIManager was a good idea at the beginning. It's a bag of UI which can be used by every classes to avoid duplications. The maor problem with that is that the implementations of methods are done with too hight tool, and then there is tons of bad dependencies. Jannik and I was discussing about create multiple polymorphic UIManager classes implementd with different level of morphic tools. This way, yo can plug and unplug PolyMorph or things like that.

ToolSet is pretty much the same about Tools but with the specificity to inherits from AppRegistry which allow you to switch between classes providing tools. But it's not used.


Ben 

On Dec 3, 2010, at 10:52 PM, Francisco Ortiz Peñaloza wrote:

+2 :)

On Fri, Dec 3, 2010 at 6:41 PM, Esteban Lorenzano <[hidden email]> wrote:
+1

El 03/12/2010, a las 6:25p.m., Igor Stasenko escribió:

> On 3 December 2010 21:47, Stéphane Ducasse <[hidden email]> wrote:
>> I was reading the change of benjmain to deprecate notifyWithLabel: aString  from Object.
>> Yes!
>>
>> Now he was putting it on ToolSet and I thought that I would have put it on UIManager.
>> Now the relationship and responsibility of this two classes are not clear to me.
>> Does anybody a clear thought on that?
>>
>
> they are related but still a bit different.
> a toolset provides an access to standard system tools like browser,
> inspector debugger etc.
> while UI manager provides an access to things like inform:, progress bars etc
>
> My proposal remains same as before. i proposed to unify this API and
> use idioms like:
>
> Smalltalk tools browser openOn: aClass
>
> as well as
>
> Smalltalk ui inform: 'you banned'
>
> so, then we don't need to have a distinct classes, but instead a
> roles, like 'tools' , 'ui', 'browser' which
> should support corresponding protocol.
>
>> Stef
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>




Reply | Threaded
Open this post in threaded view
|

Re: Toolset vs UIManager

Stéphane Ducasse
In reply to this post by Igor Stasenko
Ok this sounds like a good idea.

So we should do that.
Now I would like to have a clear comment in both classes and avoid duplicated code or functionality.

Stef

> they are related but still a bit different.
> a toolset provides an access to standard system tools like browser,
> inspector debugger etc.
> while UI manager provides an access to things like inform:, progress bars etc
>
> My proposal remains same as before. i proposed to unify this API and
> use idioms like:
>
> Smalltalk tools browser openOn: aClass
>
> as well as
>
> Smalltalk ui inform: 'you banned'
>
> so, then we don't need to have a distinct classes, but instead a
> roles, like 'tools' , 'ui', 'browser' which
> should support corresponding protocol.
>
>> Stef
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>