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 <sheidev@yahoo.de <mailto:sheidev@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