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
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
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 < hernan.morales@gmail.com> wrote:
Hi Stef,
2015-07-07 16:15 GMT-03:00 stepharo <stepharo@free.fr>:
Hi Pavel
Rubric will replace the PluggableTextMorph and friends. So it is at the same level.
This will impact Spec?
Hernán
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 <stepharo@free.fr <mailto:stepharo@free.fr>>:
Hi Pavel
Rubric will replace the PluggableTextMorph and friends. So it is at the same level.
This will impact Spec?
Hernán
participants (4)
-
Hernán Morales Durand -
Pavel Krivanek -
Peter Uhnák -
stepharo