7 Aug
2017
7 Aug
'17
9:44 a.m.
Hoi,
What is the best way for an object to delegate one or more GTInspector
views to other objects?
I have been using a pattern like this:
gtInspectorFooIn: composite
<gtInspectorPresentationOrder: 5>
otherObject gtInspectorFooIn: composite
but I am wondering whether there is a better way, and also whether this
method is valid (I've occasionally seen odd behavior, like Inspector panes
disappearing after I "Refresh", and I wonder if I could be somehow
confusing the model or if this is not relevant.)
also: Supposing this pattern is valid, is there an easy way to override the
title of the view(s) added by otherObject?
7 Aug
7 Aug
11:02 a.m.
Hi,
On Mon, Aug 7, 2017 at 9:44 AM, Luke Gorrie <luke(a)snabb.co> wrote:
Hoi,
What is the best way for an object to delegate one or more GTInspector
views to other objects?
I have been using a pattern like this:
gtInspectorFooIn: composite
<gtInspectorPresentationOrder: 5>
otherObject gtInspectorFooIn: composite
This is indeed the normal way of delegating the construction of a view to
another object. Just if otherObject can be nil it might be better to use an
accessor that ensures the object is present. If that's not an option then
either add a nil check or use a dynamic presentation.
but I am wondering whether there is a better way, and also whether this
method is valid (I've occasionally seen odd behavior, like Inspector panes
disappearing after I "Refresh", and I wonder if I could be somehow
confusing the model or if this is not relevant.)
Should not be relevant. But there can always be a bug. If you find a
reproducible case that would help. Also when reusing presentations like
above it's better to define the #display block like this 'display: [ self
computeValuesToDisplay ] ' instead of 'display: [ :each | each
computeValuesToDisplay ]'.
also: Supposing this pattern is valid, is there an easy way to override
the title of the view(s) added by otherObject?
If you return the actual presentation then you can customize any property
of that presentation:
gtInspectorFooIn: composite
<gtInspectorPresentationOrder: 5>
^ (otherObject gtInspectorFooIn: composite)
title: 'Another title'
Cheers,
Andrei
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
8 Sep
8 Sep
11:02 a.m.
On 7 August 2017 at 11:02, Andrei Chis <chisvasileandrei(a)gmail.com> wrote:
I have not finally tracked down this issue yet but it seems to be related
to error cases e.g. pressing "Abandon" in the debugger. Symptom is that the
first pane of the inspector mysteriously disappears. I will open an issue
when I know how to reproduce it.
Hi,
On Mon, Aug 7, 2017 at 9:44 AM, Luke Gorrie <luke(a)snabb.co> wrote:
Here is the part that I am missing: How do I tell the Inspector that the
*value* to inspect is otherObject instead of self?
I mean, it seems like this code constructs the GLMPresentation for
otherObject but then applies it to self, which may not be compatible.
Maybe I should add 'display: [ otherObject ]' ?
Hoi,
What is the best way for an object to delegate one or more GTInspector
views to other objects?
I have been using a pattern like this:
gtInspectorFooIn: composite
<gtInspectorPresentationOrder: 5>
otherObject gtInspectorFooIn: composite
This is indeed the normal way of delegating the construction of a view to
another object. Just if otherObject can be nil it might be better to use an
accessor that ensures the object is present. If that's not an option then
either add a nil check or use a dynamic presentation.
but I am
wondering whether there is a better way, and also whether this
method is valid (I've occasionally seen odd behavior, like Inspector panes
disappearing after I "Refresh", and I wonder if I could be somehow
confusing the model or if this is not relevant.)
Should not be relevant. But there can always be a bug. If you find a
reproducible case that would help.
11:46 a.m.
Hi,
The way you make presentations reusable in other contexts id by making gtInspectorFooIn:
display self. Something like this
SomeOtherClass>>#gtInspectorFooIn: ccomposite
<gtInspectorPresentationOrder: 5>
composite text display: [ :ignoredObject | self … ] …
So, the display block depends on self and not on the object you get in the block.
Like this, when you do:
SomeClass>>gtInspectorFooIn: composite
<gtInspectorPresentationOrder: 5>
otherObject gtInspectorFooIn: composite
You will actually apply the inner presentation on otherObject (instance of
SomeOtherClass), rather than on the current object (instance of SomeClass).
Does it make sense?
Cheers,
Doru
On Sep 8, 2017, at 11:02 AM, Luke Gorrie
<luke(a)snabb.co> wrote:
On 7 August 2017 at 11:02, Andrei Chis <chisvasileandrei(a)gmail.com> wrote:
Hi,
On Mon, Aug 7, 2017 at 9:44 AM, Luke Gorrie <luke(a)snabb.co> wrote:
Hoi,
What is the best way for an object to delegate one or more GTInspector views to other
objects?
I have been using a pattern like this:
gtInspectorFooIn: composite
<gtInspectorPresentationOrder: 5>
otherObject gtInspectorFooIn: composite
This is indeed the normal way of delegating the construction of a view to another object.
Just if otherObject can be nil it might be better to use an accessor that ensures the
object is present. If that's not an option then either add a nil check or use a
dynamic presentation.
Here is the part that I am missing: How do I tell the Inspector that the *value* to
inspect is otherObject instead of self?
I mean, it seems like this code constructs the GLMPresentation for otherObject but then
applies it to self, which may not be compatible.
Maybe I should add 'display: [ otherObject ]' ?
but I am wondering whether there is a better way, and also whether this method is valid
(I've occasionally seen odd behavior, like Inspector panes disappearing after I
"Refresh", and I wonder if I could be somehow confusing the model or if this is
not relevant.)
Should not be relevant. But there can always be a bug. If you find a reproducible case
that would help.
I have not finally tracked down this issue yet but it seems to be related to error cases
e.g. pressing "Abandon" in the debugger. Symptom is that the first pane of the
inspector mysteriously disappears. I will open an issue when I know how to reproduce it.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
www.feenk.com
"Value is always contextual."
8 Dec
8 Dec
10:49 a.m.
Thanks (belatedly) for this tip, Doru.
I have a follow on question. Is there an easy way to have the GTInspector
include _all_ views for a sub-object?
Like, I have a wrapped object that is a proxy to the real object, and when
I inspect the wrapper I would like to automatically see all the views for
the real object?
Just now I am going into Raw and selecting the real object but this is a
bit laborious. I also want to be able to disable the Raw tab for users who
are not Smalltalk hackers.
On 8 September 2017 at 11:46, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
The way you make presentations reusable in other contexts id by making
gtInspectorFooIn: display self. Something like this
SomeOtherClass>>#gtInspectorFooIn: ccomposite
<gtInspectorPresentationOrder: 5>
composite text display: [ :ignoredObject | *self* … ] …
So, the display block depends on self and not on the object you get in the
block.
Like this, when you do:
SomeClass>>gtInspectorFooIn: composite
<gtInspectorPresentationOrder: 5>
otherObject gtInspectorFooIn: composite
You will actually apply the inner presentation on *otherObject (instance
of SomeOtherClass)*, rather than on the current object (instance of
SomeClass).
Does it make sense?
Cheers,
Doru
On Sep 8, 2017, at 11:02 AM, Luke Gorrie <luke(a)snabb.co> wrote:
On 7 August 2017 at 11:02, Andrei Chis <chisvasileandrei(a)gmail.com> wrote:
Hi,
On Mon, Aug 7, 2017 at 9:44 AM, Luke Gorrie <luke(a)snabb.co> wrote:
Hoi,
What is the best way for an object to delegate one or more GTInspector
views to other objects?
I have been using a pattern like this:
gtInspectorFooIn: composite
<gtInspectorPresentationOrder: 5>
otherObject gtInspectorFooIn: composite
This is indeed the normal way of delegating the construction of a view to
another object. Just if otherObject can be nil it might be better to use an
accessor that ensures the object is present. If that's not an option then
either add a nil check or use a dynamic presentation.
Here is the part that I am missing: How do I tell the Inspector that the
*value* to inspect is otherObject instead of self?
I mean, it seems like this code constructs the GLMPresentation for
otherObject but then applies it to self, which may not be compatible.
Maybe I should add 'display: [ otherObject ]' ?
but I am wondering whether there is a better way, and also whether this
method is valid (I've occasionally seen odd behavior, like Inspector panes
disappearing after I "Refresh", and I wonder if I could be somehow
confusing the model or if this is not relevant.)
Should not be relevant. But there can always be a bug. If you find a
reproducible case that would help.
I have not finally tracked down this issue yet but it seems to be related
to error cases e.g. pressing "Abandon" in the debugger. Symptom is that the
first pane of the inspector mysteriously disappears. I will open an issue
when I know how to reproduce it.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
www.feenk.com
"Value is always contextual."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
21 Dec
21 Dec
6:39 p.m.
Hi,
The way to do that is by overriding gtInspectorPresentationsIn:inContext: like this:
SomeClass>>gtInspectorPresentationsIn: composite inContext: aGTInspector
super gtInspectorPresentationsIn: composite inContext: aGTInspector.
otherObject gtInspectorPresentationsIn: composite inContext: aGTInspector
Cheers,
Doru
On Dec 8, 2017, at 10:49 AM, Luke Gorrie
<luke(a)snabb.co> wrote:
Thanks (belatedly) for this tip, Doru.
I have a follow on question. Is there an easy way to have the GTInspector include _all_
views for a sub-object?
Like, I have a wrapped object that is a proxy to the real object, and when I inspect the
wrapper I would like to automatically see all the views for the real object?
Just now I am going into Raw and selecting the real object but this is a bit laborious. I
also want to be able to disable the Raw tab for users who are not Smalltalk hackers.
On 8 September 2017 at 11:46, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
The way you make presentations reusable in other contexts id by making gtInspectorFooIn:
display self. Something like this
SomeOtherClass>>#gtInspectorFooIn: ccomposite
<gtInspectorPresentationOrder: 5>
composite text display: [ :ignoredObject | self … ] …
So, the display block depends on self and not on the object you get in the block.
Like this, when you do:
SomeClass>>gtInspectorFooIn: composite
<gtInspectorPresentationOrder: 5>
otherObject gtInspectorFooIn: composite
You will actually apply the inner presentation on otherObject (instance of
SomeOtherClass), rather than on the current object (instance of SomeClass).
Does it make sense?
Cheers,
Doru
--
www.tudorgirba.com
www.feenk.com
"It's not how it is, it is how we see it."
On Sep 8, 2017, at 11:02 AM, Luke Gorrie
<luke(a)snabb.co> wrote:
On 7 August 2017 at 11:02, Andrei Chis <chisvasileandrei(a)gmail.com> wrote:
Hi,
On Mon, Aug 7, 2017 at 9:44 AM, Luke Gorrie <luke(a)snabb.co> wrote:
Hoi,
What is the best way for an object to delegate one or more GTInspector views to other
objects?
I have been using a pattern like this:
gtInspectorFooIn: composite
<gtInspectorPresentationOrder: 5>
otherObject gtInspectorFooIn: composite
This is indeed the normal way of delegating the construction of a view to another object.
Just if otherObject can be nil it might be better to use an accessor that ensures the
object is present. If that's not an option then either add a nil check or use a
dynamic presentation.
Here is the part that I am missing: How do I tell the Inspector that the *value* to
inspect is otherObject instead of self?
I mean, it seems like this code constructs the GLMPresentation for otherObject but then
applies it to self, which may not be compatible.
Maybe I should add 'display: [ otherObject ]' ?
but I am wondering whether there is a better way, and also whether this method is valid
(I've occasionally seen odd behavior, like Inspector panes disappearing after I
"Refresh", and I wonder if I could be somehow confusing the model or if this is
not relevant.)
Should not be relevant. But there can always be a bug. If you find a reproducible case
that would help.
I have not finally tracked down this issue yet but it seems to be related to error cases
e.g. pressing "Abandon" in the debugger. Symptom is that the first pane of the
inspector mysteriously disappears. I will open an issue when I know how to reproduce it.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
www.feenk.com
"Value is always contextual."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
2312
days inactive
2448
days old
5 comments
3 participants
participants (3)
-
Andrei Chis -
Luke Gorrie -
Tudor Girba