[Pharo-project] Fwd: Working with Pharo 1.4/2.0 â¦
Below is a blog post and my reply... If anyone has anything to add, here's the link... https://schrievkrom.wordpress.com/2012/09/06/working-with-pharo-1-42-0/
As I mentioned in my previous posting I at last have found now some time to do actually some âseriousâ work with Pharo.
Here are some thoughts â just to write down my first impressions:
Pharo 1.4
I do most of the stuff with Pharo 1.4 for now and here some points in the developer GUI:
* multiple selection in the browser does not work â this was pretty boring
* creating accessor methods for instance attributes is not speedy and takes too much clicks
* then I looked for a setting framework and I was really surprised to see, how difficult it was â or at least the documentation I read about it. After working with the setting framework of VASmalltalk I would prefer the simple approach than a perhaps even more powerful approach.
Pharo 2.0 and Nautilus
I also had a look at Pharo 2.0 â and I have MANY,MANY problems with its new browser: âNautilusâ. The reason for my problems is the way they create the GUI: the buttons do not show the actual state of the GUI, but they show what will happen, when the button is pressed !!!
This is a radical approach changing the whole GUI and make it very difficult to understand. Perhaps this is due to the fact, that they have no suitable GUI elements (like two state buttons) for supporting this GUI interaction.
The visual appearance is in my view always in a conflict state.
Then I look at buttons here in my home and most of these buttons are on/off buttons. The possible values of these buttons are know prior to the user â this is different to the buttons of Nautilus, where you perhaps do not know the other state ( Groups Packages ).
The on/off switch of my computer is a reverse-state button, but there is a LED light, showing the actual state of the computer and the user know how to use the button.
The on/off switch of my power-subsystem in my computer has also a two state button â but it shows the actual state (1 for on, 0 for off).
Thanks for the great feedback! This is gold for the Pharo dev community. I encourage you to bring this feedback to the dev list, or â even better â create issues, or (best option) take on a few so we can integrate them!! A few comments/questions: * multiple selection in 1.4 â consider the browser in 1.4 to be legacy. Nautilus will be the future browser in Pharo, and it will have multiple selection * accessor creation â will you describe what steps you took (e.g. manual creation, context menu (there are two possiblities here), etc)? If you illustrate your ideal behavior, I will create an issue and push to include it in Nautilus⦠* Settings â I find this one *really* interesting. Will you highlight the key differences to VA? Maybe we can improve the framework in Pharo, or at minimum create a UI that makes things simpler and more straightforward for you Re Nautilus: it is not production-ready, which is why it was not included in Pharo 1.4, but it is under heavy development by a great developer, Benjamin VanRyseghem. He is very open to this type of feedback. Specifically, I couldnât agree more about the buttons!!! After months of using Nautilus, I /still/ have no idea whether Iâm on the class or instance side. -- View this message in context: http://forum.world.st/Fwd-Working-with-Pharo-1-4-2-0-tp4646428.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Thu, Sep 6, 2012 at 8:30 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Below is a blog post and my reply... If anyone has anything to add, here's the link... https://schrievkrom.wordpress.com/2012/09/06/working-with-pharo-1-42-0/ ...
* creating accessor methods for instance attributes is not speedy and takes too much clicks
* then I looked for a setting framework and I was really surprised to see, how difficult it was â or at least the documentation I read about it. After working with the setting framework of VASmalltalk I would prefer the simple approach than a perhaps even more powerful approach.
... * accessor creation â will you describe what steps you took (e.g. manual creation, context menu (there are two possiblities here), etc)? If you illustrate your ideal behavior, I will create an issue and push to include it in Nautilusâ¦
I haven't worked with the framework in VA, and personally, don't like frameworks to create accessor methods. However, just yesterday, I really wished that the debugger had a button when enountering an unknown method called 'create accessor' or something similar - if the method looks like an accessor method for a variable that doesn't have one, offer up the option of letting the runner (coder) just create the simplest flavor right there in the debugger. It would show up right next to the Create button at the same time. My favorite method of coding, in any case... -Chris
Chris Cunningham wrote
I really wished that the debugger had a button when enountering an unknown method called 'create accessor' or something similar
Well, we're almost there... if you send a unary or binary message with the same name as an inst var, and click "create " from the debugger, you get an accessor template... The only problem is that is has "self shouldBeImplemented." added to it, which is not even highlighted for deletion. I've wondered for a while what the purpose of this is... Unless someone speaks up convincingly for its usefulness, I say we remove it and start with a complete and valid accessor as the template... Cheers, Sean -- View this message in context: http://forum.world.st/Fwd-Working-with-Pharo-1-4-2-0-tp4646428p4646445.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
If you want those kind of niceties in the debugger/browser look at how Dolphin Smalltalk does it. On MNU's you can implement methods in the class of any of the parents of the receiver object. Or even implement it while in the method browser. The development experience is so streamlined that it flows naturally. Regards, -- Esteban -- View this message in context: http://forum.world.st/Fwd-Working-with-Pharo-1-4-2-0-tp4646428p4646450.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Just some additional remarks about the setting framework and how VA has it since its latest release. Due to its source code management (ENVY) each application has its own configuration section in a simple ascii based *.ini file. Therefore each application has a text section like [name of application] key = value ... The developer just write 3 methods on the class side of its application class, which more or less do something: one method defines all possible entries expected in the text files and what type it has one method defines current AND default values for each setting one method defines how to transfer the values to your application. That's pretty simple - but also limited - and you copy the implementation of these three methods from another application, change them according to your needs and that's it. The documentation describing the Pharo settings framework is 20 pages long and offers many more features - I actually do not need. And I do not need a GUI to edit my setting values - but for others this might be useful. The documentation is not straight forward - three or four pages with introductions. And even now I do not know how the settings are stored outside the system. But as I said before - I have not done much work with Squeak/Pharo yet - and this only reflects my early impressions when working with this system. And I even do not know, if Settings is part of Pharo 1.4 or Pharo 2.0. Just to give you an overview of my ideas here. and another point I want to say about using the system: Working with VASmalltalk/ENVY the methods called after starting, resuming, loading, unloading (and various other events) to each class/application are well documented. I do not find documents/informations about this in Pharo/Squeak and this is a very important information when initializing an application. Marten Feldtmann Am 06.09.2012 17:30, schrieb Sean P. DeNigris:
* Settings â I find this one *really* interesting. Will you highlight the key differences to VA? Maybe we can improve the framework in Pharo, or at minimum create a UI that makes things simpler and more straightforward for you
Another hint here: I like the refactoring browser's way: multi-select items in the list of attributes and default accessors are created - no need to edit the code here. I am in the browser, already looking at this class - and then I change the code in the browser. Marten Am 06.09.2012 17:30, schrieb Sean P. DeNigris:
* creating accessor methods for instance attributes is not speedy and takes too much clicks
participants (4)
-
Chris Cunningham -
Esteban A. Maringolo -
Marten Feldtmann -
Sean P. DeNigris