- Pharo-dev - lists.pharo.org

Re: [Pharo-project] about ToolBuilder

by StÃ©phane Ducasse

> So... let's suppose we get rid off ToolBuilder... any idea of what we should use? hand made? OB? Glamour? What I suggest is that we wait a bit. I would like to see with benjamin if we can help UIBuilder to get some windowspec and UIbuilder (VW like approach) or if this is possible to extend toolbuilder to support all the widgets. Stef > > Cheers, > Esteban > > On 2010-08-02 17:05:58 -0300, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> said: > >>> I agree that it should be removed, but this means that many tools need >>> to be rewritten in plain morphic. >> do you know which ones? >> Because a lot of buildwith: methods are not used in fact. >>> Lukas >>> 2010/8/2 Richard Durr <richard.durr(a)googlemail.com>: >>>> +1. >>>> See Gilad's text about least common denominator in UI-widgetery >>>> On Fri, Jul 30, 2010 at 12:20 PM, stephane ducasse >>>> <stephane.ducasse(a)free.fr> wrote: >>>>> Hi guys >>>>> during the sprint I discussed with Gary about ToolBuilder and we think >>>>> that it would be better to remove it >>>>> since a lot of new widgets are not covered so this means that we will be >>>>> constantly limiting ourselves. >>>>> Of course ToolBuilder is a nice idea (if we would have several UI >>>>> framework). So far we got only one >>>>> and we would have several we would have to take the smallest common >>>>> denominator. >>>>> Another idea would be to extend toolBuilder to support new widgets. >>>>> So what do you think? >>>>> Stef >>>>> _______________________________________________ >>>>> 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 >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> _______________________________________________ >>> 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

Aug. 7, 2010

Re: [Pharo-project] Trying to combine two images

by Schwab,Wilhelm K

Andreas, The effect from your examples was very subtle on my display, but it looked promising so I started hacking it into my code. The results were initially very strange, but I had been badly mangling the bitblt on my end. Things went from weird to simply ugly and I started comparing the types of forms. I was using ColorForm, so I switched that to Form (interestingly I had only recently started using ColorForm) and the results are now really nice. I am curious what you meant about simplifying things if my mask were alpha. AFAIK, I am perfectly willing to use it. What would stop me? Thanks!! Bill

Aug. 7, 2010

[Pharo-project] Trying to combine two images

by Schwab,Wilhelm K

Are there any good examples of using a mask to highlight portions of an image? I have an onion-skin effect in mind, but could live with almost anything that is easy to see and does not obliterate the underlying image. The goal is to paint a mask that will select irregular regions of an image. If I have a black and white mask, I can use #eraseShape: and #reverse to get two separate images, and I appear to be able to make the masked portion of one of them transpaent and can (not terribly well) highlight the masked portion of the other. Things quickly sprial down hill when I try to combine the two pieces. Any pointers would be appreciatiated. Bill

Aug. 7, 2010

Re: [Pharo-project] about ToolBuilder

by Esteban Lorenzano

So... let's suppose we get rid off ToolBuilder... any idea of what we should use? hand made? OB? Glamour? Cheers, Esteban On 2010-08-02 17:05:58 -0300, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> said: >> I agree that it should be removed, but this means that many tools need >> to be rewritten in plain morphic. > > do you know which ones? > Because a lot of buildwith: methods are not used in fact. > >> Lukas >> >> 2010/8/2 Richard Durr <richard.durr(a)googlemail.com>: >>> +1. >>> See Gilad's text about least common denominator in UI-widgetery >>> >>> On Fri, Jul 30, 2010 at 12:20 PM, stephane ducasse >>> <stephane.ducasse(a)free.fr> wrote: >>>> >>>> Hi guys >>>> >>>> during the sprint I discussed with Gary about ToolBuilder and we think >>>> that it would be better to remove it >>>> since a lot of new widgets are not covered so this means that we will be >>>> constantly limiting ourselves. >>>> Of course ToolBuilder is a nice idea (if we would have several UI >>>> framework). So far we got only one >>>> and we would have several we would have to take the smallest common >>>> denominator. >>>> Another idea would be to extend toolBuilder to support new widgets. >>>> So what do you think? >>>> >>>> Stef >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 6, 2010

Re: [Pharo-project] XML Parser, Monticello and unicode?

by StÃ©phane Ducasse

Henrik can you open bug entry for your nice gems? we should document and make sure that we will fix that. Stef On Aug 6, 2010, at 2:52 PM, Henrik Johansen wrote: > On Aug 5, 2010, at 5:37 34PM, Norbert Hartl wrote: > >> I'm trying to port the newest XML Parser from squeaksource to gemstone. In XML-Parser-AlexandreBergel.73 there is a unicode test introduced with a longer unicode xml snippet. From this release on I cannot load or merge anything. >> >> Besides that the xml snippet looks very strange it loads in pharo but not in gemstone. Unpacking the mcz on the console and examine the content showed that the encoding is indeed weird. I don't know what it is but it is neither ascii nor utf-8. Pharo loaded the snippet into a WideString instance. >> >> How does monticello handle WideString instances when written to a file? > > Rather randomly. ;) > > If you merely need to export a package so you can import in gemstone, you could change: > > MCMczWriter >> addString: internalString at: path > | member utfConverter utfStringStream| > utfConverter := TextConverter newForEncoding: 'utf8'. "(Or whatever other format Gemstone thinks .mcz definitions will be)" > utfStringStream := RWBinaryOrTextStream on: String new. > utfStringStream binary. > utfConverter class writeBOMOn: utfStringStream. > utfStringStream ascii. > utfConverter nextPutAll: internalString toStream: utfStringStream. > member := zip addString: utfStringStream contents asString as: path. > member desiredCompressionMethod: ZipArchive compressionDeflated > > (Alternatively use String new writeStream if you don't need/want to write BOM). > > Doing changes like this in the base image is unlikely without further investigation, as it would probably break reading new packages (saved in proper utf8) containing WideStrings into old images. > I haven't read the import code, but if the binary format is preferred by old images if available, it might be a reasonable compromise saving the source in utf8, provided you also include the binary file. > > Cheers, > Henry > > PS. Another fun fact I encountered when porting Assets: > Monticello uses MethodReference>>source, which kindly converts all LF / CRLFs in your source / strings in the source to CR. > So you can forget f.ex. trying to save arbitrary ByteArrays as strings in your code, and expect them to work the same when converting back to ByteArray after saving to monticello :) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 6, 2010

Re: [Pharo-project] [ANN] Pharo Metacello Universes

by Norbert Hartl

On 06.08.2010, at 23:16, StÃ©phane Ducasse wrote: >> >> Removing the packages from the MetacelloRepository as Stephane suggested would just make them platform dependent. > > I missed your point. I did not say to remve the package form metacello but to copy them so that we do not depend on a server > that suddenly disappear from earth. > Ah, ok, I got it somewhat different. > Now let us give a try and learn. > Yep, time will tell anyway. Norbert

Aug. 6, 2010

Re: [Pharo-project] How do you extract a superclass if you can't select multiple classes?

by StÃ©phane Ducasse

> Seriously - I think you've shown that with a good engine (which I'm hoping it is - it seemed that way when I first came across a few bits in Dolphin) - and a bit of knowledge (although you have tons - but I'm hoping we can follow in your footsteps), a few people could make a big impact on what is possible (I certainly don't find it easy to even contemplate writing these things in Eclipse, as the model is very complicated). Yes!!! Some eclipse refactoring were are may be still are because java is really complex compare to smalltalk and we should take advantage of that. >> Have a look the method #refactoring in ORCmdCreateSubclassRefactoring >> and ORCmdCreateSuperclassRefactoring. Maybe you can improve something >> in terms of UI -> Refactoring Engine interaction? > > I will certainly have a look - and maybe with a bit of guidance at ESUG I might be able to make a difference too. > >> There are already numerous refactorings that I "ported" from Eclipse: > > I just took these for granted... I've been "spoiled" while being away, and had forgotten what the original base set was. I LOVE the generate multiple accessors (and the ability to edit that list and remove ones you don't want). I sometimes which it was a bit more tickable - but the alt-x (or right click) on an item works reasonably well. > >> As well as some new Smalltalk specific ones: > > Nice. > > Thanks as always for your contributions on this - its inspiring > > Tim > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 6, 2010

Re: [Pharo-project] How do you extract a superclass if you can't select multiple classes?

by StÃ©phane Ducasse

On Aug 6, 2010, at 3:14 PM, Tim Mackinnon wrote: > Well I'm certainly glad that you cared to get the tests back up to scratch - and it makes our whole community more productive. A big thanks for this! > > I'm just a bit embarrassed that in our community - we keep talking about how we have these great refactoring tools (that were invented in smalltalk) - but it looks like in Pharo (and I guess Squeak) - they've fallen a bit behind in terms of usability. yes this is clear. This is why we should wake up and this is why I thank lukas to have invested and fixed RB and its engine. > My scenario is a very frequent one - and it should be possible to do effortlessly (and I think that the pieces are in place to do it). > > Maybe at ESUG we can rally some energy to help support some of these things (hold an appeal fund... not money - but contributions). I want to help - I just am not sure how to yet - and sometimes this is partly my surprise to discover that some of the things I thought already worked - don't. > > Maybe in the show us your projects demo's it might be worth replaying this scenario and showing how it works in Pharo, and how it works in Eclipse (and maybe another Smalltalk) - and then showing some of the features available in the refactoring engine and trying to get support for improving it. This along with useful keyboard shortcuts are the things that eat away at the awesome productiveness I've noticed in other areas. start small and help this is the best things and once a small thing is done pass to the next one. We will all make progress. Stef > > Tim > > > On 6 Aug 2010, at 13:03, Lukas Renggli wrote: > >> On 6 August 2010 13:04, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: >>> Hmmm - (again if you can please be patient with me)... I really am missing >>> something big here? >>> >>> So in my example class X and Y are subclasses of WAComponent - which has >>> tons of subclasses (it could be even worse, they could subclass Object?). So >>> does this mean that I should create my superclass A first? >>> >>> E.g. I create a new subclass of WAComponent, called A. I then make X and Y >>> subclass A. Now I can do the "Refactor Class | Create Subclass" refactoring, >>> and so I have to call it A2 (ultimately I only want A - but if needs must). >>> Then I do get the prompt that you are referring to and can select both X and >>> Y. Finally it just offers to make me class A2 but unlike what I was trying >>> below it doesn't offer to move up any methods or instance variables???? >>> >>> So this doesn't work? And furthermore it seem much more convoluted than it >>> should be? >> >> I don't know. >> >> Keep in mind that nobody really cares about OmniBrowser, the >> Refactoring Engine, and all the other development tools. A few years >> ago they were just rotting along, most tests were broken and the >> refactoring code base was on outdated code from the last century. I am >> maintaining these tools because they make me more productive, not >> because it is fun. >> >> I would love to use something as sophisticated as Eclipse, but I don't >> have interest to do that myself. So I just continue to fix and enhance >> what works for me. If somebody else provides something better, I am >> happy to give it a try. >> >> Lukas >> >>> I don't understand why Refactor Class | Create Superclass doesn't prompt me >>> for other peer classes (this is what I want - in fact what I really, really >>> want is to select 2 classes in the first place). >>> >>> Maybe I'm being really stupid, or does no-one use this refactoring in Pharo? >>> It would seem that my scenario is a very common one - so I'm struggling with >>> this. And frustratingly it seems that all the horsepower to do this, is >>> built into the tools but they just don't use them in an intuitive way? >>> >>> Tim >>> >>> >>> On 6 Aug 2010, at 11:18, Lukas Renggli wrote: >>> >>>> Select the superclass of your classes X and Y and perform the 'create >>>> subclass' refactoring. A dialog asks you to choose the subclasses of >>>> your new class. >>>> >>>> This old website describes most of the refactorings: >>>> http://st-www.cs.illinois.edu/users/brant/Refactory/Refactorings.html. >>>> There is also a description in the tooltips of the menu actions. >>>> >>>> Lukas >>>> >>>> On 6 August 2010 11:47, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: >>>>> >>>>> Hi Lukas - sorry to keep this thread going, but I don't quite understand >>>>> what you mean? Partly I think the issue is that over the years I've >>>>> become >>>>> very familiar with the Eclipse/IntelliJ refactorings (and how they >>>>> approach >>>>> things) and I've slowly forgotten how they work in smalltalk (although - >>>>> in >>>>> Dolphin they seem to more closely match Eclipse/IntelliJ - adding to my >>>>> confusion in Pharo). >>>>> >>>>> To give some context, I had a class X, then I copied it to create class Y >>>>> - >>>>> made some changes and got something useful working. However X and Y are >>>>> mostly the same - so deserve a superclass. This sounds to me like >>>>> standard >>>>> Refactor Class | Create Superclass refactoring (available in the context >>>>> menu). Is this what you are referring to? (And this is a seaside30.rc >>>>> image). Is this the create class refactoring you are referring to? It >>>>> doesn't sound like it? >>>>> >>>>> The one I am referring to just asks me for a name of a superclass and >>>>> shows >>>>> me the method changes it will make (and I can remove those which I don't >>>>> deem common) - but they only apply to the single class I ran the >>>>> refactoring >>>>> for - say X. This then leaves me with Y which still needs work. I was >>>>> expecting somewhere where it would ask me if there are any other classes >>>>> to >>>>> consider for the refactoring (or better still - let me multi-select >>>>> several >>>>> classes before I do the "create superclass" in the first place - which >>>>> apparently is very hard in Pharo for some reason?). >>>>> >>>>> So is there some other browser, or menu option that I am missing? >>>>> >>>>> Tim >>>>> >>>>> On 6 Aug 2010, at 00:31, Lukas Renggli wrote: >>>>> >>>>>>>> Good point. I've been struggling with multiple selection too e.g. when >>>>>>>> setting the refactoring scope. There's an entry called "selection..." >>>>>>>> but >>>>>>>> since I've never been able to select more than one item from a list, >>>>>>>> selecting "selection..." has the same effect as âcategory" (when in a >>>>>>>> category list of course). >>>>>>> >>>>>>> So is there some way of applying a refactoring to more than one class? >>>>>>> What >>>>>>> is that refactoring scope menu item - is there some way to specify 2 or >>>>>>> more >>>>>>> classes in there? Why is this so hard? >>>>>> >>>>>> The refactoring scope is something completely different. It selects >>>>>> the part of the system that is considered by a refactoring. >>>>>> >>>>>> Did you ever try to go through the whole create-class refactoring? I >>>>>> get a dialog that offers me to select multiple classes. >>>>>> >>>>>> Lukas >>>>>> >>>>>> -- >>>>>> Lukas Renggli >>>>>> www.lukas-renggli.ch >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Lukas Renggli >>>> www.lukas-renggli.ch >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> 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

Aug. 6, 2010

Re: [Pharo-project] How do you extract a superclass if you can't select multiple classes?

by StÃ©phane Ducasse

On Aug 5, 2010, at 2:52 PM, Tim Mackinnon wrote: > Its a real pain that you can't multiple select things in the pharo UI... Agreed. Nor getting nice trees. > As I try and do things in Pharo and compare the operations to what I can easily do in Eclipse or Intelli-J - I've hit a new one - how do I extract a common superclass from 2 classes that are similar? > > I can refactor create superclass - but that just does it for one class, and then I can't easily make my second class a subclass as Pharo complains about duplicate instance variables. > > It seems like the capability is locked in there - but I keep struggling to work it out (refactoring in Pharo seems more complicated than it should be somehow - and I'm really looking forward to sitting down with someone someday and working out some keystrokes to use - extract method, extract temporary, inline temporary should just be keystrokes). > > Tim Thanks tim we need more clients :) (and producers too).

Aug. 6, 2010

Re: [Pharo-project] Issue 2756: Morphic Cleansing - Remove use of findA:

by StÃ©phane Ducasse

On Aug 6, 2010, at 4:54 AM, Guillermo Polito wrote: > Hi, removing some findA: message sendings Yes yes yes!!! We only need a few of them. > i've found: > > MenuMorph>>doButtonAction > "Do the receiver's inherent button action. Makes sense for the kind of MenuMorph that is a wrapper for a single menu-item -- pass it on the the item" > > (self findA: MenuItemMorph) ifNotNil: [:aMenuItem | aMenuItem doButtonAction] > > > And for me it doesn't make sense :). Even the comment doesn't make sense, because it isn't considering the case where a MenuMorph has multiple MenuItemMorph s. > > What should be done in cases like that? If it's my code, i should be tempted to delete it or maybe to deprecate it. And I'm really upset because it is a very difficult thing to verify not to break too much other things. So, what is the "official policy" about this cases? :P I don't like to leave it as it is... Get one or more scenario where the code behavior normally and rewrite so that it does not use findA: What I suggest is that you start with the easy findA: and publish often so that we integrate them in the system and slowly we learn and fix the ugly. Stef > > Cheers, > Guille > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 6, 2010