- Pharo-dev - lists.pharo.org

Re: [Pharo-project] alert: not defined on non-interactive ui manager

by Christophe Demarey

Hi, alert, abort, question, etc. are defined on MorphicUIManager (with a trait) but not on UIManager itself. As Stephane said, it may causes DNU when using a NonInteractiveUIManager. For example, if you try to update a version of KeyMapping in non interactive mode, it will failed because the load method defines a post-load action using alert (see ConfigurationOfKeyMapping>resetKeymapsAndWarn). So, should we define these methods as "subclass responsability" on UIManager or do I miss something? Regards, Christophe. Le 2 janv. 2013 Ã 16:05, StÃ©phane Ducasse a Ã©crit : > Hi all > > alert:, alert:title:... are defined on MorphicUIManager but not on NonInteractiveUIManager > so this means that we get DNU when loading packages that call it. > > http://code.google.com/p/pharo/issues/detail?id=7205 > > I thought that bringing a pop up or dun in non interactive mode was killing the system > but not. I'm confused but any how it would be good to have these two classes a bit more > polymorphic so tell me if I'm saying something stupid. > > Stef

Jan. 2, 2013

Re: [Pharo-project] UITheme builder, change newList list onButtonClick

by J. P. L. MartÃn

I got everything working besides the list update when changed. Also, is there anyway to properly display data in columns? This is what i have: http://i.imgur.com/bwK2M.png On Wed, Jan 2, 2013 at 11:47 AM, Ben Coman <btc(a)openinworld.com> wrote: > > J. P. L. MartÃn wrote: > > Hello, I'm having trouble to figure out how to do this, I have a simple >> window with 3 buttons, each button should change the content listed on the >> list below them but I'm really not sure about how to do it. >> >> This is the code for the window: >> --- >> open >> "Abre la ventana principal del Sistema de Gestion Bibleotecaria" >> >> | builder contain | >> builder := UITheme builder. >> contain := builder newColumn: {builder newRow: { >> builder newButtonFor: self action: #onPrestamosClick label: >> 'Prestamos' help: ''. >> builder newButtonFor: self action: #onMaterialesClick label: >> 'Materiales' help: ''. >> builder newButtonFor: self action: #onSociosClick label: >> 'Socios' help: ''}. >> builder newColumn: { >> builder newListFor: self list: nil selected: nil >> changeSelected: nil help: '' }.}. >> >> (contain openInWindowLabeled: 'Babel') extent: 600@600. >> --- >> >> How should I define #onLabelClick to set the list to for example: Prestamo >> database. >> >> Thanks in advance. >> >> >> > J. P. L. MartÃn wrote: > >> Actually the code of the GUI is inspired on the Pharocast video on the >> making of a Contact list. I wonder if the list is static since is defined >> there as a newListFor and because that you can't send any message to it, >> >> > The #changed: method tells the list to get its contents again - see > example below. > >> I'm sure there should be a way to do it so #onPrestamosClick look like: >> --- >> #onPrestamosClick >> listMorph list: Prestamo database. >> --- >> or something like that. >> >> >> >> > You didn't explicitly state your references, I presume you a referring to > http://www.pharocasts.com/**2011/02/pharo-gui-with-**polymorph.html<http://www.pharocasts.com/2011/02/pharo-gui-with-polymorph.html> > . > Note that ContactManager-**LaurentLaffront.1.mcz referred to from this > post uses... > > |builder newListFor: self list: > #contacts > selected: #contactSelectedIndex > changeSelected: #contactSelectedIndex: > help: ''.| > > whereas you have... > > builder newListFor: self list: nil > selected: nil > changeSelected: nil help: '' > which is the key part you are missing, where the (list: #contacts) defines > the method to return the list contents, for example... > --- > #contacts > ^ Contact database collect: [:aContact| > ', ' join: {aContact lastName. aContact firstName} > ]. > --- > > > You have defined your list contents as (list: nil), whereas if it was > (list: #selectedDatabase) the following might work... > --- > #onPrestamosClick > > selectedDatabase := Prestamo database. > self changed: #selectedDatabase. > --- > #selectedDatabase > ^selectedDatabase. > > --- > > good luck, > cheers -ben > > >

Jan. 2, 2013

[Pharo-project] alert: not defined on non-interactive ui manager

by StÃ©phane Ducasse

Hi all alert:, alert:title:... are defined on MorphicUIManager but not on NonInteractiveUIManager so this means that we get DNU when loading packages that call it. http://code.google.com/p/pharo/issues/detail?id=7205 I thought that bringing a pop up or dun in non interactive mode was killing the system but not. I'm confused but any how it would be good to have these two classes a bit more polymorphic so tell me if I'm saying something stupid. Stef

Jan. 2, 2013

Re: [Pharo-project] UITheme builder, change newList list onButtonClick

by Ben Coman

J. P. L. MartÃn wrote: > Hello, I'm having trouble to figure out how to do this, I have a simple > window with 3 buttons, each button should change the content listed on the > list below them but I'm really not sure about how to do it. > > This is the code for the window: > --- > open > "Abre la ventana principal del Sistema de Gestion Bibleotecaria" > > | builder contain | > builder := UITheme builder. > contain := builder newColumn: {builder newRow: { > builder newButtonFor: self action: #onPrestamosClick label: > 'Prestamos' help: ''. > builder newButtonFor: self action: #onMaterialesClick label: > 'Materiales' help: ''. > builder newButtonFor: self action: #onSociosClick label: > 'Socios' help: ''}. > builder newColumn: { > builder newListFor: self list: nil selected: nil > changeSelected: nil help: '' }.}. > > (contain openInWindowLabeled: 'Babel') extent: 600@600. > --- > > How should I define #onLabelClick to set the list to for example: Prestamo > database. > > Thanks in advance. > > J. P. L. MartÃn wrote: > Actually the code of the GUI is inspired on the Pharocast video on the > making of a Contact list. I wonder if the list is static since is defined > there as a newListFor and because that you can't send any message to it, > The #changed: method tells the list to get its contents again - see example below. > I'm sure there should be a way to do it so #onPrestamosClick look like: > --- > #onPrestamosClick > listMorph list: Prestamo database. > --- > or something like that. > > > You didn't explicitly state your references, I presume you a referring to http://www.pharocasts.com/2011/02/pharo-gui-with-polymorph.html. Note that ContactManager-LaurentLaffront.1.mcz referred to from this post uses... |builder newListFor: self list: #contacts selected: #contactSelectedIndex changeSelected: #contactSelectedIndex: help: ''.| whereas you have... builder newListFor: self list: nil selected: nil changeSelected: nil help: '' which is the key part you are missing, where the (list: #contacts) defines the method to return the list contents, for example... --- #contacts ^ Contact database collect: [:aContact| ', ' join: {aContact lastName. aContact firstName} ]. --- You have defined your list contents as (list: nil), whereas if it was (list: #selectedDatabase) the following might work... --- #onPrestamosClick selectedDatabase := Prestamo database. self changed: #selectedDatabase. --- #selectedDatabase ^selectedDatabase. --- good luck, cheers -ben

Jan. 2, 2013

Re: [Pharo-project] UITheme builder, change newList list onButtonClick

by Esteban A. Maringolo

Yes, the concatenation method (it is, #,) works only with collections(*). There is no automatic casting of objects to a string representation. In the long run you'll love that. And since String "is a" Collection, you can't send #, to other object, and neither pass an argument that is not a collection. Hence the need of the "conversion"(**) to a String. (*) In some particular cases the #, method is implemented in non collection classes for convenience. (**) There is no conversion taking place, your object is returning another one, instance of String, that is supposed to represent it as a whole or some aspect of it. You might create the String every time the message is received or if it is its name, you just return it. ps: I don't know how this relates to the Morphic subject :) Esteban A. Maringolo 2013/1/2 J. P. L. MartÃn <arguser(a)gmail.com>: > Done, I've just append asString on the collect: block. > > :D > > > On Wed, Jan 2, 2013 at 11:18 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: >> >> 2013/1/2 J. P. L. MartÃn <arguser(a)gmail.com>: >> > Another question, when I try this: >> > >> > Prestamo database collect: [:x | x id,' ',x idMaterial] >> > >> > I get Receiver of "," nil. How do I solve it? >> >> You probably have one or more elements in the collection returned by >> "Prestamo database" whose id's are nil. >> Then you're sending #, to a nil element. >> >> I would ensure all elements have an ID, or better than that I would >> delegate the printing responsibility to the element itself. >> It is: >> Prestamo database collect: [:x | x printIdAndMaterial] >> >> This way the testing of a nil id is done by the receiver. >> >> Regards, >> >> Esteban. >> >

Jan. 2, 2013

Re: [Pharo-project] UITheme builder, change newList list onButtonClick

by J. P. L. MartÃn

Done, I've just append asString on the collect: block. :D On Wed, Jan 2, 2013 at 11:18 AM, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: > 2013/1/2 J. P. L. MartÃn <arguser(a)gmail.com>: > > Another question, when I try this: > > > > Prestamo database collect: [:x | x id,' ',x idMaterial] > > > > I get Receiver of "," nil. How do I solve it? > > You probably have one or more elements in the collection returned by > "Prestamo database" whose id's are nil. > Then you're sending #, to a nil element. > > I would ensure all elements have an ID, or better than that I would > delegate the printing responsibility to the element itself. > It is: > Prestamo database collect: [:x | x printIdAndMaterial] > > This way the testing of a nil id is done by the receiver. > > Regards, > > Esteban. > >

Jan. 2, 2013

Re: [Pharo-project] UITheme builder, change newList list onButtonClick

by J. P. L. MartÃn

Thanks Esteban, I have another question. Some of the elements of Prestamo are Date objects, how can i collec them from database since they are not indexable? *btw, I'm trying to show them on a list. Thanks in advance! On Wed, Jan 2, 2013 at 11:18 AM, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: > 2013/1/2 J. P. L. MartÃn <arguser(a)gmail.com>: > > Another question, when I try this: > > > > Prestamo database collect: [:x | x id,' ',x idMaterial] > > > > I get Receiver of "," nil. How do I solve it? > > You probably have one or more elements in the collection returned by > "Prestamo database" whose id's are nil. > Then you're sending #, to a nil element. > > I would ensure all elements have an ID, or better than that I would > delegate the printing responsibility to the element itself. > It is: > Prestamo database collect: [:x | x printIdAndMaterial] > > This way the testing of a nil id is done by the receiver. > > Regards, > > Esteban. > >

Jan. 2, 2013

Re: [Pharo-project] UITheme builder, change newList list onButtonClick

by Esteban A. Maringolo

2013/1/2 J. P. L. MartÃn <arguser(a)gmail.com>: > Another question, when I try this: > > Prestamo database collect: [:x | x id,' ',x idMaterial] > > I get Receiver of "," nil. How do I solve it? You probably have one or more elements in the collection returned by "Prestamo database" whose id's are nil. Then you're sending #, to a nil element. I would ensure all elements have an ID, or better than that I would delegate the printing responsibility to the element itself. It is: Prestamo database collect: [:x | x printIdAndMaterial] This way the testing of a nil id is done by the receiver. Regards, Esteban.

Jan. 2, 2013

Re: [Pharo-project] UITheme builder, change newList list onButtonClick

by J. P. L. MartÃn

Another question, when I try this: Prestamo database collect: [:x | x id,' ',x idMaterial] I get Receiver of "," nil. How do I solve it? On Wed, Jan 2, 2013 at 9:33 AM, J. P. L. MartÃn <arguser(a)gmail.com> wrote: > could another way be on button action set a temporal variable "list"? for > newListFor. > > > On Wed, Jan 2, 2013 at 6:02 AM, J. P. L. MartÃn <arguser(a)gmail.com> wrote: > >> Hello, I'm having trouble to figure out how to do this, I have a simple >> window with 3 buttons, each button should change the content listed on the >> list below them but I'm really not sure about how to do it. >> >> This is the code for the window: >> --- >> open >> "Abre la ventana principal del Sistema de Gestion Bibleotecaria" >> >> | builder contain | >> builder := UITheme builder. >> contain := builder newColumn: {builder newRow: { >> builder newButtonFor: self action: #onPrestamosClick label: >> 'Prestamos' help: ''. >> builder newButtonFor: self action: #onMaterialesClick label: >> 'Materiales' help: ''. >> builder newButtonFor: self action: #onSociosClick label: >> 'Socios' help: ''}. >> builder newColumn: { >> builder newListFor: self list: nil selected: nil >> changeSelected: nil help: '' }.}. >> >> (contain openInWindowLabeled: 'Babel') extent: 600@600. >> --- >> >> How should I define #onLabelClick to set the list to for example: >> Prestamo database. >> >> Thanks in advance. >> >> >

Jan. 2, 2013

Re: [Pharo-project] About morph layout

by Igor Stasenko

On 2 January 2013 12:55, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > Hello again Igor > and Happy and Successful New "Pharo" Year 2013 > Thanks Hannes :) Wish best to you in New Year too :) > --Hannes > > my notes are inserted below. > > > On 12/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 24 December 2012 09:43, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>> Hello Igor >>> >>> Thank you for this interesting mail. An issue over 11 years old, see >>> below. >>> >>> On 12/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> Hi, >>>> >>>> just wanna share some ideas about how we can cleanup morph a bit. >>> >>> A bit? >>> It will be a lot of effort. >>> >> We can do it in small steps. >> >>> Squeak 4.4-12234 (current) >>> >>> Morph selectors size 1183 >>> >>> >>> Pharo 2.0 (Beta) >>> >>> Morph selectors size 865 >>> >>> >>> Cuis 4.1 (18th Dec 2012) >>> >>> Morph selectors size 343 >>> >>> >>> This was an issue in 2001 >>> >>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt >>> >>> see >>> >> I am not first day here, of course i am aware of this :) > > Did you start working with Squeak already in 2001? > no. But i know this is a long standing issue :) >>>> Layout.. bizarre. >>> >>> Yes, see humorous contribution from June 2001 >>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt >>> >>> search for >>> >>> the Morph class has 924 methods >>> >>> in that mails >>> >>> There was an effort >>> Morphic Cleanup Project >>> >>> http://wiki.squeak.org/squeak/3005 >>> >>> lead by >>> >>> Diego Gomez Deck >>> >>> It produced some results. But they did not reach far enough. >>> >> yes yes.. i know. >> >>> However Juan Vuletic was successful in coming up with a simpler Morphic in >>> Cuis. >>> >>> http://www.jvuletich.org/Cuis/Index.html >>> >> search this mailing list for Small Morphic. >> It was an attempt to use Juan's work, which didn't fly. > > Of course I am aware of SmallMorphic. If a first attempt at > integrating SimpleMorphic into Pharo was not successful it does not > necessarily mean that a second one has to be a failure again. > > Time spent on an analysis why it didn't fly is surely not a waste. > > For example another approach could be instead of copying code from > Cuis and implanting it into Pharo "blob style" you could follow Juan > Vuletich's refactoring steps incrementally and copy smaller chunks of > code. Cuis had many releases until it reached version 4.1. > > In terms of factoring out classes from the class Morph you seem to > want to do that anyway. > > See for example > > http://www.jvuletich.org/Cuis/CuisReleaseNotes.html > New in Cuis 2.7 (released September 3, 2010) > > * Morphic. New LayoutSpec mechanism. Simpler and nicer. > * Morphic Simplification: Layout, Extensions, etc > Well, one thing is that Juan doing quite radical changes to code. He is not concerned about backwards compatibility (but unlike from Pharo, nobody raising it as an issue over and over again ;) ). Yes, i checked new Cuis code. I see a lot of simplifications. But also i see reduced functionality. For instance, i did not found things like 'fill style', and themes. Also, i see some protocols is renamed, in preparation for something bigger (morphic 3 i guess ;) So, i agree we should not copy/paste the code. Because it won't fly. We should gradually analyze it and improve ours step by step. Layout code in Cuis is somewhat similar to what i proposing. But my proposal is essentially about approach, which you can apply to anything.. not just layouts in Morphics. >>>> There are so many methods dedicated to laying out morphs that it easy >>>> to get lost. >>> >>> Cuis has a new layout system. >>> >>> Worth to check out. >>> >> Sure. > > Fine. > >> >>>> For me the main mystery and source of confusion is that there actually >>>> two different groups: >>>> >>>> - methods to control morph's own layout (in respect to its parent) >>>> - methods to control morph's children layout (something called >>>> layoutPolicy) >>>> >>>> the problem is that both APIs are found in single class, >>> >>> which one? >>> >> Morph >> >>> and most of >>>> them contain 'layout' word in it, >>>> so it is really hard to determine which one to use and when.. >>>> >>>> Over a years, i seen that people learned how to use existing >>>> functionality, without delving deep into >>>> implementation detail. >>> >>> Yes. >>> >>>> But if you try to extend/change behavior (in your subclass), you will >>>> quite soon find out that it is really >>>> hard to tell with 100% certainty that the methods you override is the >>>> right place for your customization. >>> >>> Yes, this actually has made development very difficult. In such a way >>> that most people have abandoned it. Very few GUIs are actually built >>> with it. >>> >>> >>>> Also, an important detail is extremely polluted protocol(s), making >>>> Morph a GOD class, > > Morph is at the root of a large subclasses tree. The question is: what > can be pushed down or factored out. An analysis in terms of number of > method candidates to move out would surely be a good thing to know. > -- Best regards, Igor Stasenko.

Jan. 2, 2013