Re: [Pharo-project] [Pharo-users] Vancouver Smalltalk Developer Meetup Group
The UI building process is far behind in Pharo and squeak. We are working on improving this. This is an old draft of the system. What we did so far was to build some experiences and learn from them. Now we are on the edge of getting it right. We want to - define widgets - reuse them and their logic - compose them - build a UI Placer tools (later this year) Benjamin started to rewrite most of the tools using this approach. For example the new dual change sorter based on spec is around 9 simple methods binding together two simple change sorter. We will start now an experience with people not knowing the system to see if they can build simple UI such as Monticello browser. And we will refine the approach. Stef On Apr 2, 2012, at 4:19 AM, Nelson Pingitore wrote:
Thank you so much for the invitation. I live near Washington DC. In the US. I am a long time Microsoft Visual Basic developer, developing add-ins for Office products such as Excel, PowerPoint, and Project.
So far, I like what I see regarding productivity, a smaller code footprint and if I can make progress on the UI elements, a much better user experience.
On Sun, Apr 1, 2012 at 4:56 PM, Francois Stephany <tulipe.moutarde@gmail.com> wrote: Hi there,
I've just started a Vancouver Smalltalk Developer Meetup group. If you're in the area, it would great to meet around a beer and some lightning talks.
Cheers, Francois
-- http://tulipemoutarde.be CA: +1 778 558 3225 BE: +32 65 709 131
How is this related to ToolBuilder in the image? 2012/4/2 Stéphane Ducasse <stephane.ducasse@inria.fr>
The UI building process is far behind in Pharo and squeak. We are working on improving this.
This is an old draft of the system.
What we did so far was to build some experiences and learn from them. Now we are on the edge of getting it right. We want to - define widgets - reuse them and their logic - compose them - build a UI Placer tools (later this year) Benjamin started to rewrite most of the tools using this approach. For example the new dual change sorter based on spec is around 9 simple methods binding together two simple change sorter.
We will start now an experience with people not knowing the system to see if they can build simple UI such as Monticello browser. And we will refine the approach.
Stef
On Apr 2, 2012, at 4:19 AM, Nelson Pingitore wrote:
Thank you so much for the invitation. I live near Washington DC. In the US. I am a long time Microsoft Visual Basic developer, developing add-ins for Office products such as Excel, PowerPoint, and Project.
So far, I like what I see regarding productivity, a smaller code footprint and if I can make progress on the UI elements, a much better user experience.
On Sun, Apr 1, 2012 at 4:56 PM, Francois Stephany < tulipe.moutarde@gmail.com> wrote: Hi there,
I've just started a Vancouver Smalltalk Developer Meetup group. If you're in the area, it would great to meet around a beer and some lightning talks.
Cheers, Francois
-- http://tulipemoutarde.be CA: +1 778 558 3225 BE: +32 65 709 131
-- Philippe Back "Helping you hit the top 3 outcomes you really want to achieve" Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges
How is this related to ToolBuilder in the image?
You mean UIBuilder? The idea is that this is quite strange that UIBUilder defines the logic of debugger and other tools building. Now imagine (as this is done in VW) that a tools has a spec that defines how to populate and link its widgets, then we would not need to have UIBuilder concentrating too much of the logic. stef
No, ToolBuilder. ToolBuilder-Kernel ToolBuilder-Morphic ToolBuilder cross-refs: MCWorkingCopyBrowser and ThreadSafeTranscript>>openAsMorphLabel: aString openAsMorphLabel: aString ^ (self buildWith: ToolBuilder default labeled: aString) openInWorld; yourself " ^UIManager default openTranscript: self asMorphLabel: aString So? Looks like interesting but... what's meant in the spec? Phil 2012/4/2 Stéphane Ducasse <stephane.ducasse@inria.fr>
How is this related to ToolBuilder in the image?
You mean UIBuilder? The idea is that this is quite strange that UIBUilder defines the logic of debugger and other tools building. Now imagine (as this is done in VW) that a tools has a spec that defines how to populate and link its widgets, then we would not need to have UIBuilder concentrating too much of the logic.
stef
-- Philippe Back "Helping you hit the top 3 outcomes you really want to achieve" Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges
Ah ok ToolBuilder is an old abstraction we removed. It was a visitor based way of building a UI using different builder. I was however incomplete and not really documented so we decided to simplify everything. On Apr 2, 2012, at 7:08 PM, phil@highoctane.be wrote:
No, ToolBuilder.
ToolBuilder-Kernel ToolBuilder-Morphic
ToolBuilder cross-refs:
MCWorkingCopyBrowser and ThreadSafeTranscript>>openAsMorphLabel: aString
openAsMorphLabel: aString ^ (self buildWith: ToolBuilder default labeled: aString) openInWorld; yourself " ^UIManager default openTranscript: self asMorphLabel: aString
it should a bug. Stef
So? Looks like interesting but... what's meant in the spec?
Phil
2012/4/2 Stéphane Ducasse <stephane.ducasse@inria.fr>
How is this related to ToolBuilder in the image?
You mean UIBuilder? The idea is that this is quite strange that UIBUilder defines the logic of debugger and other tools building. Now imagine (as this is done in VW) that a tools has a spec that defines how to populate and link its widgets, then we would not need to have UIBuilder concentrating too much of the logic.
stef
-- Philippe Back "Helping you hit the top 3 outcomes you really want to achieve"
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges
participants (2)
-
phil＠highoctane.be -
Stéphane Ducasse