- Pharo-dev - lists.pharo.org

Spec terminology: renaming some terms

by Johan Fabry

Hi all, I donât read mails on pharo-dev usually, so sorry if this has been discussed before (and then pointers to the discussion would be appreciated). Last week, in Pharo-users I proposed the Spec terminology changes below. Responses were positive. I am willing to volunteer to do that next week so itâs finished before the 28th and itâs included in Pharo 4. And then I will update the documentation as well. But first I want to know if there are any objections from people on this list. I propose to rename: - ComposableModel to ComposableUI - all the protocols âprotocol-*â to âAPI-*â Other renaming-related comments are also welcome. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Feb. 19, 2015

Re: [Pharo-dev] [FIX (Maybe ; ))]: Issue 14959: MC Hook for Default Credentials

by Thierry Goubier

2015-02-19 11:28 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 19 Feb 2015, at 11:20, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > .... > > Yes! I want an end to that big switch ! > > > > (I had to write an override to that to get gitfiletree:// urls to work, > as well as two or three other spots in Zn where known url protocols are > hardcoded). > > Yes, you told me that at the Pharo Days, maybe you could show me what you > had to override and what was bothering you ? > Hum: The overrides I have are: ZnUrl class>>defaultPortForScheme: (I think it appears on error paths through Zn) ZnUrl>>McRepositoryAsUser:withPassword: (Where things missing would also be the github:// and the bibucket:// urls... I believe you can't use them via Gofer because of that). and ZnUrl>>asFileReference (Where there is an assert). I believe ZnUrl>>enforceKnownScheme is also problematic. I just searched through all ZnURL methods containing #http :) Thierry

Feb. 19, 2015

Re: [Pharo-dev] Athens/Morphic

by Nicolai Hess

Most of this (without the test class (AthensTestDisplay)) is now ready for integration. A lot of changes for making Mophic and Text(Morphs) work on Athens (For testing purpose there is also the AthensWrapWorldMorph included). The Canvas wrapper (AthensCanvasWrapper) is not yet included and therefore all Morphs that do not explicit have a proper drawOnAthensCanvas method arent't drawn (or just like rectangles). Should work with any image >= 40490 Just load the latest ConfigurationOfAthens from pharo 40 inbox and load ConfigurationOfAthens loadVersion:'2.9' If this is working (or not:) ) please leave a note on fogbugz: "14954 load new configuration 2.9 (more morphic support)" nicolai 2015-01-31 11:54 GMT+01:00 Alain Plantec <alain.plantec(a)yahoo.com>: > > > Yes the HandMorph is handled like any other Morph, it draws itself and > after that it draws all its submorphs. (And actually it does not use any > caching, and it is still quite fast) > > > the same in Bloc, no caching and it works just fine :) > > But yes, it needs a special drawOnAthens method. > > >> Do you plane to make a package for it ? >> I would like to integrate it in Bloc. >> > > What would like to integrate? > > In fact I do not see any change when in Bloc. > So I guess I will have to adapt Bloc to your changes. > > I will upload the changes in Athens-Morphic package to > the Athens repository. > > > cool. > > thanks > > Alain >

Feb. 19, 2015

Re: [Pharo-dev] something else than a stupi timestamp in pane of the glamour workspace.... please

by Esteban Lorenzano

> On 19 Feb 2015, at 11:47, Norbert Hartl <norbert(a)hartl.name> wrote: > > If there is only one pane there shouldn't be a tab header at all. +1 > > Norbert > >> Am 18.02.2015 um 20:52 schrieb stepharo <stepharo(a)free.fr>: >> >> something else than a stupi timestamp in pane of the glamour workspace.... please >> please please please. >> It gives this impression that pharo is not finished at all. >> >> > >

Feb. 19, 2015

Re: [Pharo-dev] something else than a stupi timestamp in pane of the glamour workspace.... please

by Sven Van Caekenberghe

I think the idea is that each workspace, even each snapshot of it, is uniquely identified. The question remains if the label and the identifier have to be the same. > On 19 Feb 2015, at 11:47, Norbert Hartl <norbert(a)hartl.name> wrote: > > If there is only one pane there shouldn't be a tab header at all. > > Norbert > >> Am 18.02.2015 um 20:52 schrieb stepharo <stepharo(a)free.fr>: >> >> something else than a stupi timestamp in pane of the glamour workspace.... please >> please please please. >> It gives this impression that pharo is not finished at all. >> >> > >

Feb. 19, 2015

Re: [Pharo-dev] something else than a stupi timestamp in pane of the glamour workspace.... please

by Norbert Hartl

If there is only one pane there shouldn't be a tab header at all. Norbert > Am 18.02.2015 um 20:52 schrieb stepharo <stepharo(a)free.fr>: > > something else than a stupi timestamp in pane of the glamour workspace.... please > please please please. > It gives this impression that pharo is not finished at all. > >

Feb. 19, 2015

Re: [Pharo-dev] [FIX (Maybe ; ))]: Issue 14959: MC Hook for Default Credentials

by Sven Van Caekenberghe

> On 19 Feb 2015, at 11:20, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-02-19 11:11 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 19 Feb 2015, at 03:15, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > > Fix in inbox: > > SLICE-Issue-14959-MC-Hook-for-Default-Credentials-SeanDeNigris.1 > > > > When creating a repo in the MC Browser, it would be great to pre-populate > > the user and password fields. > > > > Thus, we declare a CredentialSource role collaborating with MCHttpRepository > > and subclasses. The in-kernel default is a no-op Null object, but users can > > install (via MCHttpRepository class>>#credentialSource:) any object that > > responds to #defaultUserFor: and #defaultPasswordFor: > > > > I'd like to apply this to Gofer, too, but I found a big switch statement in > > ZnUrl>>#mcRepositoryAsUser:withPassword: and now my head hurts ;) > > Yes, that is not good (ahem). > > We should let the root, MCRepository, decide, probably doing a lookup through its subclasses. All subclasses should also uniformly take credentials. > > Yes! I want an end to that big switch ! > > (I had to write an override to that to get gitfiletree:// urls to work, as well as two or three other spots in Zn where known url protocols are hardcoded). Yes, you told me that at the Pharo Days, maybe you could show me what you had to override and what was bothering you ? > Thierry > > > > Anyway maybe this will spur discussion... > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: http://forum.world.st/FIX-Maybe-Issue-14959-MC-Hook-for-Default-Credentials… > > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > >

Feb. 19, 2015

Re: [Pharo-dev] something else than a stupi timestamp in pane of the glamour workspace.... please

by Piotr Klibert

+1 for this. The timestamp is ugly and not very readable. Actually, one of the first things I did with my image was to change GTPlayPage>>initialize to something like: initialize content := ''. title := String streamContents: [ :s | DateAndTime now printHMSOn: s. ] but 'Pane 1', 'Pane 2' etc. would work too. Best regards, Piotr Klibert 2015-02-19 9:11 GMT+01:00 stepharo <stepharo(a)free.fr>: > Do > I put 'Pane 1' instead of this timestamp and it took me around 15 s to do > it. > So I guess that this is possible to propose a simple fix, isn't > > Stef > > Le 18/2/15 21:27, Tudor Girba a Ã©crit : > > That's because this part is not finished :). It should come, hopefully > before the feature freeze. Otherwise, we can treat it as a bug :D > > Doru > > On Wed, Feb 18, 2015 at 8:52 PM, stepharo <stepharo(a)free.fr> wrote: > >> something else than a stupi timestamp in pane of the glamour >> workspace.... please >> please please please. >> It gives this impression that pharo is not finished at all. >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > >

Feb. 19, 2015

Re: [Pharo-dev] [FIX (Maybe ; ))]: Issue 14959: MC Hook for Default Credentials

by Thierry Goubier

2015-02-19 11:11 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 19 Feb 2015, at 03:15, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > > > Fix in inbox: > > SLICE-Issue-14959-MC-Hook-for-Default-Credentials-SeanDeNigris.1 > > > > When creating a repo in the MC Browser, it would be great to pre-populate > > the user and password fields. > > > > Thus, we declare a CredentialSource role collaborating with > MCHttpRepository > > and subclasses. The in-kernel default is a no-op Null object, but users > can > > install (via MCHttpRepository class>>#credentialSource:) any object that > > responds to #defaultUserFor: and #defaultPasswordFor: > > > > I'd like to apply this to Gofer, too, but I found a big switch statement > in > > ZnUrl>>#mcRepositoryAsUser:withPassword: and now my head hurts ;) > > Yes, that is not good (ahem). > > We should let the root, MCRepository, decide, probably doing a lookup > through its subclasses. All subclasses should also uniformly take > credentials. > Yes! I want an end to that big switch ! (I had to write an override to that to get gitfiletree:// urls to work, as well as two or three other spots in Zn where known url protocols are hardcoded). Thierry > > > Anyway maybe this will spur discussion... > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/FIX-Maybe-Issue-14959-MC-Hook-for-Default-Credentials… > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > >

Feb. 19, 2015

Re: [Pharo-dev] [FIX (Maybe ; ))]: Issue 14959: MC Hook for Default Credentials

by Sven Van Caekenberghe

> On 19 Feb 2015, at 03:15, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Fix in inbox: > SLICE-Issue-14959-MC-Hook-for-Default-Credentials-SeanDeNigris.1 > > When creating a repo in the MC Browser, it would be great to pre-populate > the user and password fields. > > Thus, we declare a CredentialSource role collaborating with MCHttpRepository > and subclasses. The in-kernel default is a no-op Null object, but users can > install (via MCHttpRepository class>>#credentialSource:) any object that > responds to #defaultUserFor: and #defaultPasswordFor: > > I'd like to apply this to Gofer, too, but I found a big switch statement in > ZnUrl>>#mcRepositoryAsUser:withPassword: and now my head hurts ;) Yes, that is not good (ahem). We should let the root, MCRepository, decide, probably doing a lookup through its subclasses. All subclasses should also uniformly take credentials. > Anyway maybe this will spur discussion... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/FIX-Maybe-Issue-14959-MC-Hook-for-Default-Credentials… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Feb. 19, 2015