March 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Polymorph fixes
by Gary Chambers March 6, 2010

March 6, 2010

A few fixes on SqueakSource. Polymorph-Widgets-gvc.24 Polymorph-Tools-Diff-gvc.24 Notably: Table layout of submorphs with #shrinkWrap attributes. Themeing of menu item text colours to help Hilaire in his Sugar theme efforts. ThemeSettings integration left for another time... Wrong "sides" for "compare to current" when using diff tools in change sets (versions browser etc.). Prevention of window dragging from submorphs promoted from StandardWindow to SystemWindow (deals with oddities when click-dragging from submorphs... offset would be wrong and window "jumps"). Wrong colours for faded background windows in Watery themes. Fix colours in W2K theme (requires class-side reinitialisation of defaultSettings. Do "UIThemeW2K defaultSettings: nil" before changing theme). Toolbars now Panel-based to adapt to pane colour. DockingBar based menus now deal with mouseFocus correctly. Regards, Gary

3 8

Re: [Pharo-project] [Esug-list] Google Summer Of Code 2010 news!!!
by Paolo Bonzini March 6, 2010

March 6, 2010

On 03/06/2010 03:54 PM, Gilad Bracha wrote: >>> You_can_ write an Objective-C binding using CObject (as in, it's >>> been done). The painful part is converting NSArray<-> Array and >>> NSString<-> String. >>> >>> However, nice-looking bindings will always have a part written in >>> C that will be VM-dependent, which is why I put this project >>> last. It is much less useful than it looks. > > Inteoperating smoothly with the rest of the world is very useful. I fully agree. But there's so much more involved in interoperating smoothly with the rest of the world than Aliens/CObjects, and what's left is very hard to do in a cross-dialect way. So, having cross-dialect Aliens/CObjects is a nice step, but unfortunately it is still far from being a full solution. Paolo

1 0

[Pharo-project] Pharo help (was About danny help :)
by Torsten Bergmann March 6, 2010

March 6, 2010

Stef wrote: >I noticed it :) So I renamed the topic ;) >we are not in rush. Good. I trimmed the model down this evening to just one class and even the help browser is now much more flexible (already displaying static and dynamic help) >But I'm pragmatic. > - how to we fill up the help With the new simpler model you will be able to easily transform various sources ... for instance I think on even getting RSS feeds, IRC, list archive ... included by loading additional packages. I'm sure we will get more ideas once this all works. >For the UML I would like to have a simple sccripting descriptoin so that we can >define it. Do you know yuml.me? http://yuml.me/diagram/class/class/[Collection],[Collection]-[CharacterSet] The interesting thing is that we can even built this into the help browser today using HTTP and images - but one has to be online. However ... first I want to get the right infrastructure. More coming soon. If one wants to help: create a good HTML viewer based on the reworked Scamper (see http://www.squeaksource.com/LaurentLSandbox.html) Bye T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

4 5

[Pharo-project] Allow $- anywhere in binary selector
by stephane ducasse March 6, 2010

March 6, 2010

Lukas and others Nicolas published a version for pharo and it would be really cool if you could help me http://code.google.com/p/pharo/issues/detail?id=2115 Stef

4 4

[Pharo-project] Scratch Viewer comes to the iPhone
by John M McIntosh March 5, 2010

March 5, 2010

Scratch Viewer comes to the iPhone http://mobilewikiserver.com/Scratch.html Yes I'm building an iPad version too. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

1 0

[Pharo-project] About danny help :)
by Torsten Bergmann March 5, 2010

March 5, 2010

Stef wrote: >Hi danny > >I would like to integrate your help system in pharo so we will have see how we can proceed. >... >Yes this is good for my ego :))) Hey, hey ... and it is not good for my ego if you keep saying it is danny's help system! Ever looked at the project and code? ;) While I appreciate that Danny wants to contribute to the project I think his changes are not aligned with the original goals, design and ideas. First and most important: I want a simple model for the help system, which I first provided as HelpTopic HelpBook HelpPage after Danny's changes the baseline now looks like this: HelpTopic DynamicHelpPage ClassAPIHelp MethodListHelp PackageAPIHelpBook HelpBook HelpPage I have several problems with these three introduced classes: - They do not stand the "is a" inheritance test since a book (PackageAPIHelpBook) now "is a" page (DynamicHelpPage) - To make it even worse the class DynamicHelpPage adds three new instance variables (using blocks) totally ignoring the ivars inherited from HelpTopic (leaving unused slots in the instances). - the three new classes are more intended towards extracting/building the three types of dynamic help informations (package, class, method), So the behavior is more oriented towards "building" a book or page - but this is what the (yet unfished) builders are used for. Therefore the classes are also misplaced. - there is no single test provided Sorry Danny - but your changes look more like a quick way on getting a dynamic help "hacked in" than a clean design towards a stable Pharo help system! However - I'm in the midst of refactoring all this and hope to provide an even simpler model than the one I originally used. Please be a little bit patient before we all jump into this "feature adding thing". Stef/Danny wrote: >>I would like to add it in a modular way. Does anybody has a nice idea? >I am not sure what you mean by modular. It has a Metacello configuration. Yes, it has a Metacello configuration which currently separates the test from the Core model/UI. My further work will provide an exchangable and more enhanced UI and no dependency on the Help system itself (at least for in image docu). I'm currently testing some ideas. >my point is if you imagine that we want a small system with good packages >where do we put the helpSystem. I intend to use pragmas to decouple this. So you could comment your code without having the help system installed. We have to make a clean distinction for the help system for: - in image documentation on classes/methods/packages/test cases that can also be accessed by the usual tools like browsers - big-picture like help (books, tutorials) I know you are all eager to play with the first in the help system but I think the second has more value and need for a help system. >A nice idea on squeak-dev was to add support for a simple structured markup >language like Markdown in class comments. We could use this to write "big- >picture" documentation directly in a class comment. Yes ... but a class comment is as the name implies just a comment for a class. You typically dont write a "big-picture" documentation in a class comment. If you write a documentation on how to use Streams, Collections or Exception Handling ... which is the class you would use for the comment? Dont get me wrong: I like well described classes but the Help system should mainly address the "big-picture" documentation for tools, frameworks, the system, ... Adding other types like the dynamic API help are easy to integrate/generate. Another goal is to use the HelpSystem to document a (commercial) software you have written in Pharo or reuse the content for a documentation appearing on a website. Danny wrote: >In a package you put in the most important class a comment that looks somehow >like this: How do you measure the importance of a class ... ? ;) Stef wrote: >we can load HelpSystem and use it but since we want to have core >we should get it in Pharo but still make sure that everything in Core is adapted to give info >to Pharo. Two simple goals: - help is always optional and core could be without it - infos provided should not be dependent on the help system itself (for comments) >In addition I would like to have a tag for promoting test to be list in the help. ><documentation> > >Would be nice. Yes, there are many things that would be nice like generating books/pages from tests or examples or even dynamically build UML diagrams. We can have that in future. But first we need a simple and good model we can built on and I'm working on it. Maybe I released too early ... Thanks T. -- GMX DSL: Internet, Telefon und Entertainment fÃ¼r nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02

2 1

[Pharo-project] [update 1.1] #11246
by Marcus Denker March 5, 2010

March 5, 2010

11246 ----- Issue 1336: Stack should be re-implemented Issue 1346: Clean up sort: and sortBy: (step 1: add TSortable) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] [update 1.1] #11245
by Marcus Denker March 5, 2010

March 5, 2010

11245 ----- Issue 2104: remove several unimplemented calls Issue 2113: asSortedArray -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] [1.1] Object>>initialExtent
by Alexandre Bergel March 5, 2010

March 5, 2010

Hi! I do not have a solution, but Object>>initialExtent was recently deprecated and this causes great usability problem. This deprecation is very valuable for a clean UI separation. However, I have a warning deprecation each time a window is open. The reason stems from the method: SystemWindow>>initialExtent ^ model initialExtent For now, in my image, I suppressed this deprecation. Again, I do not have a clean solution. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

5 4

[Pharo-project] Add Alien in 1.1 (Issue 1360)
by Schmidt, Marco March 5, 2010

March 5, 2010

I have updated issue 1360 with a zip file containing my current build. The zip-File was too large for the mailing list... Marco Schmidt

1 0