- Pharo-users - lists.pharo.org

Re: [Pharo-users] StampClient produce only and dealing with heartbeat

by Henrik Sperre Johansen

+1. Testing the RabbitMQ client (very cool, BTW) some time ago (which is structured the same way with a single event loop), I ran into the same kind of issues Holger describes; for example, bursts of incoming data would cause a heartbeat to not be sent in time, and the server would drop connections.* At least at the time, I couldn't see a way to solve those issues in a reliable manner without resorting to using multiple threads** (but never got around to implementing that) Cheers, Henry * There also seemed to be drops related to what the client considered activity that should reset the heartbeat timeout, and what the server seemed to think, but even after (I think) fixing those, I could cause drops by flooding the client with traffic ** Yes, I know, You can configure RabbitMQ to not use heartbeats, but where's the fun in that?? -- View this message in context: http://forum.world.st/StampClient-produce-only-and-dealing-with-heartbeat-t… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 20, 2016

Re: [Pharo-users] StampClient produce only and dealing with heartbeat

by Holger Freyther

> On 19 May 2016, at 10:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Holger, Dear Sven, > However, you need a regular opportunity to send something out. Thinking out loud, what about something like > > StampClient>>#runWith: receiveBlock do: sendBlock > > where receiveBlock is like it is now, and sendBlock is called regularly, basically when the loop goes through another cycle, to give you the opportunity to send something, being sure to have exclusive access. > > In the sendBlock you could query your sharedQueue that is being filled by another process, properly MP safe. > > The invocation of #runWith:do: should of course be forked. > > Does that make sense ? It makes sense for my unacknowledged SEND but I see several issues for a general scheme: a.) If write / receive ratio is not equal and I block in the send then I will not receive quickly enough. And if we block on receive (with the *TimedOut) we will not write enough. This is one general architecture issue I seem to circle around[1]. I should not have block one or the other. b.) Integration with ACKed sends (putting a receipt, reading a receipt-id). Is there a generic way to handle it? E.g. I would keep an event in the SharedQueue until it has been acked (and detect timeouts or such). Last but not least. How do you handle the ConnectionClosed and do the re-connect? It seems that >>#runWith: will exit iff ConnectionClosed signal has been raised. Will you respawn the process? Will you create another StampClient and re-execute? sorry, more these are more questions than answers. I have a local client that is similar to >>#runWith:do: (but calls receive from within the send routine). kind regards holger [1] With POSIX/C there is select(), in Windows WaitForMultipleObjects and maybe with erlang the selective receive. Now it is not very object orientated but in pseudo erlang syntax. receive FrameReady -> self handleFrame: arg; FrameToSend -> self writeEvent: arg; Disconnect -> self reconnect. ... after self timeout -> self checkRecvHeartbeatOrSendIt end I could emulate it by spawning multiple processes on "receive", creating a queue, having a semaphore.. but I don't know if I want to limit it to sockets...

May 20, 2016

Panama Papers: a case for reproducible research, data activism and frictionless data (powered by Pharo)

by Offray Vladimir Luna CÃ¡rdenas

Hi, I'm glad to share my recent work with Pharo/Roassal in the form of a minisite[1] and a detailed blog entry[2] arguing about interactive environments for increasing understanding and participation in data phenomena: [1] http://mutabit.com/repos.fossil/panama-papers/doc/tip/index.html [2] http://mutabit.com/offray/blog/en/entry/panama-papers-1 Using a relatively simple visualization I advocate for this case. The bigger issues here were not related with visualization, but with accuracy/completion of the information. For example the original RTSVGPath includes only 167 world territories, but Panama Papers mentions over 210. Improving accuracy lead to hunting a bug and to its bugfix. So we have a more cleaver reader for SVG in Roassal. I was fighting for several days with newbie errors (like the one on the download bar not advancing, despite of the download being made). I think that this are good exemplars on how Pharo Roassal is a superb moldable and affordable platform on the issues of data oriented reproducible research (in journalism and/or activism and others). Comments and suggestions are welcomed, as always. Cheers, Offray

May 20, 2016

Why is split: implemented in the separator rather than the string?

by Andy Burnett

> > > > Message: 1 > Date: Thu, 19 May 2016 20:18:09 -0700 > From: John Pfersich <jpfersich(a)gmail.com> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] Why is split: implemented in the separator > rather than the string? > Message-ID: <C3F79F22-5675-4E29-97AC-A630D9ADA2E0(a)gmail.com> > Content-Type: text/plain; charset=us-ascii > > If you want to do it reversed, do it like this: > > '1969-07-20' splitOn: '-' > > > Thanks to both of you for responding. Makes sense. Cheers Andy

May 20, 2016

Re: [Pharo-users] Spec layout

by Marion Noirbent

Hi, Thanks, I think i can do it if i take inspiration from your code. I will put too an anotation in the book to correct it. Marion, Le 20/05/2016 00:42, Peter UhnÃ¡k a Ã©crit : > Hi, > > I've made a simple example â see attached fileout. > > Couple things to note: > > 1. >> If i put it on instance side, the lookup don't find it (in the book > Building UI with Spec, it said the lookup begin by the instance side and it > allow to have specific UI, in part about layout) > > As far as I know / as far as I can tell this is false for ComposableModel. > For DynamicComposableModel you can override the method "#layout". > > 2. For some odd reason when you add a new radio button it looks like a > checkbox and only once you click on it it turns into a checkboxâ¦ which is > WTF but it shouldn't matter atm > > 3. DynamicComposableModel holds the item in a Dictionary, since you can't > provide accessors for each item, you have to cobble together some other > selector, as shown in createWidgets > > 4. I don't know if this is the best approach, but I've been using something > like this for quite a while > > I'm quite busy this week, however I scheduled to take a look at the Spec > book next week as I should probably write something thereâ¦ > So if you have any more questions/comments please ask. > > Peter > > On Wed, May 18, 2016 at 2:19 PM, Marion Noirbent < > ms.noirbent(a)etudiant.univ-lille1.fr> wrote: > >> Ok, I wait your answer. >> Thanks for your help. >> Marion, >> >> >> Le 18/05/2016 12:04, Peter UhnÃ¡k a Ã©crit : >> >>> Yes but someone must call rebuildWidgetâ¦ I will try to take a look at this >>> today and give a better/more comprehensive example. >>> >>> Peter >>> >>> On Wed, May 18, 2016 at 1:01 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>> I do not get it. >>>> >>>> I still think that the solution of peter is the one to implement >>>> >>>> rebuildWidget >>>> self widgets removeAll. >>>> self createWidgets. >>>> self needFullRebuild: false. >>>> self buildWithSpecLayout: self dynamicLayout. >>>> self alignButtons >>>> >>>> >>>> dynamicLayout >>>> | keys | >>>> keys := self widgets keys. >>>> ^ SpecLayout composed >>>> newColumn: [ :c | >>>> keys do: [ :key | c newRow: key height: self class >>>> buttonHeight ]. >>>> c newRow: [ :r | ] ]; >>>> yourself >>>> >>>> >>>> >>>> Le 18/5/16 Ã 12:46, Marion Noirbent a Ã©crit : >>>> >>>> Because I would use "openWithSpec" to build only when the widget is >>>> ready, >>>> >>>>> but it call a method (with the good pragma) on the class side. >>>>> >>>>> In the example i use i have add RadioButtonModel with addRadioButton: in >>>>> the collection buttons, it's not empty but RadioButtonModel is a >>>>> ComposableModel and layout: is define in the subclass >>>>> DynamicComposableModel . >>>>> >>>>> Le 18/05/2016 10:22, stepharo a Ã©crit : >>>>> >>>>> But why from the class side. >>>>>> >>>>>> buttons >>>>>> ^ buttons >>>>>> >>>>>> returns an empty collection >>>>>> >>>>>> and >>>>>> >>>>>> rebuildWidget >>>>>> self widgets removeAll. >>>>>> self createWidgets. >>>>>> self needFullRebuild: false. >>>>>> self buildWithSpecLayout: self dynamicLayout. >>>>>> self alignButtons >>>>>> >>>>>> >>>>>> >>>>>> Le 18/5/16 Ã 11:31, Marion Noirbent a Ã©crit : >>>>>> >>>>>> I was trying to use it but i have still the problem to call the >>>>>>> instance method from the class side, so i call the >>>>>>> buildWithSpecLayout: in the method to add buttons in the collection, >>>>>>> it seems work but i have an "MessageNotUnderstood" >>>>>>> RadioButton>>layout: >>>>>>> >>>>>>> Le 18/05/2016 09:20, stepharo a Ã©crit : >>>>>>> >>>>>>> marion the solution is what peter proposes. >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> Le 18/5/16 Ã 11:14, Marion Noirbent a Ã©crit : >>>>>>>> >>>>>>>> In fact i was trying to modify RadioButtonGroup to turn it into a >>>>>>>>> widget, #buttons is not a widget but its collection of widget. >>>>>>>>> >>>>>>>>> May you have confused RadioButtonGroup with the MenuModel / >>>>>>>>> MenuGroupModel / MenuItemModel which are widgets. I take inspiration >>>>>>>>> from them and I would got the same kind of behaviour. >>>>>>>>> >>>>>>>>> Le 17/05/2016 21:11, stepharo a Ã©crit : >>>>>>>>> >>>>>>>>> Thanks Johan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We looked at >>>>>>>>>> >>>>>>>>>> RadioButtonGroupExample >>>>>>>>>> >>>>>>>>>> but you see we cannot have a RadioButtonGroupPresenter having 2, 3 >>>>>>>>>> or 4 >>>>>>>>>> radioButton. >>>>>>>>>> >>>>>>>>>> Stef >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Le 17/5/16 Ã 18:52, Johan Fabry a Ã©crit : >>>>>>>>>> >>>>>>>>>> Hi Marion, >>>>>>>>>>> >>>>>>>>>>> the class side message of defaultSpec is generally meant to be >>>>>>>>>>> used if >>>>>>>>>>> you use a fixed number of widgets, so you can put the reference to >>>>>>>>>>> the >>>>>>>>>>> name of each widget there (in cour case #buttons). For variable >>>>>>>>>>> number >>>>>>>>>>> of widgets you should have a look at the dynamic features of Spec. >>>>>>>>>>> >>>>>>>>>>> That being said, It looks like what you really want to use is a >>>>>>>>>>> Radio >>>>>>>>>>> Button Group. Have a look at RadioButtonGroupExample. >>>>>>>>>>> >>>>>>>>>>> HTH >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Does this mail seem too brief? Sorry for that, I donât mean to be >>>>>>>>>>> rude! Please see http://emailcharter.org . >>>>>>>>>>> >>>>>>>>>>> Johan Fabry - http://pleiad.cl/~jfabry >>>>>>>>>>> PLEIAD and RyCh labs - Computer Science Department (DCC) - >>>>>>>>>>> University of Chile >>>>>>>>>>> >>>>>>>>>>> On May 17, 2016, at 13:48, Marion Noirbent >>>>>>>>>>> >>>>>>>>>>>> <ms.noirbent(a)etudiant.univ-lille1.fr> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> I'm trying to create a widget whith Spec, managing a collection >>>>>>>>>>>> of >>>>>>>>>>>> RadioButton. But I have a problem with defaultSpec (the accessor >>>>>>>>>>>> of >>>>>>>>>>>> the collection is the methods "buttons") : >>>>>>>>>>>> >>>>>>>>>>>> If i put defaultSpec on class side, i can't acces the collection >>>>>>>>>>>> of >>>>>>>>>>>> the instance. (the following code iterate on the string) >>>>>>>>>>>> >>>>>>>>>>>> defaultSpec >>>>>>>>>>>> <spec: #default> >>>>>>>>>>>> ^ SpecLayout composed >>>>>>>>>>>> newColumn: [ :column | #buttons do: [ :item | column >>>>>>>>>>>> add: >>>>>>>>>>>> item ] ]; >>>>>>>>>>>> yourself >>>>>>>>>>>> >>>>>>>>>>>> If i put it on instance side, the lookup don't find it (in the >>>>>>>>>>>> book >>>>>>>>>>>> Building UI with Spec, it said the lookup begin by the instance >>>>>>>>>>>> side >>>>>>>>>>>> and it allow to have specific UI, in part about layout) >>>>>>>>>>>> >>>>>>>>>>>> defaultSpec >>>>>>>>>>>> <spec: #default> >>>>>>>>>>>> ^ SpecLayout composed >>>>>>>>>>>> newColumn: [ :column | self buttons do: [ :item | column >>>>>>>>>>>> add: >>>>>>>>>>>> item ] ]; >>>>>>>>>>>> yourself >>>>>>>>>>>> >>>>>>>>>>>> Any idea ? >>>>>>>>>>>> >>>>>>>>>>>> Marion Noirbent, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> -- >> Ma clÃ© publique sur pgp.mit.edu >> >> > -- Ma clÃ© publique sur pgp.mit.edu

May 20, 2016

DSLDI'16: Call for Talk Proposals

by Tijs van der Storm

********************************************************************* CALL FOR TALK PROPOSALS DSLDI 2016 Fourth Workshop on Domain-Specific Language Design and Implementation October 31, 2016 Amsterdam, Netherlands Co-located with SPLASH http://2016.splashcon.org/track/dsldi2016 https://twitter.com/wsdsldi ********************************************************************* Deadline for talk proposals: August 1, 2016 *** Workshop Goal *** Well-designed and implemented domain-specific languages (DSLs) can achieve both usability and performance benefits over general-purpose programming languages. By raising the level of abstraction and exploiting domain knowledge, DSLs can make programming more accessible, increase programmer productivity, and support domain-specific optimizations. The goal of the DSLDI workshop is to bring together researchers and practitioners interested in discussing how DSLs should be designed, implemented, supported by tools, and applied in realistic contexts. The focus of the workshop is on all aspects of this process, from soliciting domain knowledge from experts, through the design and implementation of the language, to evaluating whether and how a DSL is successful. More generally, we are interested in continuing to build a community that can drive forward the development of modern DSLs. An additional goal of this year's workshop is to encourage discussion about the usability of DSLs, and to establish connections with researchers in related areas, such as end-user software engineering, who have studied human factors of programming languages and tools. *** Workshop Format *** DSLDI is a single-day workshop and will consist of moderated audience discussions structured around a series of talks. The role of the talks is to facilitate interesting and substantive discussion. Therefore, we welcome and encourage talks that express strong opinions, describe open problems, propose new research directions, and report on early research in progress. Proposed talks should be on topics within DSLDI's area of interest, which include but are not limited to: * solicitation and representation of domain knowledge * DSL design principles and processes * DSL implementation techniques and language workbenches * domain-specific optimizations * human factors of DSLs * tool support for DSL users * community and educational support for DSL users * applications of DSLs to existing and emerging domains * studies of usability, performance, or other benefits of DSLs * experience reports of DSLs deployed in practice *** Call for Submissions *** We solicit talk proposals in the form of short abstracts (max. 2 pages). A good talk proposal describes an interesting position, open problem, demonstration, or early achievement. The submissions will be reviewed on relevance and clarity, and used to plan the mostly interactive sessions of the workshop day. Publication of accepted abstracts and slides on the website is voluntary. * Deadline for talk proposals: August 1, 2016 * Notification: September 5, 2016 * Workshop: October 31, 2016 * Submission website: https://dsldi16.hotcrp.com/ *** Workshop Organization *** Organizers: * Eric Walkingshaw (Oregon State University) * Tijs van der Storm (CWI) Program committee: * Iman Avazpour (Deakin University) * Christopher Bogart (Carnegie Mellon University) * Andy Gill (University of Kansas) * Sylvia Grewe (TU Darmstadt) * Kate Howland (University of Sussex) * Lindsey Kuper (Intel Labs) * Darya Kurilova (Carnegie Mellon University) * Ralf LÃ¤mmel (University of Koblenz-Landau) * Tanja Mayerhofer (Vienna University of Technology) * Marjan Mernik (University of Maribor) * Sarah Mount (King's College London) * Justin Pombrio (Brown University) * Tillmann Rendel (University of TÃ¼bingen) * Tiark Rompf (Purdue & Oracle Labs) * Sonja Schimmler (Bundeswehr University Munich) * Markus VÃ¶lter (itemis) * Peng Wu (Huawei America Lab)

May 20, 2016

Re: [Pharo-users] Why is split: implemented in the separator rather than the string?

by John Pfersich

If you want to do it reversed, do it like this: '1969-07-20' splitOn: '-' > On May 19, 2016, at 11:48, Andy Burnett <andy.burnett(a)knowinnovation.com> wrote: > > I keep getting this wrong, which makes me wonder why we send split: to the separator rather than the thing to be split. Is there a benefit to doing > > $- split: '1969-07-20' > > rather than > > '1969-07-20' split: $- (which somehow seems more natural to me). > > Cheers > Andy

May 20, 2016

Re: [Pharo-users] [Pharo-dev] Scrollable Spec Model

by Peter UhnÃ¡k

Oh, rightâ¦ I didn't realize I can do that. :) Thanks, Peter On Thu, May 19, 2016 at 11:43 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > You can use a ListModel and put your Buttons in it. > > ListModel new > items: ( 'Files' asPackage classes collect:[:c | ButtonModel new icon: > c systemIcon; label: c name; action:[ UIManager default alert: c comment > title: c name]]); > displayBlock: [ :x | x buildWithSpec ]; > openWithSpec > > > > 2016-05-18 17:55 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> Hi, >> >> anyone has any experience with scrollable (arbitrary) Spec Model? >> >> e.g. I have a long list of buttons and fixed outer container windowâ¦ >> >> >> â >> As far as I can see scrolling is only available on morphic side, so I am >> not sure how to augment itâ¦ (Although we should probably allow scrolling on >> Spec side in some way) >> >> Thanks, >> Peter >> > >

May 19, 2016

Re: [Pharo-users] Spec layout

by Peter UhnÃ¡k

Hi, I've made a simple example â see attached fileout. Couple things to note: 1. > If i put it on instance side, the lookup don't find it (in the book Building UI with Spec, it said the lookup begin by the instance side and it allow to have specific UI, in part about layout) As far as I know / as far as I can tell this is false for ComposableModel. For DynamicComposableModel you can override the method "#layout". 2. For some odd reason when you add a new radio button it looks like a checkbox and only once you click on it it turns into a checkboxâ¦ which is WTF but it shouldn't matter atm 3. DynamicComposableModel holds the item in a Dictionary, since you can't provide accessors for each item, you have to cobble together some other selector, as shown in createWidgets 4. I don't know if this is the best approach, but I've been using something like this for quite a while I'm quite busy this week, however I scheduled to take a look at the Spec book next week as I should probably write something thereâ¦ So if you have any more questions/comments please ask. Peter On Wed, May 18, 2016 at 2:19 PM, Marion Noirbent < ms.noirbent(a)etudiant.univ-lille1.fr> wrote: > Ok, I wait your answer. > Thanks for your help. > Marion, > > > Le 18/05/2016 12:04, Peter UhnÃ¡k a Ã©crit : > >> Yes but someone must call rebuildWidgetâ¦ I will try to take a look at this >> today and give a better/more comprehensive example. >> >> Peter >> >> On Wed, May 18, 2016 at 1:01 PM, stepharo <stepharo(a)free.fr> wrote: >> >> I do not get it. >>> >>> I still think that the solution of peter is the one to implement >>> >>> rebuildWidget >>> self widgets removeAll. >>> self createWidgets. >>> self needFullRebuild: false. >>> self buildWithSpecLayout: self dynamicLayout. >>> self alignButtons >>> >>> >>> dynamicLayout >>> | keys | >>> keys := self widgets keys. >>> ^ SpecLayout composed >>> newColumn: [ :c | >>> keys do: [ :key | c newRow: key height: self class >>> buttonHeight ]. >>> c newRow: [ :r | ] ]; >>> yourself >>> >>> >>> >>> Le 18/5/16 Ã 12:46, Marion Noirbent a Ã©crit : >>> >>> Because I would use "openWithSpec" to build only when the widget is >>> ready, >>> >>>> but it call a method (with the good pragma) on the class side. >>>> >>>> In the example i use i have add RadioButtonModel with addRadioButton: in >>>> the collection buttons, it's not empty but RadioButtonModel is a >>>> ComposableModel and layout: is define in the subclass >>>> DynamicComposableModel . >>>> >>>> Le 18/05/2016 10:22, stepharo a Ã©crit : >>>> >>>> But why from the class side. >>>>> >>>>> buttons >>>>> ^ buttons >>>>> >>>>> returns an empty collection >>>>> >>>>> and >>>>> >>>>> rebuildWidget >>>>> self widgets removeAll. >>>>> self createWidgets. >>>>> self needFullRebuild: false. >>>>> self buildWithSpecLayout: self dynamicLayout. >>>>> self alignButtons >>>>> >>>>> >>>>> >>>>> Le 18/5/16 Ã 11:31, Marion Noirbent a Ã©crit : >>>>> >>>>> I was trying to use it but i have still the problem to call the >>>>>> instance method from the class side, so i call the >>>>>> buildWithSpecLayout: in the method to add buttons in the collection, >>>>>> it seems work but i have an "MessageNotUnderstood" >>>>>> RadioButton>>layout: >>>>>> >>>>>> Le 18/05/2016 09:20, stepharo a Ã©crit : >>>>>> >>>>>> marion the solution is what peter proposes. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> Le 18/5/16 Ã 11:14, Marion Noirbent a Ã©crit : >>>>>>> >>>>>>> In fact i was trying to modify RadioButtonGroup to turn it into a >>>>>>>> widget, #buttons is not a widget but its collection of widget. >>>>>>>> >>>>>>>> May you have confused RadioButtonGroup with the MenuModel / >>>>>>>> MenuGroupModel / MenuItemModel which are widgets. I take inspiration >>>>>>>> from them and I would got the same kind of behaviour. >>>>>>>> >>>>>>>> Le 17/05/2016 21:11, stepharo a Ã©crit : >>>>>>>> >>>>>>>> Thanks Johan >>>>>>>>> >>>>>>>>> >>>>>>>>> We looked at >>>>>>>>> >>>>>>>>> RadioButtonGroupExample >>>>>>>>> >>>>>>>>> but you see we cannot have a RadioButtonGroupPresenter having 2, 3 >>>>>>>>> or 4 >>>>>>>>> radioButton. >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 17/5/16 Ã 18:52, Johan Fabry a Ã©crit : >>>>>>>>> >>>>>>>>> Hi Marion, >>>>>>>>>> >>>>>>>>>> the class side message of defaultSpec is generally meant to be >>>>>>>>>> used if >>>>>>>>>> you use a fixed number of widgets, so you can put the reference to >>>>>>>>>> the >>>>>>>>>> name of each widget there (in cour case #buttons). For variable >>>>>>>>>> number >>>>>>>>>> of widgets you should have a look at the dynamic features of Spec. >>>>>>>>>> >>>>>>>>>> That being said, It looks like what you really want to use is a >>>>>>>>>> Radio >>>>>>>>>> Button Group. Have a look at RadioButtonGroupExample. >>>>>>>>>> >>>>>>>>>> HTH >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Does this mail seem too brief? Sorry for that, I donât mean to be >>>>>>>>>> rude! Please see http://emailcharter.org . >>>>>>>>>> >>>>>>>>>> Johan Fabry - http://pleiad.cl/~jfabry >>>>>>>>>> PLEIAD and RyCh labs - Computer Science Department (DCC) - >>>>>>>>>> University of Chile >>>>>>>>>> >>>>>>>>>> On May 17, 2016, at 13:48, Marion Noirbent >>>>>>>>>> >>>>>>>>>>> <ms.noirbent(a)etudiant.univ-lille1.fr> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> I'm trying to create a widget whith Spec, managing a collection >>>>>>>>>>> of >>>>>>>>>>> RadioButton. But I have a problem with defaultSpec (the accessor >>>>>>>>>>> of >>>>>>>>>>> the collection is the methods "buttons") : >>>>>>>>>>> >>>>>>>>>>> If i put defaultSpec on class side, i can't acces the collection >>>>>>>>>>> of >>>>>>>>>>> the instance. (the following code iterate on the string) >>>>>>>>>>> >>>>>>>>>>> defaultSpec >>>>>>>>>>> <spec: #default> >>>>>>>>>>> ^ SpecLayout composed >>>>>>>>>>> newColumn: [ :column | #buttons do: [ :item | column >>>>>>>>>>> add: >>>>>>>>>>> item ] ]; >>>>>>>>>>> yourself >>>>>>>>>>> >>>>>>>>>>> If i put it on instance side, the lookup don't find it (in the >>>>>>>>>>> book >>>>>>>>>>> Building UI with Spec, it said the lookup begin by the instance >>>>>>>>>>> side >>>>>>>>>>> and it allow to have specific UI, in part about layout) >>>>>>>>>>> >>>>>>>>>>> defaultSpec >>>>>>>>>>> <spec: #default> >>>>>>>>>>> ^ SpecLayout composed >>>>>>>>>>> newColumn: [ :column | self buttons do: [ :item | column >>>>>>>>>>> add: >>>>>>>>>>> item ] ]; >>>>>>>>>>> yourself >>>>>>>>>>> >>>>>>>>>>> Any idea ? >>>>>>>>>>> >>>>>>>>>>> Marion Noirbent, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > -- > Ma clÃ© publique sur pgp.mit.edu > >

May 19, 2016

Re: [Pharo-users] [Pharo-dev] Scrollable Spec Model

by Nicolai Hess

You can use a ListModel and put your Buttons in it. ListModel new items: ( 'Files' asPackage classes collect:[:c | ButtonModel new icon: c systemIcon; label: c name; action:[ UIManager default alert: c comment title: c name]]); displayBlock: [ :x | x buildWithSpec ]; openWithSpec 2016-05-18 17:55 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Hi, > > anyone has any experience with scrollable (arbitrary) Spec Model? > > e.g. I have a long list of buttons and fixed outer container windowâ¦ > > > â > As far as I can see scrolling is only available on morphic side, so I am > not sure how to augment itâ¦ (Although we should probably allow scrolling on > Spec side in some way) > > Thanks, > Peter >

May 19, 2016