February 2015 - Pharo-dev - lists.pharo.org

CI Server still down...

by Marcus Denker

Hi, CI Servers are still down. Until they are up we can not do any integration nor run the automatic check on submitted things. Marcus

Feb. 20, 2015

Re: [Pharo-dev] [FIX]: Issue 4795: Horizontal wheel

by Craig Latta

> Bueller? I think the devs here are perhaps *slightly* more busy than the drooling teenagers in that scene... :) -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Feb. 20, 2015

Re: [Pharo-dev] Spec terminology: renaming some terms

by Henrik Johansen

> On 20 Feb 2015, at 12:23 , Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-02-19 23:24 GMT+01:00 Johan Fabry <jfabry(a)dcc.uchile.cl <mailto:jfabry@dcc.uchile.cl>>: > > The problem is that people are confused by the term Model, so they will also be confused by Logic. I want to remove the confusion and make clear that it is a user interface (and that it is composable by default) -> ComposableUI. > > It could also be ComposableUserInterface but we do not win anything by that name, as UI is a standard acronym + we would have to type more when subclassing it. So I prefer ComposableUI. > > But this *is* a model, not a UI. Yes a model for the UI, but still, the real UI-View is what comes through the Spec interpreter. > "UI" sounds like "the whole user interface", but Specs ComposableModels are meant as "building blocks". > > > UI-Model -> WidgetAdapter -> Widget/View. > > I would prefer (in this order): > 1. ComposableModel (because this is the current name) > 2. ComposableWidgetModel (widget: a brick or part of an UI) > 3. ComposableUIModel > 4. ComposableUI > > I am not fully against 4., because it is the goal of spec to build reuseable UIs. > For example for a Spec based "ListSelectionDialog" we can reuse the whole component, not only the model, not only the view, but the > whole component with interaction between the list and other controls. > But I would prefer ComposableWidgetModel, because a "Widget" (button/textfield/list) is the smallest unit of a user interface representable with Spec. If the goal is avoiding confusion to data model classes, why not just use Spec in place of Model? It reflects the framework name, and is fairly descriptive in that the classes are neither the actual widgets, nor the models that hold data, but a specification of how they are composed and wired together. Cheers, Henry

Feb. 20, 2015

Re: [Pharo-dev] untypeable key combination

by Marcus Denker

> On 19 Feb 2015, at 10:19, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Fogbugz issue 14936 > and slice in inbox > > After loading this slice, there are still many references to the (now) obsolete class KMUntypeableSingleKeyCombination. > I tried to remove these references with the following code : > > NECPreferences popupShowWithShortcut: nil. > KMSingleKeyCombination reset. > KMSpecialCharSingleKeyCombination reset. > KMRepository reset. > > > But they arent removed. > > Anyone knows how to re-init all users of KMUntypeableSingleKeyCombination ? > > Very strangeâ¦ using âexplore pointersâ with the old inspector, it shows lots of instancesâ¦ I sadly have no time to now look deeper, but the pointer explorer should be a way to find who holds onto themâ¦ Marcus

Feb. 20, 2015

Re: [Pharo-dev] Spec terminology: renaming some terms

by Peter UhnÃ¡k

> > However, reflecting all of this in the name, ComposableModel, makes it > unclear what it is for. > >From "Seamless Composition and Reuse of Customizable User Interfaces with Spec" ( http://rmod.lille.inria.fr/archives/papers/Ryse13a-SCICO-Spec.pdf ) UI Element: an interactive graphical element displayed as part of the Graphical User Interface. UI Model: an object that contains the state and behavior of one or several UI elements. Widget: the union of a UI Element and its UI model. My understanding was that Element is Morphic, Model is Spec and Widget is an adapter? -- But in the end once you start using it you know what to look for (= 10 minutes after reading tutorial) does it really make that much difference? It is just a subclass. >From my point having clean and well organized protocols is more important, because you will end up interacting with those order of magnitude more, and if there is method in unexpected protocol... well then I might as well use --show all protocols--. Also whenXYChanged methods are not so nice (those have been mentioned previously).

Feb. 20, 2015

Re: [Pharo-dev] Athens/Morphic

by Marcus Denker

Very nice! Works here (on Mac). I will integrate as soon as the CI is up againâ¦ Marcus > On 19 Feb 2015, at 12:44, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 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 <mailto:alain.plantec@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. 20, 2015

Re: [Pharo-dev] Spec terminology: renaming some terms

by Johan Fabry

Well, yes, I know what it is, I know about the building block idea behind it, and I know about the reusability. However, reflecting all of this in the name, ComposableModel, makes it unclear what it is for. This is what I got as feedback of people: they did not even understand that this is what you subclass to define your UI. So apparently this is confusing and not the way to go. Using âWidgetâ in the name is not really a good idea either, because then people will think that it is for parts of an UI only, not complete UIâs. Thatâs more confusion. > On Feb 19, 2015, at 20:23, Nicolai Hess <nicolaihess(a)web.de> wrote: > > But this *is* a model, not a UI. Yes a model for the UI, but still, the real UI-View is what comes through the Spec interpreter. > "UI" sounds like "the whole user interface", but Specs ComposableModels are meant as "building blocks". > > > UI-Model -> WidgetAdapter -> Widget/View. > > I would prefer (in this order): > 1. ComposableModel (because this is the current name) > 2. ComposableWidgetModel (widget: a brick or part of an UI) > 3. ComposableUIModel > 4. ComposableUI > > I am not fully against 4., because it is the goal of spec to build reuseable UIs. > For example for a Spec based "ListSelectionDialog" we can reuse the whole component, not only the model, not only the view, but the > whole component with interaction between the list and other controls. > But I would prefer ComposableWidgetModel, because a "Widget" (button/textfield/list) is the smallest unit of a user interface representable with Spec. ---> 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] Spec terminology: renaming some terms

by Nicolai Hess

2015-02-19 23:24 GMT+01:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: > > The problem is that people are confused by the term Model, so they will > also be confused by Logic. I want to remove the confusion and make clear > that it is a user interface (and that it is composable by default) -> > ComposableUI. > > It could also be ComposableUserInterface but we do not win anything by > that name, as UI is a standard acronym + we would have to type more when > subclassing it. So I prefer ComposableUI. > But this *is* a model, not a UI. Yes a model for the UI, but still, the real UI-View is what comes through the Spec interpreter. "UI" sounds like "the whole user interface", but Specs ComposableModels are meant as "building blocks". UI-Model -> WidgetAdapter -> Widget/View. I would prefer (in this order): 1. ComposableModel (because this is the current name) 2. ComposableWidgetModel (widget: a brick or part of an UI) 3. ComposableUIModel 4. ComposableUI I am not fully against 4., because it is the goal of spec to build reuseable UIs. For example for a Spec based "ListSelectionDialog" we can reuse the whole component, not only the model, not only the view, but the whole component with interaction between the list and other controls. But I would prefer ComposableWidgetModel, because a "Widget" (button/textfield/list) is the smallest unit of a user interface representable with Spec. nicolai > > > On Feb 19, 2015, at 14:37, stepharo <stepharo(a)free.fr> wrote: > > > > I know :) > > So may be Logic because this is the logic of the application. > > > > Stef > > Le 19/2/15 18:16, Sven Van Caekenberghe a Ã©crit : > >> Well, it means User Interface ;-) > >> > >> The thing that got everybody confused is precisely the word Model, if > we keep that the confusion will continue. > >> > >>> On 19 Feb 2015, at 18:11, stepharo <stepharo(a)free.fr> wrote: > >>> > >>> Hi Johan > >>> > >>> For me UI does not mean anything. > >>> So may be ComposableUIModel? > >>> Or ComposableUILogic > >>> > >>> > >>> Stef > >>> > >>> Le 19/2/15 13:22, Johan Fabry a Ã©crit : > >>>> 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 > >>>> > >>>> > >>>> > >>> > >> > >> > > > > > > > > > > ---> 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] Spec terminology: renaming some terms

by nacho

Or you can define a new standard by renaming it ComposableSpec ;) ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Spec-terminology-renaming-some-terms-tp4806486p480657… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 19, 2015

Re: [Pharo-dev] Spec terminology: renaming some terms

by Johan Fabry

The problem is that people are confused by the term Model, so they will also be confused by Logic. I want to remove the confusion and make clear that it is a user interface (and that it is composable by default) -> ComposableUI. It could also be ComposableUserInterface but we do not win anything by that name, as UI is a standard acronym + we would have to type more when subclassing it. So I prefer ComposableUI. > On Feb 19, 2015, at 14:37, stepharo <stepharo(a)free.fr> wrote: > > I know :) > So may be Logic because this is the logic of the application. > > Stef > Le 19/2/15 18:16, Sven Van Caekenberghe a Ã©crit : >> Well, it means User Interface ;-) >> >> The thing that got everybody confused is precisely the word Model, if we keep that the confusion will continue. >> >>> On 19 Feb 2015, at 18:11, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi Johan >>> >>> For me UI does not mean anything. >>> So may be ComposableUIModel? >>> Or ComposableUILogic >>> >>> >>> Stef >>> >>> Le 19/2/15 13:22, Johan Fabry a Ã©crit : >>>> 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 >>>> >>>> >>>> >>> >> >> > > > ---> 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