May 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] FileBrowser/FileList rant

by Benjamin

We will have to reimplement it using Spec so :) Ben On May 14, 2012, at 3:02 PM, Camillo Bruni wrote: > well the previous implementation was so horrible I didn't really feel > to fix too much. besides, drag and drop works pretty nicely, so I personally > don't see why using a shitty file browser in pharo when I can do the same thing > 100 times faster in my OS :/ > > but I think we will reimplement it from scratch in 2.0. The whole implementation > is almost orthogonal to the new FileSystem... > > > On 2012-05-13, at 16:56, Nicolas Cellier wrote: > >> Hi, >> it seems that FileBrowser/FileList is never used... >> And I absolutely don't understand some design choices. >> >> 1) Having a single reference inst var for both selectedDirectory and >> selectedFile : this is a bug factory, see >> http://code.google.com/p/pharo/issues/detail?id=5881 and >> http://code.google.com/p/pharo/issues/detail?id=5884 for example of >> bugs (I could open 1 bug entry per menu item I guess) >> >> 2) auto-selecting the file item under pop-up menu click >> This is a windows thing and anti-Smalltalk-UI-custom >> This is not at all uniform in the rest of Pharo UI (not even on the >> directory list) >> The implementation is buggish (see >> ttp://code.google.com/p/pharo/issues/detail?id=5882 which is duplicate >> of ttp://code.google.com/p/pharo/issues/detail?id=5625) >> >> There was (and still is) a specific menu when no file is selected... >> fileListMenu: aMenu >> reference >> ifNil: [^ self noFileSelectedMenu: aMenu] >> ifNotNil: [^ self fileSelectedMenu: aMenu]. >> >> I don't want to argue whether or not FileList did deserve a clean-up, >> I'm quite sure it did. >> And I also agree that we can temporarily break things in development images. >> But when the clean-up is so far from anything functional, I just >> wonder who do you want to eat the dog food? >> I'm a bit sick of it ;) >> >> Nicolas >> > >

May 14, 2012

Re: [Pharo-project] Notify progress with Announcements instead of Exceptions

by Sean P. DeNigris

Sean P. DeNigris wrote > > * String>>displayProgressAt:from:to:during: has "deprecated" in the > comment, but is not in a deprecated category. The timestamp is 9/7/11 > which puts it either 1.2 or early 1.3, but either way, it should be > removed for 2.0, right? There is only one sender in the image, which can > easily be fixed to call #displayProgressFrom:to:during: > Steph, this one's yours, do you know why it was deprecated and why it was done in the comment instead of using deprecated:on:in:? Is wanting to place a progress bar in a specific location not ever needed? If not, we should remove it from all the UIManagers also, right? Thanks. Sean -- View this message in context: http://forum.world.st/Notify-progress-with-Announcements-instead-of-Excepti… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 14, 2012

Re: [Pharo-project] FileBrowser/FileList rant

by Camillo Bruni

well the previous implementation was so horrible I didn't really feel to fix too much. besides, drag and drop works pretty nicely, so I personally don't see why using a shitty file browser in pharo when I can do the same thing 100 times faster in my OS :/ but I think we will reimplement it from scratch in 2.0. The whole implementation is almost orthogonal to the new FileSystem... On 2012-05-13, at 16:56, Nicolas Cellier wrote: > Hi, > it seems that FileBrowser/FileList is never used... > And I absolutely don't understand some design choices. > > 1) Having a single reference inst var for both selectedDirectory and > selectedFile : this is a bug factory, see > http://code.google.com/p/pharo/issues/detail?id=5881 and > http://code.google.com/p/pharo/issues/detail?id=5884 for example of > bugs (I could open 1 bug entry per menu item I guess) > > 2) auto-selecting the file item under pop-up menu click > This is a windows thing and anti-Smalltalk-UI-custom > This is not at all uniform in the rest of Pharo UI (not even on the > directory list) > The implementation is buggish (see > ttp://code.google.com/p/pharo/issues/detail?id=5882 which is duplicate > of ttp://code.google.com/p/pharo/issues/detail?id=5625) > > There was (and still is) a specific menu when no file is selected... > fileListMenu: aMenu > reference > ifNil: [^ self noFileSelectedMenu: aMenu] > ifNotNil: [^ self fileSelectedMenu: aMenu]. > > I don't want to argue whether or not FileList did deserve a clean-up, > I'm quite sure it did. > And I also agree that we can temporarily break things in development images. > But when the clean-up is so far from anything functional, I just > wonder who do you want to eat the dog food? > I'm a bit sick of it ;) > > Nicolas >

May 14, 2012

Re: [Pharo-project] Nautilus feedback - format of history pulldown combo box

by Benjamin

You are right. It was because it used to be package->class->protocol->method Fix in Nautilus-BenjaminVanRyseghem.277 in PharoInbox Ben On May 14, 2012, at 2:40 PM, Ben Coman wrote: > In Nautilus there is a combo box spanning and underneath the protocol and method panes which I shall presume to call the 'history pulldown' > where items are display like: MyObject -> myMethod: (1) > > The usual convention in most documentation seems to be: MyObject >> myMethod: (2) > > Now it strangely feels uncomfortable to getting used to (1). Is there a strong directive to move away from (2), or could this be used instead of (1). > > cheers -ben >

May 14, 2012

[Pharo-project] Nautilus feedback - format of history pulldown combo box

by Ben Coman

In Nautilus there is a combo box spanning and underneath the protocol and method panes which I shall presume to call the 'history pulldown' where items are display like: MyObject -> myMethod: (1) The usual convention in most documentation seems to be: MyObject >> myMethod: (2) Now it strangely feels uncomfortable to getting used to (1). Is there a strong directive to move away from (2), or could this be used instead of (1). cheers -ben

May 14, 2012

Re: [Pharo-project] Singleton access selector

by Carla F. Griggio

For personal/work projects, I also use #uniqueInstance. It's true that if #current is used for singleton instances it could be ambiguous. On Mon, May 14, 2012 at 7:12 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Historically, #soleInstance can be found in st80 I think. > > Nicolas > > 2012/5/14 Esteban Lorenzano <estebanlm(a)gmail.com>: > > > > > > On Mon, May 14, 2012 at 9:42 AM, Mariano Martinez Peck > > <marianopeck(a)gmail.com> wrote: > >> > >> > >> > >> On Mon, May 14, 2012 at 6:24 AM, Sean P. DeNigris < > sean(a)clipperadams.com> > >> wrote: > >>> > >>> I've noticed we use a buffet of accessors for singletons, like > #default, > >>> #instance, #current... it'd be nice to just pick one. I like #instance, > >>> but > >>> could live with any as long as I never have to guess which one from a > >>> list > >>> again :) > >> > >> > >> Indeed. For me it depends in the case. For the general case, I like > >> #uniqueInstance. And #default and #current I use it when it is not > completly > >> singleton. I mean, when there is a class side variable storing it, but > there > >> could be also some other instances, like non-default or non-current. > > > > > > +1 > > > >> > >> > >>> > >>> > >>> Sean > >>> > >>> -- > >>> View this message in context: > >>> http://forum.world.st/Singleton-access-selector-tp4630062.html > >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >>> > >> > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > > > >

May 14, 2012

Re: [Pharo-project] Singleton access selector

by Nicolas Cellier

Historically, #soleInstance can be found in st80 I think. Nicolas 2012/5/14 Esteban Lorenzano <estebanlm(a)gmail.com>: > > > On Mon, May 14, 2012 at 9:42 AM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> >> >> On Mon, May 14, 2012 at 6:24 AM, Sean P. DeNigris <sean(a)clipperadams.com> >> wrote: >>> >>> I've noticed we use a buffet of accessors for singletons, like #default, >>> #instance, #current... it'd be nice to just pick one. I like #instance, >>> but >>> could live with any as long as I never have to guess which one from a >>> list >>> again :) >> >> >> Indeed. For me it depends in the case. For the general case, I like >> #uniqueInstance. And #default and #current I use it when it is not completly >> singleton. I mean, when there is a class side variable storing it, but there >> could be also some other instances, like non-default or non-current. > > > +1 > >> >> >>> >>> >>> Sean >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Singleton-access-selector-tp4630062.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

May 14, 2012

Re: [Pharo-project] [Seaside] Zinc as static file server

by Sven Van Caekenberghe

Paul, On 12 May 2012, at 23:59, Sven Van Caekenberghe wrote: > I'll have a look later on (I have little time this weekend). > > We also need at least one simple test (another one of Marcus' quotes; if there is no actively run test, it does not exist). We just need an extra version of #testIfModifiedSinceNotModified directly on a local server, it will require some setup, be it should be doable. I integrated your changes and added 3 tests: --- Name: Zinc-HTTP-SvenVanCaekenberghe.275 Author: SvenVanCaekenberghe Time: 14 May 2012, 10:59:51 am UUID: 94f2451b-b7e0-4d74-866b-d55b01c98ed9 Ancestors: Zinc-HTTP-PaulDeBruicker.274 refactored ZnStaticFileServerDelegate a bit: - store expiration times as seconds in #defaultMimeTypeExpiration & #mimeTypeExpiration map - add not only Cache-Control but Expires header as well - removed unused #responseForFile: fixed a bug in ZnMessage>>#clearEntity (didn't #close streaming entities with HEAD requests) --- Name: Zinc-Tests-SvenVanCaekenberghe.142 Author: SvenVanCaekenberghe Time: 14 May 2012, 11:11:41 am UUID: 9f8498a3-c576-4844-a0f5-bafc5c5cbeca Ancestors: Zinc-Tests-SvenVanCaekenberghe.141 added ZnStaticFileServerDelegateTests for - expiration - cache-control - if-modified-since, not-modified --- Have a look and tell me what you think. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 14, 2012

Re: [Pharo-project] Notify progress with Announcements instead of Exceptions

by Esteban Lorenzano

Hi, On Mon, May 14, 2012 at 6:18 AM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > A few updates... > * String>>displayProgressAt:from:to:during: has "deprecated" in the > comment, > but is not in a deprecated category. The timestamp is 9/7/11 which puts it > either 1.2 or early 1.3, but either way, it should be removed for 2.0, > right? There is only one sender in the image, which can easily be fixed to > call #displayProgressFrom:to:during: > * String>>displayProgressFrom:to:during: should probably delegate to the > UIManager's displayProgress:from:to:during: > * Progress should have its own announcer. The progress could be something > that doesn't alter the system, so it doesn't really fit into system > announcer. > I don't like the idea of having several notification centers...I think that approach tends inevitably to chaos. instead, I much prefer an unique notification center for all system... I do think it fits System Announcer (as any other system announce), and you just receive notification if you are registered to do so... so, why not? Esteban > > -- > View this message in context: > http://forum.world.st/Notify-progress-with-Announcements-instead-of-Excepti… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

May 14, 2012

Re: [Pharo-project] Semantic Versioning

by Philippe Marschall

On 05/14/2012 04:45 AM, Sean P. DeNigris wrote: > Do you guys know about this? Yes, Eclipse uses it, successfully, for a decade. > This seems like it could fit really well with > Metacello... I don't think you'd be happy with the consequences. First you'd have to define what is API which is hard because everything is public in Smalltalk. And then you have to live by it which means you have much less freedom how you version things. Cheers Philippe

May 14, 2012