- Pharo-users - lists.pharo.org

Re: [Pharo-users] [Moose-dev] [ann] brick on top of bloc - preview

by Johan Fabry

It looks very cool! Keep up the good work! > On Aug 25, 2015, at 17:13, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > We are happy to announce the first preview version of Brick, a new widget set created from scratch on top of Bloc. > > Brick is being developed primarily by Alex Syrel (together with Alain Plantec, Andrei Chis and myself), and the work is sponsored by ESUG. Brick is part of the Glamorous Toolkit effort and will provide the basis for the new versions of the development tools. > > Brick's goal is to provide a beautiful looking widget set, and the default look is based on material design. The widgets are theme-able. > > Right now, there exists: > - Label > - Simple button > - Toggle button > - Checkbox > - Radio button > - Window with or without an active title bar that can include various visual actions and info > - Menu > - Beautiful scrollbars that are thin by default and enlarge when the mouse hovers over it > - Scalable list for huge amounts of items with various heights > (The list also allows one for embedding text widgets with in place editing) > > The next immediate target is the creation of a new Pager widget (the widget that is behind the current GTInspector). > > You can see some screenshots on the official site: > http://gt.moosetechnology.org/brick <http://gt.moosetechnology.org/brick> > > To play with it, you can download a ready-made image: > https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/gtoolk… <https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/gtoolk…> > > and, in a Bloc space, you can browse the examples: > BrExampleBrowser exampleOpen > > We would be happy to hear your feedback. > > Cheers, > Doru > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow" > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Aug. 25, 2015

Re: [Pharo-users] [ann] brick on top of bloc - preview

by Bernardo Ezequiel Contreras

Sorry, but after evaluating Gofer new smalltalkhubUser: 'Pharo' project: 'Brick'; configuration; loadDevelopment in Pharo5.0#50270, i got an Error: Unrecognized class definition The screenshots look really cool. thanks On Tue, Aug 25, 2015 at 5:13 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > We are happy to announce the first preview version of Brick, a new widget > set created from scratch on top of Bloc. > > Brick is being developed primarily by Alex Syrel (together with Alain > Plantec, Andrei Chis and myself), and the work is sponsored by ESUG. Brick > is part of the Glamorous Toolkit effort and will provide the basis for the > new versions of the development tools. > > Brick's goal is to provide a beautiful looking widget set, and the default > look is based on material design. The widgets are theme-able. > > Right now, there exists: > - Label > - Simple button > - Toggle button > - Checkbox > - Radio button > - Window with or without an active title bar that can include various > visual actions and info > - Menu > - Beautiful scrollbars that are thin by default and enlarge when the mouse > hovers over it > - Scalable list for huge amounts of items with various heights > (The list also allows one for embedding text widgets with in place editing) > > The next immediate target is the creation of a new Pager widget (the > widget that is behind the current GTInspector). > > You can see some screenshots on the official site: > http://gt.moosetechnology.org/brick > > To play with it, you can download a ready-made image: > > https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/gtoolk… > > and, in a Bloc space, you can browse the examples: > BrExampleBrowser exampleOpen > > We would be happy to hear your feedback. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

Aug. 25, 2015

Re: [Pharo-users] [ann] brick on top of bloc - preview

by Sven Van Caekenberghe

Very nice ! > On 25 Aug 2015, at 22:13, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > We are happy to announce the first preview version of Brick, a new widget set created from scratch on top of Bloc. > > Brick is being developed primarily by Alex Syrel (together with Alain Plantec, Andrei Chis and myself), and the work is sponsored by ESUG. Brick is part of the Glamorous Toolkit effort and will provide the basis for the new versions of the development tools. > > Brick's goal is to provide a beautiful looking widget set, and the default look is based on material design. The widgets are theme-able. > > Right now, there exists: > - Label > - Simple button > - Toggle button > - Checkbox > - Radio button > - Window with or without an active title bar that can include various visual actions and info > - Menu > - Beautiful scrollbars that are thin by default and enlarge when the mouse hovers over it > - Scalable list for huge amounts of items with various heights > (The list also allows one for embedding text widgets with in place editing) > > The next immediate target is the creation of a new Pager widget (the widget that is behind the current GTInspector). > > You can see some screenshots on the official site: > http://gt.moosetechnology.org/brick > > To play with it, you can download a ready-made image: > https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/gtoolk… > > and, in a Bloc space, you can browse the examples: > BrExampleBrowser exampleOpen > > We would be happy to hear your feedback. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Aug. 25, 2015

[ann] brick on top of bloc - preview

by Tudor Girba

Hi, We are happy to announce the first preview version of Brick, a new widget set created from scratch on top of Bloc. Brick is being developed primarily by Alex Syrel (together with Alain Plantec, Andrei Chis and myself), and the work is sponsored by ESUG. Brick is part of the Glamorous Toolkit effort and will provide the basis for the new versions of the development tools. Brick's goal is to provide a beautiful looking widget set, and the default look is based on material design. The widgets are theme-able. Right now, there exists: - Label - Simple button - Toggle button - Checkbox - Radio button - Window with or without an active title bar that can include various visual actions and info - Menu - Beautiful scrollbars that are thin by default and enlarge when the mouse hovers over it - Scalable list for huge amounts of items with various heights (The list also allows one for embedding text widgets with in place editing) The next immediate target is the creation of a new Pager widget (the widget that is behind the current GTInspector). You can see some screenshots on the official site: http://gt.moosetechnology.org/brick To play with it, you can download a ready-made image: https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/gtoolk… and, in a Bloc space, you can browse the examples: BrExampleBrowser exampleOpen We would be happy to hear your feedback. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Aug. 25, 2015

Re: [Pharo-users] How can an object have its "self" and "name" instance variables nil after being instantiated?

by Julien Delplanque

Ok, thanks for your answers. I think this is involved in the problem I had but I solved it by changing my approach anyway :). On 25/08/15 17:55, Mariano Martinez Peck wrote: > Well...Sven explained #gtDisplayOn: and he nailed it. > > On Tue, Aug 25, 2015 at 12:54 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> The problem is that KMCategory reimplements #name, which is not a good >> idea. And that is the method used by the inspector. Since the >> implementation of #name answers the instVar that's why it's nil. just >> remove KMCategory >> name and do the inspect again and you will see the >> different. >> >> >> >> On Tue, Aug 25, 2015 at 12:39 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> >>> Well, name is an instance variable that is simply nil. >>> >>> Self is printed as nil because this object has its own #gtDisplayOn: >>> method that prints just its name. >>> >>> You could try 'Basic Inspect' as well. >>> >>>> On 25 Aug 2015, at 17:30, Julien Delplanque <julien(a)tamere.eu> wrote: >>>> >>>> I didn't do anything like using these names as inst vars. You can >>> reproduce what I am talking about: >>>> KMCategory new inspect. >>>> >>>> On 25/08/15 17:25, Joachim Tuchel wrote: >>>>> I don't have an exact answer for you, but I think neither self nor >>> name are good names for inst vars. >>>>> >>>>> >>>>>> Am 25.08.2015 um 15:57 schrieb Julien Delplanque <julien(a)tamere.eu>: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I have an object that override KMCategory and that is initialized and >>> added to "KmRepository default" using #postLoadDoIt: message in BaselineOf >>> after the package is loaded in an image. >>>>>> But once it is loaded I have huge problems with keyboards entries, >>> they do not work any more, I get an exception each time I press a key. >>>>>> If I inspect the Singleton class variable of my category object I can >>> see it contains an instance of my object that have its "self" variable nil >>> and its "name" variable nil. Others variables look fine. How is it possible? >>>>>> I can remove my custom KMCategory by copy/paste code from sublime >>> text to Pharo and left click/do it and then everything is fine with my >>> keyboard: no more exception and it behave correctly. >>>>>> Thanks in advance, >>>>>> >>>>>> Julien >>>>>> >>>>>> >>>> >>> >>> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

Aug. 25, 2015

Re: [Pharo-users] How can an object have its "self" and "name" instance variables nil after being instantiated?

by Mariano Martinez Peck

Well...Sven explained #gtDisplayOn: and he nailed it. On Tue, Aug 25, 2015 at 12:54 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > The problem is that KMCategory reimplements #name, which is not a good > idea. And that is the method used by the inspector. Since the > implementation of #name answers the instVar that's why it's nil. just > remove KMCategory >> name and do the inspect again and you will see the > different. > > > > On Tue, Aug 25, 2015 at 12:39 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Well, name is an instance variable that is simply nil. >> >> Self is printed as nil because this object has its own #gtDisplayOn: >> method that prints just its name. >> >> You could try 'Basic Inspect' as well. >> >> > On 25 Aug 2015, at 17:30, Julien Delplanque <julien(a)tamere.eu> wrote: >> > >> > I didn't do anything like using these names as inst vars. You can >> reproduce what I am talking about: >> > >> > KMCategory new inspect. >> > >> > On 25/08/15 17:25, Joachim Tuchel wrote: >> >> I don't have an exact answer for you, but I think neither self nor >> name are good names for inst vars. >> >> >> >> >> >> >> >>> Am 25.08.2015 um 15:57 schrieb Julien Delplanque <julien(a)tamere.eu>: >> >>> >> >>> Hi, >> >>> >> >>> I have an object that override KMCategory and that is initialized and >> added to "KmRepository default" using #postLoadDoIt: message in BaselineOf >> after the package is loaded in an image. >> >>> >> >>> But once it is loaded I have huge problems with keyboards entries, >> they do not work any more, I get an exception each time I press a key. >> >>> >> >>> If I inspect the Singleton class variable of my category object I can >> see it contains an instance of my object that have its "self" variable nil >> and its "name" variable nil. Others variables look fine. How is it possible? >> >>> >> >>> I can remove my custom KMCategory by copy/paste code from sublime >> text to Pharo and left click/do it and then everything is fine with my >> keyboard: no more exception and it behave correctly. >> >>> >> >>> Thanks in advance, >> >>> >> >>> Julien >> >>> >> >>> >> > >> > >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Aug. 25, 2015

Re: [Pharo-users] How can an object have its "self" and "name" instance variables nil after being instantiated?

by Mariano Martinez Peck

The problem is that KMCategory reimplements #name, which is not a good idea. And that is the method used by the inspector. Since the implementation of #name answers the instVar that's why it's nil. just remove KMCategory >> name and do the inspect again and you will see the different. On Tue, Aug 25, 2015 at 12:39 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Well, name is an instance variable that is simply nil. > > Self is printed as nil because this object has its own #gtDisplayOn: > method that prints just its name. > > You could try 'Basic Inspect' as well. > > > On 25 Aug 2015, at 17:30, Julien Delplanque <julien(a)tamere.eu> wrote: > > > > I didn't do anything like using these names as inst vars. You can > reproduce what I am talking about: > > > > KMCategory new inspect. > > > > On 25/08/15 17:25, Joachim Tuchel wrote: > >> I don't have an exact answer for you, but I think neither self nor name > are good names for inst vars. > >> > >> > >> > >>> Am 25.08.2015 um 15:57 schrieb Julien Delplanque <julien(a)tamere.eu>: > >>> > >>> Hi, > >>> > >>> I have an object that override KMCategory and that is initialized and > added to "KmRepository default" using #postLoadDoIt: message in BaselineOf > after the package is loaded in an image. > >>> > >>> But once it is loaded I have huge problems with keyboards entries, > they do not work any more, I get an exception each time I press a key. > >>> > >>> If I inspect the Singleton class variable of my category object I can > see it contains an instance of my object that have its "self" variable nil > and its "name" variable nil. Others variables look fine. How is it possible? > >>> > >>> I can remove my custom KMCategory by copy/paste code from sublime text > to Pharo and left click/do it and then everything is fine with my keyboard: > no more exception and it behave correctly. > >>> > >>> Thanks in advance, > >>> > >>> Julien > >>> > >>> > > > > > > > -- Mariano http://marianopeck.wordpress.com

Aug. 25, 2015

Re: [Pharo-users] How can an object have its "self" and "name" instance variables nil after being instantiated?

by Sven Van Caekenberghe

Well, name is an instance variable that is simply nil. Self is printed as nil because this object has its own #gtDisplayOn: method that prints just its name. You could try 'Basic Inspect' as well. > On 25 Aug 2015, at 17:30, Julien Delplanque <julien(a)tamere.eu> wrote: > > I didn't do anything like using these names as inst vars. You can reproduce what I am talking about: > > KMCategory new inspect. > > On 25/08/15 17:25, Joachim Tuchel wrote: >> I don't have an exact answer for you, but I think neither self nor name are good names for inst vars. >> >> >> >>> Am 25.08.2015 um 15:57 schrieb Julien Delplanque <julien(a)tamere.eu>: >>> >>> Hi, >>> >>> I have an object that override KMCategory and that is initialized and added to "KmRepository default" using #postLoadDoIt: message in BaselineOf after the package is loaded in an image. >>> >>> But once it is loaded I have huge problems with keyboards entries, they do not work any more, I get an exception each time I press a key. >>> >>> If I inspect the Singleton class variable of my category object I can see it contains an instance of my object that have its "self" variable nil and its "name" variable nil. Others variables look fine. How is it possible? >>> >>> I can remove my custom KMCategory by copy/paste code from sublime text to Pharo and left click/do it and then everything is fine with my keyboard: no more exception and it behave correctly. >>> >>> Thanks in advance, >>> >>> Julien >>> >>> > >

Aug. 25, 2015

Re: [Pharo-users] How can an object have its "self" and "name" instance variables nil after being instantiated?

by Julien Delplanque

I didn't do anything like using these names as inst vars. You can reproduce what I am talking about: KMCategory new inspect. On 25/08/15 17:25, Joachim Tuchel wrote: > I don't have an exact answer for you, but I think neither self nor name are good names for inst vars. > > > >> Am 25.08.2015 um 15:57 schrieb Julien Delplanque <julien(a)tamere.eu>: >> >> Hi, >> >> I have an object that override KMCategory and that is initialized and added to "KmRepository default" using #postLoadDoIt: message in BaselineOf after the package is loaded in an image. >> >> But once it is loaded I have huge problems with keyboards entries, they do not work any more, I get an exception each time I press a key. >> >> If I inspect the Singleton class variable of my category object I can see it contains an instance of my object that have its "self" variable nil and its "name" variable nil. Others variables look fine. How is it possible? >> >> I can remove my custom KMCategory by copy/paste code from sublime text to Pharo and left click/do it and then everything is fine with my keyboard: no more exception and it behave correctly. >> >> Thanks in advance, >> >> Julien >> >>

Aug. 25, 2015

Re: [Pharo-users] How can an object have its "self" and "name" instance variables nil after being instantiated?

by Joachim Tuchel

I don't have an exact answer for you, but I think neither self nor name are good names for inst vars. > Am 25.08.2015 um 15:57 schrieb Julien Delplanque <julien(a)tamere.eu>: > > Hi, > > I have an object that override KMCategory and that is initialized and added to "KmRepository default" using #postLoadDoIt: message in BaselineOf after the package is loaded in an image. > > But once it is loaded I have huge problems with keyboards entries, they do not work any more, I get an exception each time I press a key. > > If I inspect the Singleton class variable of my category object I can see it contains an instance of my object that have its "self" variable nil and its "name" variable nil. Others variables look fine. How is it possible? > > I can remove my custom KMCategory by copy/paste code from sublime text to Pharo and left click/do it and then everything is fine with my keyboard: no more exception and it behave correctly. > > Thanks in advance, > > Julien > >

Aug. 25, 2015