Hi, with GT Inspector/Spotter we now have more moldable tools and Pharo becomes again a more flexible Tool and IDE. The settings framework also allows to use the settings browser for own purposes and in own applications - which is nice. One can even have a custom world menu in Pharo for the own app (see [1]) Reminds me on Eclipse (RCP, ...) where one can extend the IDE at specific extension points to provide own custom tools and even build applications that are not IDE's. What about a moldable browser? For instance it would be nice if I could extend the browser with own panes as replacement for the regular code pane. So for instance a method that returns an XML string could be shown as a clickable tree instead of the code pane, ... foo <xml> ^'<someXML></someXML> With a flexible code editor like Rubric/TxText and Petit infrastructure or other one could even provide moldable code panes with syntax highlighting for different languages (PHP, CSS, HTML, ... Even the browser panes (packages, classes, ...) could be moldable - you display in a tree an object with relations to other objects - when you click on them more customizable details (depending on the displayed object) open up in new panes. The more (moldable) infrastructure Pharo provides the more cases one will find where it can be applied. So the question is how modable is Pharo already (beside the mentioned cases) and how moldable will Pharo be in the future? What is the next planned step in this area (if any)? Thx T. [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/032670.h...
Indeed! Hey! The Glamorous team! This is a call :-) Alexandre
On Jul 8, 2015, at 1:28 PM, Torsten Bergmann <astares@gmx.de> wrote:
Hi,
with GT Inspector/Spotter we now have more moldable tools and Pharo becomes again a more flexible Tool and IDE. The settings framework also allows to use the settings browser for own purposes and in own applications - which is nice. One can even have a custom world menu in Pharo for the own app (see [1])
Reminds me on Eclipse (RCP, ...) where one can extend the IDE at specific extension points to provide own custom tools and even build applications that are not IDE's.
What about a moldable browser? For instance it would be nice if I could extend the browser with own panes as replacement for the regular code pane.
So for instance a method that returns an XML string could be shown as a clickable tree instead of the code pane, ...
foo <xml> ^'<someXML></someXML>
With a flexible code editor like Rubric/TxText and Petit infrastructure or other one could even provide moldable code panes with syntax highlighting for different languages (PHP, CSS, HTML, ...
Even the browser panes (packages, classes, ...) could be moldable - you display in a tree an object with relations to other objects - when you click on them more customizable details (depending on the displayed object) open up in new panes.
The more (moldable) infrastructure Pharo provides the more cases one will find where it can be applied.
So the question is how modable is Pharo already (beside the mentioned cases) and how moldable will Pharo be in the future? What is the next planned step in this area (if any)?
Thx T.
[1] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/032670.h...
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi, Moldability is the very center part of the philosophy behind GT and Pharo. We want the whole environment to become moldable. Essentially, we bring dynamism into the IDE (the language has long been dynamic, but the tools were much less so). Indeed, right now you see it materialized by default in the inspector and spotter. In the Moose image, the debugger also supports the same concept. Next, it will be materialized in the playground. And yes, the code browser will also be affected, but probably at the end. We specifically did not start with the code browser exactly because by not doing that we forced ourselves to reinvent the IDE from the basics. We started with the inspector because Pharo is object-oriented not class-oriented :). We are currently working on the Playground because this is where objects start. I think we are on a good path to reinvent that little interface as well. We will likely have news on that soon. Cheers, Doru
did you check the nautilus plugin? Because you cannot compose everything but you can add plugin and I clean them today. Stef Le 8/7/15 13:28, Torsten Bergmann a écrit :
Hi,
with GT Inspector/Spotter we now have more moldable tools and Pharo becomes again a more flexible Tool and IDE. The settings framework also allows to use the settings browser for own purposes and in own applications - which is nice. One can even have a custom world menu in Pharo for the own app (see [1])
Reminds me on Eclipse (RCP, ...) where one can extend the IDE at specific extension points to provide own custom tools and even build applications that are not IDE's.
What about a moldable browser? For instance it would be nice if I could extend the browser with own panes as replacement for the regular code pane.
So for instance a method that returns an XML string could be shown as a clickable tree instead of the code pane, ...
foo <xml> ^'<someXML></someXML>
With a flexible code editor like Rubric/TxText and Petit infrastructure or other one could even provide moldable code panes with syntax highlighting for different languages (PHP, CSS, HTML, ...
Even the browser panes (packages, classes, ...) could be moldable - you display in a tree an object with relations to other objects - when you click on them more customizable details (depending on the displayed object) open up in new panes.
The more (moldable) infrastructure Pharo provides the more cases one will find where it can be applied.
So the question is how modable is Pharo already (beside the mentioned cases) and how moldable will Pharo be in the future? What is the next planned step in this area (if any)?
Thx T.
[1] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/032670.h...
Nautilus plugins are good for adding new stuff at very restricted places... but if you want to change parts you are out of luck. So if I want to for example play around with the comment area, I am forced to change hardcoded code in AbstractNautilusUI (namely AbstractNautilusUI>>buildCommentPane) â So there's definitely room for making parts of Nautilus more loosely coupled and interchangeable. Peter On Wed, Jul 8, 2015 at 11:16 PM, stepharo <stepharo@free.fr> wrote:
did you check the nautilus plugin? Because you cannot compose everything but you can add plugin and I clean them today. Stef
Le 8/7/15 13:28, Torsten Bergmann a écrit :
Hi,
with GT Inspector/Spotter we now have more moldable tools and Pharo becomes again a more flexible Tool and IDE. The settings framework also allows to use the settings browser for own purposes and in own applications - which is nice. One can even have a custom world menu in Pharo for the own app (see [1])
Reminds me on Eclipse (RCP, ...) where one can extend the IDE at specific extension points to provide own custom tools and even build applications that are not IDE's.
What about a moldable browser? For instance it would be nice if I could extend the browser with own panes as replacement for the regular code pane.
So for instance a method that returns an XML string could be shown as a clickable tree instead of the code pane, ...
foo <xml> ^'<someXML></someXML>
With a flexible code editor like Rubric/TxText and Petit infrastructure or other one could even provide moldable code panes with syntax highlighting for different languages (PHP, CSS, HTML, ...
Even the browser panes (packages, classes, ...) could be moldable - you display in a tree an object with relations to other objects - when you click on them more customizable details (depending on the displayed object) open up in new panes.
The more (moldable) infrastructure Pharo provides the more cases one will find where it can be applied.
So the question is how modable is Pharo already (beside the mentioned cases) and how moldable will Pharo be in the future? What is the next planned step in this area (if any)?
Thx T.
[1] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/032670.h...
participants (5)
-
Alexandre Bergel -
Peter Uhnák -
stepharo -
Torsten Bergmann -
Tudor Girba