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

Re: [Pharo-dev] about theme and friends

by Benjamin

Ok, my bad :) This is a massive refactoring, but indeed, it may be cool :) Ben On May 14, 2013, at 5:18 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > On May 14, 2013, at 5:13 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> The problem is the overlapping. >> For settings, different project do not define the same settings. >> >> But for tools, it's different >> By example, Browser, and Nautilus will try to register to default browser. > > I'm not talking about this level. > No registration about tools. UITheme does not deal with that. > > The current theme should push to all the widgets that the defaultColor is blue. > > > >> >> Ben >> >> On May 14, 2013, at 4:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> esteban >>> >>> I discussed with damien and I think that now I got the solution. In fact the architecture should be the same than the >>> one of settings. >>> >>> Every widget should have custom hooks and setter, getter and default values. >>> The hooks should be annotated or registered seomwhere. >>> Then the widget code simply uses the hooks normally. >>> >>> Now a theme changes should push new values onto these hooks. >>> >>> This will lead to a flow that is totally different. Nobody should write UITheme builder or even Smalltalk ui theme. >>> I will try to build a small experiment but I'm sure that this is the solution >>> >>> Nobody call settings nowadays (as it was the case with Preferences in the past). >>> >>> Stef >> >

May 14, 2013

Killing respondsTo:

by StÃ©phane Ducasse

Hi I'm in favor killing all the respondsTo: acceptTextMorphs "Accept any text morphs except for those that have no edits." self allMorphs do: [:p | ((p respondsTo: #accept) and: [ (p respondsTo: #hasUnacceptedEdits) and: [ p hasUnacceptedEdits]]) ifTrue: [p accept]] :) And there are too many Smalltalk references in the system

May 14, 2013

Re: [Pharo-dev] about theme and friends

by stephane ducasse

On May 14, 2013, at 5:13 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > The problem is the overlapping. > For settings, different project do not define the same settings. > > But for tools, it's different > By example, Browser, and Nautilus will try to register to default browser. I'm not talking about this level. No registration about tools. UITheme does not deal with that. The current theme should push to all the widgets that the defaultColor is blue. > > Ben > > On May 14, 2013, at 4:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> esteban >> >> I discussed with damien and I think that now I got the solution. In fact the architecture should be the same than the >> one of settings. >> >> Every widget should have custom hooks and setter, getter and default values. >> The hooks should be annotated or registered seomwhere. >> Then the widget code simply uses the hooks normally. >> >> Now a theme changes should push new values onto these hooks. >> >> This will lead to a flow that is totally different. Nobody should write UITheme builder or even Smalltalk ui theme. >> I will try to build a small experiment but I'm sure that this is the solution >> >> Nobody call settings nowadays (as it was the case with Preferences in the past). >> >> Stef >

May 14, 2013

Re: [Pharo-dev] about theme and friends

by Benjamin

The problem is the overlapping. For settings, different project do not define the same settings. But for tools, it's different By example, Browser, and Nautilus will try to register to default browser. Ben On May 14, 2013, at 4:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > esteban > > I discussed with damien and I think that now I got the solution. In fact the architecture should be the same than the > one of settings. > > Every widget should have custom hooks and setter, getter and default values. > The hooks should be annotated or registered seomwhere. > Then the widget code simply uses the hooks normally. > > Now a theme changes should push new values onto these hooks. > > This will lead to a flow that is totally different. Nobody should write UITheme builder or even Smalltalk ui theme. > I will try to build a small experiment but I'm sure that this is the solution > > Nobody call settings nowadays (as it was the case with Preferences in the past). > > Stef

May 14, 2013

about theme and friends

by StÃ©phane Ducasse

esteban I discussed with damien and I think that now I got the solution. In fact the architecture should be the same than the one of settings. Every widget should have custom hooks and setter, getter and default values. The hooks should be annotated or registered seomwhere. Then the widget code simply uses the hooks normally. Now a theme changes should push new values onto these hooks. This will lead to a flow that is totally different. Nobody should write UITheme builder or even Smalltalk ui theme. I will try to build a small experiment but I'm sure that this is the solution Nobody call settings nowadays (as it was the case with Preferences in the past). Stef

May 14, 2013

[3.0][Opal] Compiler Options!

by Marcus Denker

In 3.0, when using the new Compiler, there is now a new way to set options that the compile chain can act on (Opal takes care to hand them through all the stages). For now, the there are two cases where we use options: controlling inlining and to generate long ivar access bytecodes even when short ones would be enough: defaultOptions ^ #( "by default we inline all optimized constructs" + optInlineIf + optInlineIfNil + optInlineAndOr + optInlineWhile + optInlineToDo + optInlineCase - optIlineNone "to turn off all. Overrides the others" - optLongIvarAccessBytecodes "special for Contexts" ) There are two ways to set compiler options. One is per Class Hierarchy. For example, in InstructionStream class, there is this method: compiler ^super compiler options: #(+ optLongIvarAccessBytecodes) The other way to use it is with a pragma: test <compilerOptions: #(-optInlineIf)> ^1 < 2 ifTrue: [ 'Hello!' ] The options API idea is taken from NativeBoost: #( + option1 option2 - option3 ... ) each time the #+ is seen, the options which follow it will be subject for inclusion and, correspondingly, if #- seen, then they will be excluded. By default, (if none of #+ or #- specified initially), all options are subject for inclusion. Like NativeBoost it uses #doesNotUnderstand, so e.g. if you want to have a flag for your own Compiler Plugin, just set it and query the compilationContext by sending the flag symbol as a message. Next: AST Transformation Pluginsâ¦ ready later this week. Marcus

May 14, 2013

Re: [Pharo-dev] [Pharo-users] the future of squeaksource

by Andrei Vasile Chis

Only the projects that have public read access will be made available. Cheers, Andei On Tue, May 14, 2013 at 3:13 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I think the license is important. > > Please also take into account that some projects are private, thus, they > should not be made public during this move. > > Cheers, > Doru > > > > On Tue, May 14, 2013 at 2:41 PM, Andrei Vasile Chis < > chisvasileandrei(a)gmail.com> wrote: > >> Hi, >> >> So SqueakSource will remain like it's now until 15 July 2013. Afterward >> we'll replace it with a simple view exposing just the file system. >> This view will only contain projects that are globally visible. I've >> updated the front page with this news and the migration script to smalltalk >> hub. >> >> Now a question. If we replace squeak source with a view of the file >> system all meta information won't be accessible any more. This also >> includes the >> license of the projects. Do you think it makes sense to extract this >> information and put it next to the projects? Also is there any other meta >> information >> that would be useful to have? >> >> >> Cheers, >> Andrei >> >> >> >> On Thu, May 9, 2013 at 10:22 AM, Hilaire Fernandes < >> hilaire.fernandes(a)gmail.com> wrote: >> >>> Le 08/05/2013 18:08, Andrei Vasile Chis a Ã©crit : >>> > Thanks. I will add this script to the front page of SqueakSource. >>> > >>> >>> Thanks. >>> >>> Hilaire >>> >>> -- >>> Dr. Geo http://drgeo.eu >>> >>> >>> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

May 14, 2013

Re: [Pharo-dev] success story: NTed

by Nicolas Petton

I do have one question: what was your experience with Amber? Nico On May 14, 2013, at 11:37 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > I think my last post of this message fell into the time the old mailing list dies. So here it is again > > --- > > We (@2denker in cooperation with a local university) built a monitoring tool for disaster scenario recovery rehearsals. Several times a year universities, red cross, THW und hospitals are planning a rehearsal together. For this an environment is prepared for a simulated disaster (car accidents, explosions in civil areas, â¦). The local environment is prepared to look real as well as film make-up artist prepare people for injuries (broken legs, open head, â¦). > The rehearsal should improve the coordination of several hospitals, firemenâ¦as well as the quickest possible treatment for the injured. > > One important part of the rehearsal is monitoring of what happens. This is achieved by installing a local position system and using our tool. Every injured person gets a wireless tablet. On the tablet there are UI elements that indicate treatment done to them. Whenever a doctor comes visiting the injured person activates the corresponding UI button. The events are transmitted to a server and are prepared for another analysis software. The tablet enables the HQ to make contact to individual persons or groups. The tablet measures times of needed treatments and instructs the injured to be dead if measurements weren't taken in time. > > Technically it is done in smalltalk solo. > > The server is a pharo image. It has > > - web admin interface with complex forms for managing injuries, injured, groups, etc. For this we used seaside because it is best suited for this job. Forms are done with magritte, magritte-bootstrap. The interface also displays the live incoming events and other data > - a static file server that delivers static resources to client tablets > - a websocket connector that is used by the clients to connect to the server > - a http handler to export data to other analysis tools > > The client is done with amber smalltalk. It > > - loads the web page containing amber from the server > - connects back to the server > - downloads a UI spec for the injured using the tablet to display personalized UI elements > - stores events on the tablet in case the injured is offline > - measures times to instruct the injured > > If you have any questions please don't hesitate to ask. > > Norbert -- Nicolas Petton http://www.nicolas-petton.fr

May 14, 2013

Re: [Pharo-dev] [Pharo-users] success story: NTed

by Alexandre Bergel

Glad to see this! We all benefit from such experience! Alexandre On May 14, 2013, at 6:15 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > Good idea. I need to collect them first from mobile devices and other systems. Until then here are some of the admin interface (it's all in german) > > <Bildschirmfoto 2013-05-14 um 11.58.57.jpeg> > > <Bildschirmfoto 2013-05-14 um 11.58.26.jpg> > > <Bildschirmfoto 2013-05-14 um 11.57.53.jpg> > > <Bildschirmfoto 2013-05-14 um 11.59.38.jpeg> > > Norbert > > Am 14.05.2013 um 11:43 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> Great success story, Norbert, it is really good to hear it ! >> >> One request though: sexy screenshots ;-) >> >> Sven >> >> On 14 May 2013, at 11:37, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> I think my last post of this message fell into the time the old mailing list dies. So here it is again >>> >>> --- >>> >>> We (@2denker in cooperation with a local university) built a monitoring tool for disaster scenario recovery rehearsals. Several times a year universities, red cross, THW und hospitals are planning a rehearsal together. For this an environment is prepared for a simulated disaster (car accidents, explosions in civil areas, â¦). The local environment is prepared to look real as well as film make-up artist prepare people for injuries (broken legs, open head, â¦). >>> The rehearsal should improve the coordination of several hospitals, firemenâ¦as well as the quickest possible treatment for the injured. >>> >>> One important part of the rehearsal is monitoring of what happens. This is achieved by installing a local position system and using our tool. Every injured person gets a wireless tablet. On the tablet there are UI elements that indicate treatment done to them. Whenever a doctor comes visiting the injured person activates the corresponding UI button. The events are transmitted to a server and are prepared for another analysis software. The tablet enables the HQ to make contact to individual persons or groups. The tablet measures times of needed treatments and instructs the injured to be dead if measurements weren't taken in time. >>> >>> Technically it is done in smalltalk solo. >>> >>> The server is a pharo image. It has >>> >>> - web admin interface with complex forms for managing injuries, injured, groups, etc. For this we used seaside because it is best suited for this job. Forms are done with magritte, magritte-bootstrap. The interface also displays the live incoming events and other data >>> - a static file server that delivers static resources to client tablets >>> - a websocket connector that is used by the clients to connect to the server >>> - a http handler to export data to other analysis tools >>> >>> The client is done with amber smalltalk. It >>> >>> - loads the web page containing amber from the server >>> - connects back to the server >>> - downloads a UI spec for the injured using the tablet to display personalized UI elements >>> - stores events on the tablet in case the injured is offline >>> - measures times to instruct the injured >>> >>> If you have any questions please don't hesitate to ask. >>> >>> Norbert >> >> >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 14, 2013

Re: [Pharo-dev] [Pharo-users] the future of squeaksource

by Tudor Girba

I think the license is important. Please also take into account that some projects are private, thus, they should not be made public during this move. Cheers, Doru On Tue, May 14, 2013 at 2:41 PM, Andrei Vasile Chis < chisvasileandrei(a)gmail.com> wrote: > Hi, > > So SqueakSource will remain like it's now until 15 July 2013. Afterward > we'll replace it with a simple view exposing just the file system. > This view will only contain projects that are globally visible. I've > updated the front page with this news and the migration script to smalltalk > hub. > > Now a question. If we replace squeak source with a view of the file system > all meta information won't be accessible any more. This also includes the > license of the projects. Do you think it makes sense to extract this > information and put it next to the projects? Also is there any other meta > information > that would be useful to have? > > > Cheers, > Andrei > > > > On Thu, May 9, 2013 at 10:22 AM, Hilaire Fernandes < > hilaire.fernandes(a)gmail.com> wrote: > >> Le 08/05/2013 18:08, Andrei Vasile Chis a Ã©crit : >> > Thanks. I will add this script to the front page of SqueakSource. >> > >> >> Thanks. >> >> Hilaire >> >> -- >> Dr. Geo http://drgeo.eu >> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

May 14, 2013