What to do with the PlusTools

hi all

I think that without an effort (we need help) we will have to remove  
the PlusTool (ie
the tools that are using the ToolBuilder framework and this would be  
a pity since this is the way to go
so that we can get Tweak or Morphic) since we have now a lot of  
duplicated code.

I'm looking for ideas:
        - removing the current tool set and losing some of the enh
        - removing the PlusTool with the risk that this effort is lost
        - keeping both is not a good idea.
Stef

> I'm looking for ideas:
>         - removing the current tool set and losing some of the enh

+1

I vote for this, we need to go forward. I don't see the future in morphic.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

> Lukas Renggli wrote:
> Sent: Friday, January 13, 2006 2:51 PM
>
> I don't see the future in morphic.
>

Could you explain this comment a bit more?  

Ron Teitelbaum

>         - removing the current tool set and losing some of the enh

Yup. Carrying two toolkits around is not wise, and I think that
PlusTools is the way to go.

We'll just have to carry forward some of the goodies from the old tools...

In an ideal world I'd suggest
making a list of the features in the current tools that are wanted
making a list ..... new tools.... blah-blah
making a list of new features wanted
making a list of dud 'features' to get rid of
move to PlusTools
implement whatever can be implemented from the above lists.

Probably the crucial question is whether the PlusTools stuff includes  
enough capabilities to keep people from revolting in the interim.

And of course finding someone with the time/commitment to do the work.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
State-of-the-art: What we could do with enough money.

> > I don't see the future in morphic.
>
> Could you explain this comment a bit more?

Morphic hasn't changed for years, except for bug-fixes, optimizations,
etc. For me it is a always a pain when I have to build something in
Morphic. I think Squeak needs to concentrate on something new like
Tweak, wxWidgets, ... And ToolBuilder is the bridge to this.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Il giorno ven, 13/01/2006 alle 20.36 +0100, stéphane ducasse ha scritto:
Another idea is dropping them for the moment, but immediately starting
planning and executing a gradual substitution of the Morphic tools with
the ToolBuilder equivalent. At the same time, don't accept any new tools
or new versions of existing tools unless they use ToolBuilder.

I'm not really fond of this idea, but it could work without losing the
enh which already are in the image.

        Giovanni

Of course, a big question is - how much are the plustools missing?

I really don't like the idea of removing them again - that will just
postpone the issue, because when 4.0 comes, no-one will have worked on
PlusTools (wanna bet?). So we need to force ourselves to work on it,
and the only way I can think of is by dropping the old stuff.

Step 1 would probably be making RB subclass of PlusTools...

On 14 janv. 06, at 12:23, Cees De Groot wrote:

> Of course, a big question is - how much are the plustools missing?
>
> I really don't like the idea of removing them again - that will just
> postpone the issue, because when 4.0 comes, no-one will have worked on
> PlusTools (wanna bet?). So we need to force ourselves to work on it,
> and the only way I can think of is by dropping the old stuff.

Hi cees

this is also my fear.

> Step 1 would probably be making RB subclass of PlusTools...

Yeap! Who is in charge of RB? marcus?

Stef

On 14.01.2006, at 13:42, stéphane ducasse wrote:

What does "make RB a subclass of PlusTools" mean exactly?
the browser part of the RB is a subclass of the systembrowser,
but that's very ugly anyway.

The idea of RB is to not have any browser, so I don't want to
put any effort into the browser part of RB *at all*.
(I am waiting for services...)

The other tools (SLint, dialogs...) yes... they should be converted  
to not
depend on morphic. But I don't think that I can make that my personal  
priority.

     marcus

On 1/14/06, Marcus Denker <[hidden email]> wrote:
> The idea of RB is to not have any browser, so I don't want to
> put any effort into the browser part of RB *at all*.
> (I am waiting for services...)
>
Well, we can wait for services, or we can just make sure that RB works
in the PlusTools environment...

Maybe I'll take a look at it this week, shouldn't be too hard. And
maybe I'll manage to make it work without subclassing :)

I'm starting now to look at the services because indeed if we could  
get rid of the UI of RB
this is where all the story starts to pay.

Stef

On 14 janv. 06, at 14:49, Cees De Groot wrote:

> I'm looking for ideas:
>         - removing the current tool set and losing some of the enh

+1

I vote for this, we need to go forward. It would also help the cleaning and
evolution of Morphic!

Juan
----- Original Message -----
From: "stéphane ducasse" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Friday, January 13, 2006 4:36 PM
Subject: What to do with the PlusTools

Hi -

Unless you find someone to maintain it, remove the package. I have never
intended that proof-of-concept to go into the image. That I now find
bugs assigned to me for a package that for all intents and purposes of
Squeak-dev I do not and have no intention to maintain, goes too far.

Either throw it out or find someone who takes of it.

Regards,
   - Andreas

stéphane ducasse wrote:

On 1/15/06, Andreas Raab <[hidden email]> wrote:
> That I now find
> bugs assigned to me for a package that for all intents and purposes of
> Squeak-dev I do not and have no intention to maintain, goes too far.
>
Err... insofar you are referencing bugs that I "assigned" to you, IIRC
these couple of instances were all paired with questions about your
intentions, hardly with an assignment to fix them...

Anyway, a Tools team is in order, and I'd rather would have them go
with PlusTools than with the current toolset as a starting point.

Brian Brown leads a ToolBuilder team, which hasn't been very active -
maybe it is an idea to rename it and change the focus?

Cees De Groot wrote:
> On 1/15/06, Andreas Raab <[hidden email]> wrote:
>
>>That I now find
>>bugs assigned to me for a package that for all intents and purposes of
>>Squeak-dev I do not and have no intention to maintain, goes too far.
>
> Err... insofar you are referencing bugs that I "assigned" to you, IIRC
> these couple of instances were all paired with questions about your
> intentions, hardly with an assignment to fix them...

I'm not sure what you're talking about. I am referring to

http://bugs.impara.de/view.php?id=2486
http://bugs.impara.de/view.php?id=2493
http://bugs.impara.de/view.php?id=2494

which were all assigned to me (I've reassigned them since). And I think
I've made my intentions clear in this post:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-November/096901.html

> Anyway, a Tools team is in order, and I'd rather would have them go
> with PlusTools than with the current toolset as a starting point.

If you wish to do that, I can't stop you. Just be aware that I have no
plans and intentions to join that team. And please, stop assigning these
bugs to me.

> Brian Brown leads a ToolBuilder team, which hasn't been very active -
> maybe it is an idea to rename it and change the focus?

Bad idea. ToolBuilder is a framework, the tools are an application. You
don't reassign framework people to any specific application (not as long
as you want the framework be usable outside of that application).

Regards,
   - Andreas

On 1/16/06, Andreas Raab <[hidden email]> wrote:
> > Brian Brown leads a ToolBuilder team, which hasn't been very active -
> > maybe it is an idea to rename it and change the focus?
>
> Bad idea. ToolBuilder is a framework, the tools are an application. You
> don't reassign framework people to any specific application (not as long
> as you want the framework be usable outside of that application).
>
I don't agree here - ToolBuilder is a framework for the tools, which
is not 'an application'. A Tools team would need to maintain the
browsers, debugger, workspace, ... - which in my eyes are a series of
applications, and modulo a couple of tools that are 'external' (MC,
MCC come to mind), it's the vast majority of the code base that uses
and probably will use the framework.

Ok, care is in order, because I know exactly what you mean here, seen
it too often :-). But I wouldn't reject the idea out of hand. Anyway,
I think it's ultimately for Brian and the team to decide, I was just
suggesting it.