October 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] OldSocket removal

by Damien Cassou

On Wed, Oct 22, 2008 at 11:24 PM, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > Ok, Michael R suggested I bundle these up, recheck them, so who would I send > them to? You should commit them directly to PharoInbox on SqueakSource. As an alternative, you can upload it to http://code.google.com/p/pharo/issues/detail?id=275. Thank you -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Oct. 23, 2008

Re: [Pharo-project] Merging one-click and pharo-dev

by Damien Cassou

On Wed, Oct 22, 2008 at 9:58 PM, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > That is preserving any resource fork, and meta-data from hfs file > attributes. > Also so retains the hidden file that is used by the finder to format the > folder view. > It doesn't need to be present I believe in order for the re-zipped app to > run, however I'd just keep it for now. > After you replace the image/changes and other files, just rezip it all. On > the mac unzipping it and the unarchive will > do the right thing with the __MACOS__ files/folders I guess I can just keep the zip file as it is and update the image and changes file directly. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Oct. 23, 2008

Re: [Pharo-project] OB annotation icons

by Antony Blakey

On 23/10/2008, at 9:40 AM, Antony Blakey wrote: > A video of it in action in VW is here: http://www.cincomsmalltalk.com/userblogs/antony/blogView?showComments=true&… I should point out that the VW version has none of the menu/ accelerator ordering/filtering etc. facilities. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 He who would make his own liberty secure, must guard even his enemy from repression. -- Thomas Paine

Oct. 22, 2008

Re: [Pharo-project] OB annotation icons

by Antony Blakey

On 23/10/2008, at 1:05 AM, David Roethlisberger wrote: > Any possibility to see how you do this browser? It's a commercial effort, but I will explain it. > Could you elaborate on that? I don't quite get this. How is the fact > that we use text (or string) to represent labels of items to be > rendered in lists related to the space usage in these lists due to > icons? Because the decision about how to represent those things is taken too early - in the model in effect. This is because of the #displayString:forNode: model. The system commits to a concrete (and very limited) representation too early. > This annotated text is just one representation of the item, the icon > is another one (kind of). So how could help us another abstraction > here? Rather than using strings, I use an object that represents an annotated label, which HAS a string but IS NOT a string. Filters can add/change annotations (nv-pairs) and when the list comes to render the item *the list* can decide how to render the string (which isn't styled) and the annotations. This is appropriate because the list is the first time the presentation object hits the UI. The renderer on the list can use a strategy pattern for different contexts and/or UI mechanisms. So the render can add more space and different locations for different types of things, and it can even do it dynamically e.g. adding an icon column if ANY item has a certain class of annotation - although that presumes a non-lazy implementation, which I use because I've completely re-implemented lists, scrollpanes, scrollbars etc. Furthermore the label object can carry a reference to the original model object, which makes DnD and command discovery/invocation more straightforward. I think there's too much unconsidered reuse in Squeak e.g. "Text looks like it sort of does what we want, *and it will be quick to do* - let's use that". IMO this is partly due to the 'playground' nature of Squeak, where the quality of the vision and specific goals are lost in a sea of playful expediency, and partly inherent to Smalltalk. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Borrow money from pessimists - they don't expect it back. -- Steven Wright

Oct. 22, 2008

Re: [Pharo-project] OB annotation icons

by Antony Blakey

On 23/10/2008, at 1:06 AM, Lukas Renggli wrote: > I disagree. I exclusively use OB in productive development on a daily > bases for over 2 years now. Decent selection support? Multiple selection? Dynamic filtering? Rich labels? Trees? Multiple 'definition' edges? OB is usable today, and I use it exclusively as well, but my point is that is should be a lot better. Why settle for 'great concept, ok realization'? I want something 'exceptional'. I think OB is a great start, and an excellent piece of work, but it doesn't stop it being a prototype that has been tested in the field and found to require structural modifications and some rethinking, as opposed to the hacks that have polluted what is a beautiful model. >> b) shouldn't include any action abstraction because that's best >> handled in a completely different and system-wide fashion; > > I disagree. OB provides this system-wide abstraction. It is the fault > of the other tools that don't use these abstractions. For example, > I've written a process browser, debugger, inspector and several other > tools in OB and they all benefit from the commands that already exist > and that other people write as extensions (e.g. open a hierarchy > browser from within the debugger). > > I agree that the abstraction is not optimal in all cases (e.g. text > commands, applicability tests, ...), but it is definitely better than > anything else I've seen so far. I have (IMO) a better system, called Commando, implemented in VW and now in Squeak. It has the following advantages: 1. Not tied to OB. 2. Commands are trivially enumerable, so a selection and discovery interface is natural. 3. Commands are applicable not only to UI elements, but also across- domains where the UI exposes a semantic marker/object. Thus the concept of an action is separated from the presentation of objects representing command parameters. 5. Commands can be easily structured into menus in both a context- sensitive, per-window and global manner, including platform-standard- specific positioning, as well as allowing manual semantically/HUI- factors directed grouping/ordering/accelerators, orthogonal to their definition. A video of it in action in VW is here: http://www.cincomsmalltalk.com/userblogs/antony/blogView?showComments=true&… > This is what happens, when an appealing and widely adapted projects > entirely lacks a form of leadership. IMO success is dependent on having either one, or a very few people who share a vision and taste, explicitly in control/gatekeeping, applying *their* taste and judgement (technical and aesthetic), and guiding a project in accordance with their specific vision. That's what I branched off on my own rather than joining a group, and naturally why no-one else has joined me :) I maybe completely out to lunch, but it's *my* lunch. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Some defeats are instalments to victory. -- Jacob Riis

Oct. 22, 2008

Re: [Pharo-project] OB annotation icons

by Antony Blakey

On 23/10/2008, at 7:19 AM, StÃ©phane Ducasse wrote: > would be nice to know do whom I'm replying. Me. > But still there is a value in knowing that the method is doing a > super call or not. > The indicator means that the method use the keyword "super". So this > is valuable. I cannot see why it is valuable given all the contexts in which super is used. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Hi, I'd like to do $THING. I know that $SOLUTION_A and $SOLUTION_B will do it very easily and for a very reasonable price, but I don't want to use $SOLUTION_A or $SOLUTION_B because $VAGUE_REASON and $CONTRADICTORY_REASON. Instead, I'd like your under-informed ideas on how to achieve my $POORLY_CONCEIVED_AMBITIONS using Linux, duct tape, an iPod, and hours and hours of my precious time. -- Slashdot response to an enquiry

Oct. 22, 2008

Re: [Pharo-project] OB annotation icons

by Antony Blakey

On 23/10/2008, at 7:21 AM, StÃ©phane Ducasse wrote: > can you explain the icons The left arrow, which comes in three forms - up, down and up&down, indicates declared-in-super/subclass. It is not overloaded with any other meaning. To the left of that is space for a green '+' that indicates 'is an extension', which is also used in the instance/class list. The 'x' indicates a method containing a halt. Normally, shifting the left side of the label is a bad idea because it makes scanning the list more difficult - it forces the user to explicitly read the label - but in the case of a halt that doesn't matter as much because it is both transient and operationally very significant. Except in the case of the method that looks for #halt, because it contains the symbol without actually *being* a halt method. I am considering adding a marker-method or pragma to allow you to control those few (reflective) methods that have this problem i.e. a manual semantic annotation. The right boxed forms are: comes-from-trait, is-unfulfilled-trait- requirement and is-trait-method-conflict. One of my focusses is including better support for traits in the UI. I think the comes-from- trait is too strong in relation to it's meaning. The right downwards arrow means is-abstract e.g. #subclassResponsibility. The right red star means '#needsWork or #flag:'. Those icons horizontally accumulate to the right, so multiple icons can co-exist. Note that red always means 'attention required', and how much the red stands out is in proportion to the nature of the issue. But I always pair color with a shape change to deal with color-blindness - a poor example is in VW's SUnit fail/success markers. I use an ellipsis for labels that are truncated by virtue of having icons to the right. I also have a hover mechanism that shows the full label in-place when you hover over it iff it is truncated, either with an explicit ellipsis or simply because it is too wide for the list. Also note that the column widths can be adjusted independently, and don't have to start an equal width. Some columns will always have icon spaces, some not. I did these before I gave in and bought a copy of Fireworks, so I was limited in what I could do shape wise without manually pixel painting e.g AA embosses. Anyone who's done that knows what a fiddly PITA it is. I thing a circular badge (for the trait markers) would be less jarring in general, although it's important to maintain a consistent aesthetic in that sense across the entire product, and circular forms commit you to a reduced area for the semantic payload. Furthermore there is a significant pragmatic benefit to using simple rectlinear icons that can be done well a) with simple tools and b) by many developers, because it allows contributors to produce icons for integratable components that don't look out of place. Check out the class type icons in VW for an example of how not to do it. For a system that is *meant* to be extended by the user, this is IMO an important consideration. This is very much a work in progress. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It is no measure of health to be well adjusted to a profoundly sick society. -- Jiddu Krishnamurti

Oct. 22, 2008

Re: [Pharo-project] OldSocket removal

by John M McIntosh

Ok, Michael R suggested I bundle these up, recheck them, so who would I send them to? On Oct 22, 2008, at 1:55 PM, StÃ©phane Ducasse wrote: > yes please john. > > Stef > > On Oct 21, 2008, at 6:55 PM, John M McIntosh wrote: > >> Actually the tests there are rather primitive, why don't you pickup >> the tests from >> http://www.smalltalkconsulting.com/html/OTNotes4.html -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Oct. 22, 2008

Re: [Pharo-project] Looking for ImageSegment tests

by John M McIntosh

We used imageSegments in Sophie to store cached font information, we then attempted to store a few more binary objects that way but soon discovered it was flaky..... Flaky meaning when we loaded an image segment it would crash the VM, but not always. We didn't have time to figure out exactly what the problem and back out our usage of it. On Oct 22, 2008, at 1:26 PM, StÃ©phane Ducasse wrote: >>>>> Hi all >>>>> >>>>> if by any chance you have some code that could be turned into >>>>> tests, or >>>>> some tests or some time to write tests for image segments this >>>>> would be great >>>>> because etoy is really deep inside image segment and I would >>>>> really like to keep this >>>>> beautiful idea working :) >>>> >>>> yes please. We use this in production (like DabbleDB), and it >>>> works very well. I just hope to never really need to understand >>>> the code... >>> >>> really read the code because it is full of etoy related ugly hack >>> (really ugly) >> >> I know... > > I imagine :) >>> >> I'll add it to my todo list > I can help I would love to write a small chapter on imageSegment for > the Volume 2 > because I also found the idea so cool. > > stef > >> >> >> Adrian >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Oct. 22, 2008

Re: [Pharo-project] OldSocket removal

by StÃ©phane Ducasse

yes please john. Stef On Oct 21, 2008, at 6:55 PM, John M McIntosh wrote: > Actually the tests there are rather primitive, why don't you pickup > the tests from > http://www.smalltalkconsulting.com/html/OTNotes4.html > > I also have some changes Rob Withers made if someone wants those > files for integration > > On Oct 21, 2008, at 12:14 AM, Damien Cassou wrote: > >> I've started working on OldSocket removal: >> http://code.google.com/p/pharo/issues/detail?id=275. I need someone >> to >> review my first changes. >> >> -- >> Damien Cassou >> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2008