[Pharo-users] Spec Layout Help

[Rob Rothwell]

Hello,

How might one achieve a fixed width column containing fixed width widgets
within a resizable row using Spec Layouts?

For example:

<--- Resizable Space --->| Fixed Width |<---Resizable Space --->

Where the Fixed Width space might have something like a left justified
input field and a right justified button or something.  The best I can
achieve is everything resizable, which Spec excels at!  I have tried adding
three columns to the row with the center column a fixed width
(newColumn:width:), but I can't seem to get it centered.

I have even tried adding dummy widgets as in the code below, which creates
a resizable column taking up the first half of the space, followed by a
fixed width (100) input field, followed by another resizable space (sharing
the right half of the column with the fixed width column):

LayoutPractice>>defaultSpec

^ SpecColumnLayout composed
newRow: [:row |
row
newColumn: [ :col | col add: #spacer1 height: 30 ];
newColumn: [ :col | col add: #inputField height: 30] width: 100;
newColumn: [ :col | col add: #spacer2 height: 30 ];
yourself
] height: 50;
newRow: [:row | row add: #list ];
yourself

If this is not possible, could I allow the window to resize vertically but
not horizontally (I have a ListPresenter below problematic row which would
be nice to resize vertically)?

Thank you,

Rob

Re: [Pharo-users] DictionaryValueHolder question

[Rob Rothwell]

Hi Peter,

Thank you very much for the clarification; I'll see what I can come up with!

Take care,

Rob

On Tue, Sep 12, 2017 at 11:18 AM, Peter Uhnák <i.uh...@gmail.com> wrote:

> Hi Rob,
>
> this is by omission. Originally CollectionValueHolder didn't have it
> either until I've introduced ValueAdded/ValueRemoved. So feel free to
> incorporate it in a meaningful fashion to a DictionaryHolder.
>
> Peter
>
> On Tue, Sep 12, 2017 at 3:46 AM, Rob Rothwell <r.j.rothw...@gmail.com>
> wrote:
>
>> Hello,
>>
>> Unlike the CollectionValueHolder, the DictionaryValueHolder only notifies
>> you that something has changed, rather than tell you what item has been
>> added or removed.  Does anyone know if this is by design, or just
>> incomplete?
>>
>> If incomplete, what do you think about using the
>> ValueAdded/ValueChanged/ValueRemoved announcements and passing the
>> association in newValue/oldValue?
>>
>> Thank you,
>>
>> Rob
>>
>>
>>
>

Re: [Pharo-users] Accessor Creation in Nautilus Browser

[Rob Rothwell]

On Tue, Sep 12, 2017 at 5:45 AM, Alistair Grant <akgrant0...@gmail.com>
wrote:

> Hi Rob,
>
> On 12 September 2017 at 03:32, Rob Rothwell <r.j.rothw...@gmail.com>
> wrote:
> > Hello,
> >
> > Is there a way to create accessors for more than one instance variable
> at a
> > time with the Nautilus browser?
> >
> > "Class -> Refactoring -> Inst Var Refactoring -> Accessors" shows
> available
> > instance variables, but only one can be selected...
> >
> > Thank you,
> >
> > Rob
>
> Class -> Refactoring -> Class Refactoring -> Generate Accessors
>
>
  Ha!  Thank you...my brain kept seeing "Class" and saying, "But I'm not ON
the Class side!"

Thanks again,

Cheers,
> Alistair
>
>

[Pharo-users] DictionaryValueHolder question

[Rob Rothwell]

Hello,

Unlike the CollectionValueHolder, the DictionaryValueHolder only notifies
you that something has changed, rather than tell you what item has been
added or removed.  Does anyone know if this is by design, or just
incomplete?

If incomplete, what do you think about using the
ValueAdded/ValueChanged/ValueRemoved announcements and passing the
association in newValue/oldValue?

Thank you,

Rob

[Pharo-users] Accessor Creation in Nautilus Browser

[Rob Rothwell]

Hello,

Is there a way to create accessors for more than one instance variable at a
time with the Nautilus browser?

"Class -> Refactoring -> Inst Var Refactoring -> Accessors" shows available
instance variables, but only one can be selected...

Thank you,

Rob

Re: [Pharo-users] Spec "bindings"

[Rob Rothwell]

On Sat, Sep 9, 2017 at 5:06 AM, Stephane Ducasse 
wrote:

> Hi Rob
>
> I discussed with peter and I hope that he has more and younger
> braincells than me. I'm *super* busy with lectures
> preparation, workshop preparation and business issues. So I would love
> to get some time to get concentrated but not before beginning of
> October at the minimum.
> May be when I am at Prague we can discuss with Peter.
>
> Stef
>
>
>
Hi Stef,

Thank you very much for the encouragement,  and good luck with all your
endeavors.  I have a huge MOOC project going on at work myself (you know
how that can be), but I will keep experimenting with this and try to be
prepared when there is some time available!

Take care,

Rob

Re: [Pharo-users] Spec "bindings"

[Rob Rothwell]

On Sat, Sep 9, 2017 at 7:11 AM, Peter Uhnak  wrote:

> Hi Rob,
>
> I'm making a note to look at your proposals and I will discuss it with
> Stef later.
>

Thanks, Peter, I appreciate any insights you can offer.  I will continue
experimenting, and just wanted to make sure I figured out how to share my
ideas during a window of opportunity I had.


> >
> > he has more and younger braincells than me
>
> But not enough connections between them. The cells just sit there alone
> and are not talking to anyone. :(
>

I can certainly relate to that! Unfortunately, some of my best thinking is
out loud trying to explain something I don't really understand to someone
else...

Take care,

Rob


>
> Peter
>
>

Re: [Pharo-users] Spec "bindings"

[Rob Rothwell]

s wrong.
>
> To fit Spec (but Spec is certainly too limited)
>

Like you said, it just needs some continuous improvement!


>
> >
> >
> > It would be interesting to hear the arguments against lists and trees
> > updating themselves when their underlying objects change.  It looks like
> > Spec, VW, and Pharo all require you to monitor and replace the UI list
> when
> > something is updated.
>
> mistake :)
> Lack of analysis.
> We are learning while doing it so let us continue.
>

I'll try to recreate my VW experiments, which needed a sort of "complex
object value holder" so you could have something like a Person object in
your list that that displayed some representative string like a full name.
Then, if any of the components of Person (or any of their their
sub-components, like aPerson personName firstName) changed, these changes
propagated to the to top and let the list know that one of it's items had
changed so it knew to update it in the list.

Take care,

Rob


> >
> >>
> >>
> >> Stef
> >>
> >> thanks for this discussion.
> >
> >
> > You're very welcome.
> >
> > Take care,
> >
> > Rob
> >
> >>
> >>
> >> >
> >> > Take care,
> >> >
> >> > Rob
> >> >
> >> > On Tue, Sep 5, 2017 at 6:08 PM, Stephane Ducasse
> >> > <stepharo.s...@gmail.com>
> >> > wrote:
> >> >>
> >> >> Rob
> >> >>
> >> >> Spec deserves another pass.
> >> >> I see your point with showOn: now I do not see how you could avoid
> the
> >> >> presenter building. But may be I'm not enough into it.
> >> >> So I'm interested in your feedback.
> >> >>
> >> >> Stef
> >> >>
> >> >> Stef
> >> >>
> >> >> On Tue, Sep 5, 2017 at 8:49 PM, Rob Rothwell <r.j.rothw...@gmail.com
> >
> >> >> wrote:
> >> >> > Hello,
> >> >> >
> >> >> > I was wondering what more experienced users than myself thought of
> >> >> > the
> >> >> > idea
> >> >> > of an explicit Spec "connection point" to a domain model object
> >> >> > similar
> >> >> > to
> >> >> > Dolphin's "showOn:" method, like:
> >> >> >
> >> >> > CounterApp showOn: counter.
> >> >> >
> >> >> > This would perhaps trigger something like Dolphin's
> Presenter>>model:
> >> >> > message (although I've always found the use of "model" confusing
> when
> >> >> > there
> >> >> > are so many "models" involved.) after the widgets had been created:
> >> >> >
> >> >> > ComposableModel>>initializeBindings: anObject
> >> >> >
> >> >> > In many cases, if your domain model uses ValueHolders as well (like
> >> >> > Spec
> >> >> > does), making a connection could just mean replacing the Spec
> >> >> > ValueHolder
> >> >> > with your domain ValueHolder so changes to the domain model would
> >> >> > automatically propagate to the UI presentation without providing
> >> >> > explicit
> >> >> > code in ComposableModel>>initializePresenter.
> >> >> >
> >> >> > However, since I am still trying to understand and learn Spec, it's
> >> >> > quite
> >> >> > possible I am missing some key point and there are reasons not to
> >> >> > explore
> >> >> > this line of thinking!
> >> >> >
> >> >> > Thank you,
> >> >> >
> >> >> > Rob
> >> >> >
> >> >>
> >> >
> >>
> >
>
>

Re: [Pharo-users] Spec "bindings"

[Rob Rothwell]

amples like master-detail lists and so on.


> I want to write a small interface for a small app.
> I checked my code
> and I thought that it was strange that we cannot initialize presenter
> once the model is done
>

Right...you can see in Spec that each type of widget creates a static
ValueHolder ( such as '' asValueHolder ) for each type of widget and does
not currently offer a method to swap it out with a new one.

Also, there are probably more available Morphic widgets that could be
adapted (like a progress bar as an number presenter, for example).


>
> GameListModel new
>on: GameCollector smallCollection;
>openWithSpec
>
>
> "protocol: #initialization"
>
> initializeWidgets
>   listModel := self newList.
>   listModel items: (collector collectionNamed: #owned)
>
> and then back then I realized that I was wrong.
>

It would be interesting to hear the arguments against lists and trees
updating themselves when their underlying objects change.  It looks like
Spec, VW, and Pharo all require you to monitor and replace the UI list when
something is updated.


>
> Stef
>
> thanks for this discussion.
>

You're very welcome.

Take care,

Rob


>
> >
> > Take care,
> >
> > Rob
> >
> > On Tue, Sep 5, 2017 at 6:08 PM, Stephane Ducasse <
> stepharo.s...@gmail.com>
> > wrote:
> >>
> >> Rob
> >>
> >> Spec deserves another pass.
> >> I see your point with showOn: now I do not see how you could avoid the
> >> presenter building. But may be I'm not enough into it.
> >> So I'm interested in your feedback.
> >>
> >> Stef
> >>
> >> Stef
> >>
> >> On Tue, Sep 5, 2017 at 8:49 PM, Rob Rothwell <r.j.rothw...@gmail.com>
> >> wrote:
> >> > Hello,
> >> >
> >> > I was wondering what more experienced users than myself thought of the
> >> > idea
> >> > of an explicit Spec "connection point" to a domain model object
> similar
> >> > to
> >> > Dolphin's "showOn:" method, like:
> >> >
> >> > CounterApp showOn: counter.
> >> >
> >> > This would perhaps trigger something like Dolphin's Presenter>>model:
> >> > message (although I've always found the use of "model" confusing when
> >> > there
> >> > are so many "models" involved.) after the widgets had been created:
> >> >
> >> > ComposableModel>>initializeBindings: anObject
> >> >
> >> > In many cases, if your domain model uses ValueHolders as well (like
> Spec
> >> > does), making a connection could just mean replacing the Spec
> >> > ValueHolder
> >> > with your domain ValueHolder so changes to the domain model would
> >> > automatically propagate to the UI presentation without providing
> >> > explicit
> >> > code in ComposableModel>>initializePresenter.
> >> >
> >> > However, since I am still trying to understand and learn Spec, it's
> >> > quite
> >> > possible I am missing some key point and there are reasons not to
> >> > explore
> >> > this line of thinking!
> >> >
> >> > Thank you,
> >> >
> >> > Rob
> >> >
> >>
> >
>
>

Re: [Pharo-users] Spec "bindings"

[Rob Rothwell]

Hi Stef,

I think you are correct and you would still always perform actions like:

initializeWidgets (to create components and sub-components)
initializePresenter (to define interactions between components)


But, there could also be a third initialization step like

initializeSubject: aSubjectModel


That would allow you to initialize the domain model of each component
relative to your overall model.

Then, by exposing the aspects of your model available for viewing by a UI
as ValueHolders, it looks pretty straightforward (for simple objects) to
extend Spec to use those ValueHolders so that UI elements can implicitly
update themselves.

The source of my inspiration is the Dolphin "Better Hello World" example(s)
here:

http://object-arts.com/blog/files/better-hello-world.html


To try it out, I added a few Spec extensions and tried a little "counter"
test (like your MOOC example) displayed by a CounterApp (having an
increment button, decrement button, and label to show the count) such that

CounterApp showOn: counter

triggers

CounterApp>>initializeSubject: aSubjectModel

subject := aSubjectModel.

countLabel initializeSubject: subject countHolder

This results in replacing the UI label ValueHolder with the Counter's
"count" ValueHolder.  If I had more aspects of my model I wanted to
connect, I would do it here, or if I wanted to connect the same thing to
multiple widgets (like a slider, for example), I would do that here as well.

This allows direct interactions with the Counter model (for example, an
"increment" button) to be reflected directly by the UI without having to
explicitly update the value after the interaction or listening for events.

I'll have to think about it some more, but I think Spec has what it needs
already to create a nice set of "type presenters" instead of what is
currently seems more like "widget presenters."

Then, instead of adding a LabelModel to a ComposableModel, you could add
something like a NumberPresenter and specify the spec you want to use
(which would in turn display the desired widget).
I didn't go that far yet, and created a NumberLabelModel for my example
above. It worked, but seems like the wrong way to go about it.  Or maybe
you need both...I'm not sure!

I also want to take a look at self-updating complex widgets as well (lists,
tables, etc...) so that telling a list presenter it's list means that
adding a value to that list could automatically update the widget and so
on.
I had some crude prototyping success with that in VW before deciding
(hopefully for the last time) that "native" widgets aren't as important to
me as a solid and simple way to connect a model to a UI presentation.

This seems much easier to achieve in Pharo, and after years of intermittent
attempts I am hopeful that my knowledge level has finally become sufficient
to contribute something to this heroic effort.

Take care,

Rob

On Tue, Sep 5, 2017 at 6:08 PM, Stephane Ducasse <stepharo.s...@gmail.com>
wrote:

> Rob
>
> Spec deserves another pass.
> I see your point with showOn: now I do not see how you could avoid the
> presenter building. But may be I'm not enough into it.
> So I'm interested in your feedback.
>
> Stef
>
> Stef
>
> On Tue, Sep 5, 2017 at 8:49 PM, Rob Rothwell <r.j.rothw...@gmail.com>
> wrote:
> > Hello,
> >
> > I was wondering what more experienced users than myself thought of the
> idea
> > of an explicit Spec "connection point" to a domain model object similar
> to
> > Dolphin's "showOn:" method, like:
> >
> > CounterApp showOn: counter.
> >
> > This would perhaps trigger something like Dolphin's Presenter>>model:
> > message (although I've always found the use of "model" confusing when
> there
> > are so many "models" involved.) after the widgets had been created:
> >
> > ComposableModel>>initializeBindings: anObject
> >
> > In many cases, if your domain model uses ValueHolders as well (like Spec
> > does), making a connection could just mean replacing the Spec ValueHolder
> > with your domain ValueHolder so changes to the domain model would
> > automatically propagate to the UI presentation without providing explicit
> > code in ComposableModel>>initializePresenter.
> >
> > However, since I am still trying to understand and learn Spec, it's quite
> > possible I am missing some key point and there are reasons not to explore
> > this line of thinking!
> >
> > Thank you,
> >
> > Rob
> >
>
>

[Pharo-users] Spec "bindings"

[Rob Rothwell]

Hello,

I was wondering what more experienced users than myself thought of the idea
of an explicit Spec "connection point" to a domain model object similar to
Dolphin's "showOn:" method, like:

CounterApp showOn: counter.

This would perhaps trigger something like Dolphin's Presenter>>model:
message (although I've always found the use of "model" confusing when there
are so many "models" involved.) after the widgets had been created:

ComposableModel>>initializeBindings: anObject

In many cases, if your domain model uses ValueHolders as well (like Spec
does), making a connection could just mean replacing the Spec ValueHolder
with your domain ValueHolder so changes to the domain model would
automatically propagate to the UI presentation without providing explicit
code in ComposableModel>>initializePresenter.

However, since I am still trying to understand and learn Spec, it's quite
possible I am missing some key point and there are reasons not to explore
this line of thinking!

Thank you,

Rob

Re: [Pharo-users] Spec Adapter Advice

[Rob Rothwell]

ften held in ValueHolders, which can be observed on ValueChange, so
> the
> > > Adapter can register to event change and react on itself;
> > >
> > > you can see this best in MorphicTabAdapter (but you will see that
> > > TabAdapter looks a bit different from the rest, because I was
> experimenting
> > > with cleaning up Adapters...)
> > >
> > > 2. adapter to morphic
> > >
> > > Every adapter implements #buildWidget method that returns a Morphic
> Object.
> > > Typically the adapter registers itself as the model of the adapter (so
> > > adapter's model is Spec, and Morphic's model is the adapter). This
> depends
> > > a lot on the API of morphic. (in TabAdapter I'm overriding adapt: so
> > > there's no buildWidget, and it is in #buildWidgetWith:).
> > >
> > > It is all kinds of messy, but if you have other widgets then it will
> be a
> > > good test how well Spec can handle it... or rather we'll see how it
> can be
> > > improved...
> > >
> > > Peter
> > >
> > >
> > >
> > > On Thu, Apr 27, 2017 at 05:10:39PM -0400, Rob Rothwell wrote:
> > > > Hello,
> > > >
> > > > I have recently been lucky enough to get the Cocoa portion of Mars
> > > working
> > > > on Pharo 5.0.  While there are some issues, it has a wonderful set of
> > > > examples that allowed me create new Cocoa classes and delegate
> methods
> > > and
> > > > see a straightforward path to learning how to use Coco widgets from
> > > Pharo.
> > > >
> > > > I'd like to do that by creating appropriate Spec adapters, but
> > > > unfortunately the new Spec booklet wasn't designed for that!
> > > >
> > > > Can anyone give me any insight into creating (and using) a new Spec
> > > > adapter?  Maybe just some high level steps to help me orient my
> > > > investigation into how Spec works?
> > > >
> > > > Thank you,
> > > >
> > > > Rob
> > >
> > >
>
>

Re: [Pharo-users] Spec Adapter Advice

[Rob Rothwell]

Hi Peter,

Thank you very much for that overview!

It looks like even just creating a window with no other widgets is sort of
"hard-wired" to Morphic through ComposableModel>>defaultWindowModelClass,
so maybe just overriding that and trying to create a Cocoa window model and
adapter is the place to start.

I need to find a good starting point because you can't poke at the existing
code too much since even the debugger is built with Spec!

It's pretty exciting, though, because it feels like all the right pieces
are there and a lot of this could mostly be "just work" once I get going.

Thanks again,

Rob

On Thu, Apr 27, 2017 at 6:04 PM, Peter Uhnak <i.uh...@gmail.com> wrote:

> Hi Rob,
>
> I guess the best resource at the moment is to just look at existing
> adapters.
>
> But here are some thoughts to get you started:
>
> (Spec) ComposableModel has as its widget (Spec) Adapter
> Adapter has as its widget the actual visual component, which currently
> means Morphic.
>
>
> The simplest example: LabelModel
>
> 1. model to adapter
>
> LabelModel is adapted by MorphicLabelAdapter:
>
> you can see on the class side in method `defaultSpec`.
> There is only `LabelAdapter` there because there is some extra mapping for
> some classes, but you can specify directly the class of the Adapter, so the
> following would work just as well:
>
> LabelModel class>>defaultSpec
> 
>
> ^ #(MorphicLabelAdapter
> adapt: #(model))
>
>
> LabelModel -> LabelAdapter direct event propagation (pushing changes)
>
> in Model world you can call changed:with: to execute code on the Adapter,
> e.g.
>
> self changed: #emphasis: with: {emphasis}
>
> which in turn will call the #emphasis: method on the LabelAdapter.
>
> LabelModel -> LabelAdapter events (pulling changes)
>
> preferred alternative is to do the opposite; properties of models are
> often held in ValueHolders, which can be observed on ValueChange, so the
> Adapter can register to event change and react on itself;
>
> you can see this best in MorphicTabAdapter (but you will see that
> TabAdapter looks a bit different from the rest, because I was experimenting
> with cleaning up Adapters...)
>
> 2. adapter to morphic
>
> Every adapter implements #buildWidget method that returns a Morphic Object.
> Typically the adapter registers itself as the model of the adapter (so
> adapter's model is Spec, and Morphic's model is the adapter). This depends
> a lot on the API of morphic. (in TabAdapter I'm overriding adapt: so
> there's no buildWidget, and it is in #buildWidgetWith:).
>
> It is all kinds of messy, but if you have other widgets then it will be a
> good test how well Spec can handle it... or rather we'll see how it can be
> improved...
>
> Peter
>
>
>
> On Thu, Apr 27, 2017 at 05:10:39PM -0400, Rob Rothwell wrote:
> > Hello,
> >
> > I have recently been lucky enough to get the Cocoa portion of Mars
> working
> > on Pharo 5.0.  While there are some issues, it has a wonderful set of
> > examples that allowed me create new Cocoa classes and delegate methods
> and
> > see a straightforward path to learning how to use Coco widgets from
> Pharo.
> >
> > I'd like to do that by creating appropriate Spec adapters, but
> > unfortunately the new Spec booklet wasn't designed for that!
> >
> > Can anyone give me any insight into creating (and using) a new Spec
> > adapter?  Maybe just some high level steps to help me orient my
> > investigation into how Spec works?
> >
> > Thank you,
> >
> > Rob
>
>

[Pharo-users] Spec Adapter Advice

[Rob Rothwell]

Hello,

I have recently been lucky enough to get the Cocoa portion of Mars working
on Pharo 5.0.  While there are some issues, it has a wonderful set of
examples that allowed me create new Cocoa classes and delegate methods and
see a straightforward path to learning how to use Coco widgets from Pharo.

I'd like to do that by creating appropriate Spec adapters, but
unfortunately the new Spec booklet wasn't designed for that!

Can anyone give me any insight into creating (and using) a new Spec
adapter?  Maybe just some high level steps to help me orient my
investigation into how Spec works?

Thank you,

Rob

Re: [Pharo-users] FFI return by reference

[Rob Rothwell]

>
> This is pretty new but there is some thread in the mailing list about it.
>
> Esteban also begun a documentation:
>
> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/UnifiedFFI/UnifiedFFI.pdf


Thanks Cyril, this is a very nice start and helps a lot!

Take care,

Rob

Re: [Pharo-users] FFI return by reference

[Rob Rothwell]

>
>
> Is there any general information about UFFI usage anywhere, or is
> reviewing this thread my best place to start?
>
> It looks like Torsten's new WebBrowser package might get me started!

Rob

Re: [Pharo-users] [ANN] General WebBrowser package for Pharo4 and Pharo 5 onwards

[Rob Rothwell]

>
>
> # Usage
>
> WebBrowser openOn: 'http://www.pharo.org'
>

Fantastic...this is a nice example of using UFFI to call a LibC command,
and since it is just using open(1), you can also do something like:


WebBrowser openOn: '/users/rob/desktop/enterprisepharo.pdf'

To generically open a file!

Take care,

Rob

Re: [Pharo-users] FFI return by reference

[Rob Rothwell]

On Wed, Apr 13, 2016 at 8:52 AM, Esteban Lorenzano 
wrote:

> Hi,
>
> Just checked… contrary to what I believed, strings are passed by copy (not
> by reference, as ByteArray)… logical for safety but with penalty on
> performance... so yes, using a ByteArray is the correct way to do it. (Or
> an external value holder, which is a glorified way for passing a ByteArray,
> but this probably do not work fine for “char*" because I didn’t preview it
> :P)
>
> Hello,

I've never used UFFI before, but would like to call setxattr and getxattr
in LibC on OS X (which also pass strings).  I don't have a lot of Mac or
Unix background, but I have past experience fiddling with parameters to
call external Windows libraries from VB.

Is there any general information about UFFI usage anywhere, or is reviewing
this thread my best place to start?

Thank you,

Rob

Re: [Pharo-users] List with Border

[Rob Rothwell]

On Tue, Apr 12, 2016 at 3:00 PM, Stephan Eggermont  wrote:

>
> Not ideal, and should be fixed.
>
> Would you consider this a Priority 4 "Would be nice" like Issue 17743 and
17754? (I have been looking for things at my skill level I might actually
be able to track down).

Rob

Re: [Pharo-users] [video] How to open an issue and submit a fix

[Rob Rothwell]

On Tue, Apr 12, 2016 at 4:22 AM, Stephan Eggermont <step...@stack.nl> wrote:

> On 11/04/16 18:53, Rob Rothwell wrote:
>
>> Where can I learn how to open a bug entry and/or how to submit a fix?
>>
>
> https://vimeo.com/162493974


Thanks again, Stephan.  I'll watch this and see if I can figure it out!

Re: [Pharo-users] MessageDialogWindow(s)

[Rob Rothwell]

On Tue, Apr 12, 2016 at 4:05 AM, Stephan Eggermont  wrote:

> On 12/04/16 08:56, stepharo wrote:
>
>> can you submit a fix?
>>
>
> 17979 (MessageDialogWindow new text: 'Hello') open should work
>

Thanks, Stephan...I apologize for my slowness...

Re: [Pharo-users] MessageDialogWindow(s)

[Rob Rothwell]

On Mon, Apr 11, 2016 at 2:52 AM, Nicolai Hess  wrote:

>
>
> 2016-04-11 8:29 GMT+02:00 Stephan Eggermont :
>
>> On 11-04-16 02:00, Robert J Rothwell wrote:
>>
>>> Should
>>>
>>> (MessageDialogWindow new text: 'Hello') open
>>>
>>> work?
>>>
>>> I get a stack trace on CompositionScanner if I try to set the text.
>>>
>>
>> Yes. Please open a bug entry. (If you want to help, try with a few older
>> versions
>> of pharo to find out when the bug was introduced)
>
>
Where can I learn how to open a bug entry and/or how to submit a fix?



>
>>
> Yes, maybe MessageDialogWindow should init the font with a default font.
>

You are correct; adding:

MessageDialogWindow>>initialize
^super initialize textFont: (Smalltalk ui theme textFont)

Corrects the problem in Pharo 4.0 and Pharo 5.0


>
>
>> Also, is there a way to display the dialog modally (relative to your
>>> application)?
>>>
>>> Take a look at Morph>openModal:
>>
>
Thank you!


>
>> Stephan
>>
>>
> And this DialogWindow classes are used by UITheme, for example
>
> Smalltalk ui theme messageIn:World text:'Some MessageText' title:'The
> Title'.
> or for long messages:
> Smalltalk ui theme longMessageIn:World text: ProfStef
> pharoZenValuesContents  title:'Pharo Zen'.
>
> The "World" argument specifies to which Window this Dialog should be modal.
>

This seems like what I should have done in the first place!

Rob