Fwd: Working with Pharo 1.4/2.0 …

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

Fwd: Working with Pharo 1.4/2.0 …

Sean P. DeNigris
Administrator
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.
Cheers,
Sean
cbc
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Working with Pharo 1.4/2.0 …

cbc
On Thu, Sep 6, 2012 at 8:30 AM, Sean P. DeNigris <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Working with Pharo 1.4/2.0 …

Sean P. DeNigris
Administrator
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
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Working with Pharo 1.4/2.0 …

Esteban A. Maringolo
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


Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Working with Pharo 1.4/2.0 …

feldti
In reply to this post by Sean P. DeNigris
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

marten.vcf (226 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Working with Pharo 1.4/2.0 …

feldti
In reply to this post by Sean P. DeNigris
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
>>


marten.vcf (226 bytes) Download Attachment