January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Glamour vs Spec (was: towards moose in the pharo ide (gtinspector / gtdebugger))

by Tudor Girba

Hi, On Wed, Jan 1, 2014 at 3:59 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On 01 Jan 2014, at 15:02, Stephan Eggermont <stephan(a)stack.nl> wrote: > > > The point I apparently failed to make is that I miss the abstraction > above the widget level. > > With Spec you have the same as in VisualWorks. You have applicationModel and you specify the logic that you can reuse > with plain Smalltalk. Glamour does it with a component model, event and a DSL full of blocks. > Interesting comparison. It sounds to me as if this "component model" is a bad thing and that VW is a gold standard when it comes to describing user interfaces. Also, when you say DSL you refer to the way the Smalltalk API was design to read like sentences, which might sound like it goes against the tradition of Smalltalk. As for blocks, some would go as far as considering them to be plain Smalltalk :). I think a more detailed comparison would be more useful for newcomers. So, here is one. First, the block issue. The funny thing is that if you want to build a dynamic browser with Spec you have to rely on blocks, too. Take a look at an example from Ben: --- m := DynamicComposableModel new. m instantiateModels: #( button ButtonModel list ListModel). m list items: #(1 2 3 4 5). m button label: 'Plip'; action: [ self halt ]. m openWithSpecLayout: (SpecLayout composed newColumn: [: c | c add: #list ; add: #button height: 26 ]; yourself). --- Glamour is actually written in plain Smalltalk, and you can simply use subclassing, too. For example, something like this: GLMCompositePresentation new with: [ :a | a list display: [ :input | 1 to: input ]; act: [ :list | self halt ] entitled: 'Plip' ]; openOn: 42 Could be done like this: "Define a list presentation with an action in distinct classes to make blocks disappear" GLMGenericAction subclass: #MyPlipAction instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'AAA'. GLMListPresentation subclass: #MyListPresentation instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'AAA'. MyListPresentation compile: 'displayValue ^ 1 to: self entity'. MyListPresentation compile: 'actions ^ {MyPlipAction new}'. MyPlipAction compile: 'actOn: aPresentation self halt'. MyPlipAction compile: 'title ^ ''Plip'''. "Use the list" composite := GLMCompositePresentation new. composite add: (MyListPresentation new). composite openOn: 42. I doubt the blocks are an actual issue. Using blocks has the advantage of more compact code, but it is true that it comes with a price: when you store the block you cannot edit its code live while debugging (you actually can do that, too if you take care). The main difference between Spec and Glamour is actually conceptual: the application space. Spec addresses widgets: with Spec you place widgets on a "canvas" and handle the interaction. So, in a sense, this places Spec at the same level as Morphic. Glamour is at a higher level and it is specifically dedicated to supporting browsing workflows. In its current state, it is not useful for laying out widgets, but it can be very concise for expressing browsers. The way this works is via this "component model". Essentially, a browser can be described as a set of components that can pass data to each other. Glamour lets you model that. It so happens that the inspector and the debugger are browsers and can be expressed at that level. It also so happens that most user interfaces that programmers use can be expressed as browsers, too. And Glamour was actually validated for hundreds of various browsers (literally), so it seems it can support a large set of use cases. If you want to learn more about Glamour you can read the chapters from: - http://deepintopharo.org, or - http://www.themoosebook.org/book/internals/glamour If you want to see where Glamour fits within Moose, you can read this post: http://www.humane-assessment.com/blog/moose-custom-analyses-made-easy Doru -- www.tudorgirba.com "Every thing has its own flow"

Jan. 1, 2014

Re: [Pharo-dev] Spotlight Demo

by Tudor Girba

And it would still be cool if the search would not block the UI process :). Is that on your roadmap? Doru On Wed, Jan 1, 2014 at 9:39 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I went only over the functionality for now (I tried in a Pharo #30664 with > Moose inside). > > It starts to be really interesting: > - I love it how I can navigate with up/down and still continue typing. > This is seriously cool. > > but :): > - Esc has no effect ( > - The list entries behave strangely because you use a text morph that can > be edited. For example, type something, go with the mouse over an item in > the list, you will see the cursor changes to a text one, click, and you can > start typing there. Why not use a LabelMorph? > - Pressing Enter does not seem to trigger the action associated with a > list. Only pressing double click seems to work. > - The PluggableTextMorph at the top allows Enter. Pressing Enter leads to > a line break. This is not wanted (you asked what I meant by it a field). > - The PluggableTextMorph at the top should not indicate dirty state > - Pressing up/down also moves the cursor in the top PluggableTextMorph. > This should not happen. > - It would be interesting to have the count of hits even though we are > only displaying a limited amount. The count could be displayed below the > label (with a gray color) like: > Messages > 23 items > > And a question related to "Show all on down arrow when closed": > - I think I did not see this behavior. What does "closed" mean? And what > do you mean by "all"? > > Cheers, > Doru > > > > > On Wed, Jan 1, 2014 at 7:23 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Sounds like a great New Year gift :). I will review the code today. >> >> Cheers, >> Doru >> >> >> On Wed, Jan 1, 2014 at 3:20 AM, DeNigris Sean <sean(a)clipperadams.com>wrote: >> >>> Thanks for the feedback everyone! >>> >>> A few enhancements: >>> - Close on escape >>> - Select next on down arrow when open >>> - Show all on down arrow when closed >>> - Select previous on up arrow >>> - Accept on enter - requires an override in PluggableTextFieldMorph, but >>> I think the change can be integrated in Core >>> - For entry completion (unlike our current behavior): >>> - Keyboard focus remains with the text field, so: >>> - you can continue to type >>> - the selected item stays selected as long as it remains >>> visible, even if it moves around in the list (maybe doesn't matter for >>> completion...) >>> >>> I'm off to celebrate... See you in the new year! >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 1, 2014

Re: [Pharo-dev] Spotlight Demo

by Tudor Girba

Hi, I went only over the functionality for now (I tried in a Pharo #30664 with Moose inside). It starts to be really interesting: - I love it how I can navigate with up/down and still continue typing. This is seriously cool. but :): - Esc has no effect ( - The list entries behave strangely because you use a text morph that can be edited. For example, type something, go with the mouse over an item in the list, you will see the cursor changes to a text one, click, and you can start typing there. Why not use a LabelMorph? - Pressing Enter does not seem to trigger the action associated with a list. Only pressing double click seems to work. - The PluggableTextMorph at the top allows Enter. Pressing Enter leads to a line break. This is not wanted (you asked what I meant by it a field). - The PluggableTextMorph at the top should not indicate dirty state - Pressing up/down also moves the cursor in the top PluggableTextMorph. This should not happen. - It would be interesting to have the count of hits even though we are only displaying a limited amount. The count could be displayed below the label (with a gray color) like: Messages 23 items And a question related to "Show all on down arrow when closed": - I think I did not see this behavior. What does "closed" mean? And what do you mean by "all"? Cheers, Doru On Wed, Jan 1, 2014 at 7:23 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Sounds like a great New Year gift :). I will review the code today. > > Cheers, > Doru > > > On Wed, Jan 1, 2014 at 3:20 AM, DeNigris Sean <sean(a)clipperadams.com>wrote: > >> Thanks for the feedback everyone! >> >> A few enhancements: >> - Close on escape >> - Select next on down arrow when open >> - Show all on down arrow when closed >> - Select previous on up arrow >> - Accept on enter - requires an override in PluggableTextFieldMorph, but >> I think the change can be integrated in Core >> - For entry completion (unlike our current behavior): >> - Keyboard focus remains with the text field, so: >> - you can continue to type >> - the selected item stays selected as long as it remains >> visible, even if it moves around in the list (maybe doesn't matter for >> completion...) >> >> I'm off to celebrate... See you in the new year! >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 1, 2014

Re: [Pharo-dev] new year resolution

by StÃ©phane Ducasse

> Ok, but let's get concrete. What does better mean in this case? > > I think we could all learn from each other's examples. Relations/Collaborations with other classes Invariant internal representations for real (description of implementation) + examples. Stef > > Doru > > > On Wed, Jan 1, 2014 at 6:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > Iâm fighting to get the old browser working so that I can continue to work on the reloading of configurations of tools. > Now we should really stop to write comments like that for new classes > > ClassOrganization > This object is in charge of system notifications. > It manages the class comment, the class comment stamp and a protocol organizer > > For example I have to reverse engineer the invariant (if any) because I should see how to find a way to implement > numberOfCategoryOfElement: element > which was based on the old index behavior. > > Seriously we should do better. > > Stef > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Jan. 1, 2014

Re: [Pharo-dev] Thank you for Pharo

by StÃ©phane Ducasse

> I understand that community support is needed, and yes i am willing to help. As a first step i can offer my help to test pharo features, help to write test cases, write some example code snippets, open bug reports. But i am not sure what Pharo features or libraries i should put my focus on. Any suggestions where to dig in? Excellent! Thanks. I suggest that you focus on what you like or what you want to learn and do it step by step. Stef

Jan. 1, 2014

Re: [Pharo-dev] Desktop Application with Pharo

by Damir Majer

+1 Thanks for the hints ;-) Damir StÃ©phane Ducasse wrote >>> ben developed a system to give a key to the user. >> >> What is it? > > this is a service that generate a key that you can give your client and > the server checks if this is ok > Ben should be flying to chile tomorrow (to the sun :). > > Stef >> >> -- >> Dr. Geo http://drgeo.eu >> >> ----- -- Damir Majer ... be agile: www.majcon.de -- View this message in context: http://forum.world.st/Desktop-Application-with-Pharo-tp4733442p4733465.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 1, 2014

Re: [Pharo-dev] new year resolution

by Tudor Girba

Ok, but let's get concrete. What does better mean in this case? I think we could all learn from each other's examples. Doru On Wed, Jan 1, 2014 at 6:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Hi guys > > Iâm fighting to get the old browser working so that I can continue to work > on the reloading of configurations of tools. > Now we should really stop to write comments like that for new classes > > ClassOrganization > This object is in charge of system notifications. > It manages the class comment, the class comment stamp and a > protocol organizer > > For example I have to reverse engineer the invariant (if any) because I > should see how to find a way to implement > numberOfCategoryOfElement: element > which was based on the old index behavior. > > Seriously we should do better. > > Stef > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 1, 2014

new year resolution

by StÃ©phane Ducasse

Hi guys Iâm fighting to get the old browser working so that I can continue to work on the reloading of configurations of tools. Now we should really stop to write comments like that for new classes ClassOrganization This object is in charge of system notifications. It manages the class comment, the class comment stamp and a protocol organizer For example I have to reverse engineer the invariant (if any) because I should see how to find a way to implement numberOfCategoryOfElement: element which was based on the old index behavior. Seriously we should do better. Stef

Jan. 1, 2014

Re: [Pharo-dev] Thank you for Pharo

by Volkert Barr

> We all appreciate when Pharo is useful. But it is not yet finished (if it ever will) and you are welcome to help moving it forward as > yet another crazy guy. Step by step it goes ... > > Bye > Torsten I understand that community support is needed, and yes i am willing to help. As a first step i can offer my help to test pharo features, help to write test cases, write some example code snippets, open bug reports. But i am not sure what Pharo features or libraries i should put my focus on. Any suggestions where to dig in? BW, Volkert

Jan. 1, 2014

Re: [Pharo-dev] Desktop Application with Pharo

by StÃ©phane Ducasse

>> ben developed a system to give a key to the user. > > What is it? this is a service that generate a key that you can give your client and the server checks if this is ok Ben should be flying to chile tomorrow (to the sun :). Stef > > -- > Dr. Geo http://drgeo.eu > >

Jan. 1, 2014