Hi, Thanks for the reply. My reply is inlined below. It might appear that we are contradicting each other, but I am actually sure we are not :).
On Nov 4, 2015, at 11:54 PM, Torsten Bergmann <astares@gmx.de> wrote:
Hi Doru,
yes - but the concept of moldable tools is nothing new for Smalltalk - it's a long tradition. Even in Java world we have them (NetBeans and Eclipse can be adopted to own needs as well). The GT inspector with the tabs is similar to the known concept of custom inspectors in Smalltalk and custom views in Eclipse.
Almost, but not really :). Moldability means to have the tools and the mechanisms behind be extensible with little cost and ideally during usage. The tiny difference lies in the cost. Indeed, inspectors have been extensible in Smalltalk systems for a long time. But, if this would be enough why were there so few extensions before and why are there so many now?
The #act: methods who provide the buttons usually care on the current GT presentation. In Eclipse one has explicit extension points so I can even add a button on another tab view easily.
Dont know how this can currently be done in GT tools as usually now a single extension method represents the whole composite with the menues, context menues, â¦
In the current design, the actions of a presentation are defined within that presentation. If the presentation thinks it wants to be extensible, which is not the case for most presentations, it is the responsibility of that presentation to provide the extension points. As I said, it is so cheap now to create a new presentation that it is perhaps less worthwhile to introduce many way of extending to the detriment of understanding (people that have tried to debug Eclipse RCP projects might attest to the less than comfortable experience :)) However, the object actions can be customized by each class using the <gtInspectorAction> pragma. A concept that we have in Moose is that of a menu attached to each object. This is something that we would like to add to GT as well.
Also there are more concepts abstracted away in Eclipse (workbench, perspectives, actions, ...) that allow one to customize the whole IDE for a rich client platform.
Eclipse perspectives correspond to browsers in Pharo.
For sure it is easier to lively inspect/provide code in Pharo with less LOC than in Java. And yes I know that in Eclipse there is a gap because extensions require a bad mix of XML and code in the plugins and all that is based on a language with dead code in text files ;)
This matters. In Pharo we have the opportunity to push the envelope significantly further than any other environment. And we have just started. I would like to see more innovation in this field.
Small issues I've found: - the tabs constantly display a "a MyClass" followed by the #gtDisplayString in parantheses - havent found where to adopt this - I was not able to find out quickly how to avoid the "Browse" button at the top
These ones are not being customizable because that need did not exist until now. Regarding the label: this one is decided by the object. In your case, you would like to specialize them depending on the inspector. Regarding object actions: you can find the list of current actions in: Object>>gtInspectorActions Both of these are being directly called from: GTInspector>>composite In both of these cases, we could imagine a double dispatch based on the inspector, or at least an extra hook that can be customized by Inspector subclasses. However, I would rather take a different route. The original idea was that if you need a browser that wants to do other things than what the inspector does, you simply create one using a Glamour Finder. That is why we wanted to keep the inspector code as small as possible. In the meantime that code of the GTInspector class reached 252 lines of code, which starts to be too much, and we should consider adding hooks to it, or to slim it down.
There is a much better approach/alternative to the way we do it now with less coding ... but I can not talk about that further. Not yet ;)
Ok :) Doru
Bye T.
Gesendet: Mittwoch, 04. November 2015 um 23:09 Uhr Von: "Tudor Girba" <tudor@tudorgirba.com> An: "Any question about pharo is welcome" <pharo-users@lists.pharo.org> Cc: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] [Pharo-users] [ANN] QuickAccess for Pharo 5
Hi,
Nice work!
I love the details you went through to implement this, especially given that the UI is just a custom inspector. Itâs naked objects on steroids :).
I think this is a beautiful use case for moldable tools. It shows that once the cost of tools drops, unforeseen solutions will emerge. We need to focus on more support to make more things like this possible.
Cheers, Doru
On Nov 4, 2015, at 10:35 PM, Torsten Bergmann <astares@gmx.de> wrote:
Hi,
I quickly wrote yet another small tool to work faster with Pharo. I call it "QuickAccess" - it's some kind of "ScriptManager 2.0" allowing you to quickly access actions (defined as code scripts) via Spotter, Menu, Button, etc.
You can load it from Spotter/Catalog in Pharo 5.0 beta.
The following video demonstrates how to use it:
The defined structure including the scripts can be exported to a file and send around. So far it is "complete" for my own requirements - if you feel something is missing you can contribute and help moving it forward.
The repo is at http://www.smalltalkhub.com/#!/~TorstenBergmann/QuickAccess Contact me with your STHub account if you need access.
The tool has some similarities with Playground/script cache, but GT tools lack the category structuring for scripts that you find in QuickAccess. It might be an inspiration for a future unified script management solution in Playground.
Have fun!
Bye T.
-- www.tudorgirba.com
"Obvious things are difficult to teach."
-- www.tudorgirba.com "Presenting is storytelling."