Seems we wrote at the same time...
Well, Steph here is what I do.
- I attend, organize Smalltalk meet ups.
- I contribute to the open source community of Gemstone, Amber and VAST
- I attend conferences like ESUG and STIC and burn funds to make the
community look bigger
- I host Smalltalk Inspect
- I organized the VanIsle CampSmalltalk last October
- I provide feedback and write open source boards
- I started a Software Group here in town that meets weekly and
Smalltalk is always part of it. We didn't promote it yet, but are about to.
For all these actions I need to prepare for questions that I might
encounter like:
- "Where do I get started?"
- "Is there an example for...."
- "Which Smalltalk distribution shall I start with?"
- "Why does the Pharo 3.0 distribution not work with Moose 3.0 even
though it is advertised?"
- "How can I add more flavour to an application, which framework shall I
use?"
So what does Pharo community currently do for me?
I report bugs and ask for help and fixes, introductions, examples.
The answers I get is "load the most current 4.0 development. There it
should work", "I don't know that doesn't work for me either..."
Am I supposed to advertise Pharo the same way? To a beginner?
I find it very strange that after 30 years one can not easily implement
a modern looking GUI without too much hassle.
Even the tool support for Pharo is inconsitant and unstable. I reported
that several times.
Unit tests are great, but UI tests are needed too.
I can only tell you that a beginner in Smalltalk is not conditioned like
us and he suffers much more problems as we do and even think of.
e.g. it is difficult enough for them to understand what tools are
available and how to navigate the code. But searching for a simple menu
like "browse implementors" can even be challenging.
I know 3 different implementations/spots in one release...
There are so many developers out there that already heard of Smalltalk
and would love to try it out.
The only problem is.... there is no real support for them.
Once you outgrow the Pharo tutorial it is extreemly difficult to go on
with more serious stuff.
Why do stable Configuration oftern not work and dev has to be loaded?
That does not make sense in a One-Click-Image...
I tried the experiement and started an application from scratch and it
is really not easy to get started. First question was "Which UI
framework do I actually have to use? There are "MANY" out there"
But I have to tell all contributers here in the forum. The support and
will to help is great! I realized that past months some of the questions
I had had already been answered several times.
I still got helpful answeres again and was able to go on.
There should be a collection of useful tutorials that are maintained and
tested before every release.
I found several great tutorial that I can point Beginners at, but many
of them do not work anymore.
What you, board and the community currently built is a great eco sytem
for tools and it is getting better every month.
That is something that one can really tell.
Please do not forget to take care of the upcoming Smalltalkers and their
problems.
There should be a timechart on Pharo.org that shows when (during which
Pharo release) which framework was/is supported or considert feasable.
Is BLoc old, or new? Is is deprecated or upcoming? Do the Pharo
maintainers consider it usable with the current release and if not with
which?
"Welcome to the world of Smalltalk!"
You don't like that reaction? Well this is the reaction I get,.... and
well, what should I reply then? "If you don't like it, then contribute?"
A beginner is shy and insecure,... they simply give up and download
information on SWIFT...
I propose that the community collects information on what Pharo is used
for. What are it's strength and what kind of application is it the
perfect abse for.
This would help guys like me to advertise it with less surprise for the
interested
I am sorry, I won't currently be able to contribute code to the Pharo
community since it is not part of my current stack.
But I release chucnk of thought useful implementations that I encounter
in my other dialects.
The only thing that I can provide you with are critical questions that I
encounter.
That might change, but it is all I can do so far.
Go on! But don't forget the beiggner and the basic ui.
Sebastian
Am 28.01.2015 um 12:23 schrieb stepharo:
It was a bit easy to say that.
You can get frustrated by the state of certain libraries and I can
tell you that we are fighting daily
to improve the system (writing doc, fighting to get funds for
engineers, coding).
Now you should ask yourself how you can help pharo.
Stef
Welcome to the world of Smalltalk!
Am 28.01.2015 um 07:27 schrieb Mark Rizun:
I have the same problem with PolygonMorph. It does not resize properly.
Also I couldn't find any event related with window resizing.
If you find a solution please let me know.
Mark
2015-01-28 16:19 GMT+01:00 Sebastian Heidbrink <shei...@yahoo.de
<mailto:shei...@yahoo.de>>:
Am 28.01.2015 um 07:07 schrieb Mark Rizun:
First the svg does not resive properly while resizing the
window.
What do you mean by this?
Well, I implemented the example window from spec.st
<http://spec.st> and added a ASVGMorph to it.
When I now resize the window, then the button changes his size
correctly but the svg somhow just seems to be put into the
background.
I then implemented a SVGMorpModel that includes a
ASVGMorpAdapter and adde dthis one to my example window but the
result is that the SVG resizes just half the speed...
How can I also introduce an animated SVG? Like an svg that
changes color during a mouse click?
To work with events that are implemented in AthensSvgMorph you
have to (as far as I know) access this morph.
You can do it by sending #widget message to your model to times
like this:
svgModel widget widget ==> svgMorph
Than morph can handle events like "changes color during a mouse
click".
Are there any particular Models that could be used as a
container for this SVGMorphAdapter?
SVGMorphAdapter is a class that represents a layer betwen
SVGMorph and model of svg in spec.
It allows model and morph to "communicate" with each other.
Mark