Rubic is getting more and more lowlevel

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

Rubic is getting more and more lowlevel

Pavel Krivanek-3
Hi,

it is understandable that Rubic is used in our most basic tools but because it is an semi-external project with a configuration, it makes some dependency problems in Pharo. It is not possilbe to use Nautilus without it and newly the Workspace (from Tool-Workspace) is not possilbe to load properly.
Currently we have no configuratons for all tools that are using Rubic and these tools are nested deeply in the system so we cannot have right loading order of Pharo packages.
Please, do not add new dependencies from Pharo monolit to external packages.

Cheers,
-- Pavel
Reply | Threaded
Open this post in threaded view
|

Re: Rubic is getting more and more lowlevel

stepharo
Hi Pavel

Rubric will replace the PluggableTextMorph and friends. So it is at the
same level.
Rubric is not an external package. It is the replacement for
     TextEditor
     SmalltalkTextEditor
     PluggableTextMorph (and subclasses).
     => we should not use these classes and we will deprecated them.

We also want to remove NewList. I need some help from exteban to see how
we can express the API in
FTList.
    FTList should replace Pluggable***List*. So we should make sure that
they are not used anymore too.

It is important because we want to be able to
     improve the system
     while preparing the move to Bloc/Brick.

What should be done it to define ConfigurationOf for a lot more.
We are working with guille and christophe (check the dependency browser)
because we start to use it a lot.

Stef

Le 7/7/15 17:15, Pavel Krivanek a écrit :

> Hi,
>
> it is understandable that Rubic is used in our most basic tools but
> because it is an semi-external project with a configuration, it makes
> some dependency problems in Pharo. It is not possilbe to use Nautilus
> without it and newly the Workspace (from Tool-Workspace) is not
> possilbe to load properly.
> Currently we have no configuratons for all tools that are using Rubic
> and these tools are nested deeply in the system so we cannot have
> right loading order of Pharo packages.
> Please, do not add new dependencies from Pharo monolit to external
> packages.
>
> Cheers,
> -- Pavel


Reply | Threaded
Open this post in threaded view
|

Re: Rubic is getting more and more lowlevel

hernanmd
Hi Stef,

2015-07-07 16:15 GMT-03:00 stepharo <[hidden email]>:
Hi Pavel

Rubric will replace the PluggableTextMorph and friends. So it is at the same level.

This will impact Spec?

Hernán

Reply | Threaded
Open this post in threaded view
|

Re: Rubic is getting more and more lowlevel

Peter Uhnak
Spec has in theory independent API, so someone will have to write a new adapter for Rubric.
On the other hand TextModel is internally relying on Morphic change mechanisms too much (it's indirect, but still) ... so it could help streamline the code more.

Peter

On Thu, Jul 9, 2015 at 9:02 AM, Hernán Morales Durand <[hidden email]> wrote:
Hi Stef,

2015-07-07 16:15 GMT-03:00 stepharo <[hidden email]>:
Hi Pavel

Rubric will replace the PluggableTextMorph and friends. So it is at the same level.

This will impact Spec?

Hernán


Reply | Threaded
Open this post in threaded view
|

Re: Rubic is getting more and more lowlevel

stepharo
In reply to this post by hernanmd
We will replace the PluggableTexMorph uses by Spec
Normally this should be transparent to the user.

PluggableTextMorph should get out.

Stef

Le 9/7/15 09:02, Hernán Morales Durand a écrit :
Hi Stef,

2015-07-07 16:15 GMT-03:00 stepharo <[hidden email]>:
Hi Pavel

Rubric will replace the PluggableTextMorph and friends. So it is at the same level.

This will impact Spec?

Hernán