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

Re: [Pharo-dev] Confused about the GTInspector State Tab

by Marcus Denker

On 01 Oct 2014, at 15:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I am confused about the GTInspector State tab. What is its definition ? > > I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views. > > Why then does it not show all variable content and only named variables ? > > Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all. > > How can I inspect an individual character of a String ? Or an individual byte ? > > Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view. > > In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing. > > I could propose changes or a slice, but I think we should agree on the definition of 'State' first. > I think this is just a matter of iterating, e.g. Dictionary has it already correct: State show the raw state (array, tally), while the âitemsâ view shows nicely key->values. an example where it fails is CompiledMethod, it has a Bytecode view, but in addition a (virtual) âall byte codesâ variable in the raw view. (and more). I think we need -> the raw state for every object (like the old basic inspector) -> this might not be the default view for all objects, though. (the default should present something useful). This means, maybe having the notion of a default view would be nice. -> work to add more views to everything interesting. Marcus

Oct. 1, 2014

Re: [Pharo-dev] GTPlayground Play Button Semantics

by Esteban Lorenzano

so far, we want to keep cmd+o to open tools. then what about cmd+g for âcmd+goâ (and as Guille says, an internal joke for âcmd+gDoitâ) :P Esteban > On 01 Oct 2014, at 16:15, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > If we want to keep cmd+o for opening the tools then it make sense to use cmd+e. > Just it could be a little confusing because cmd+e was already user before to open the explorer. > > We wanted a new shortcut to avoid this confusion. But I am not against using cmd+e > > On Wed, Oct 1, 2014 at 4:06 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > and btw, what about remap cmd+o to cmd+e (like âexecuteâ) ? > > Esteban > > >> On 01 Oct 2014, at 16:05, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >> >> >> On 01 Oct 2014, at 16:00, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: >> >>> >>> >>> On Wed, Oct 1, 2014 at 3:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >>> Was it a conscious decision to make the GTPlayground Play button act as 'play all' (evaluate the whole workspace contents) ? >>> >>> If so, why ? >>> >>> I find it quite limiting that I cannot select some expression and 'play it'. A workspace/playground is like a notebook containing lots of different things. >>> >>> >>> Yes, it is like this by design. The Play button at the top evaluates the entire content of the workspace. >>> >>> To evaluate just an expression you can select it and choose 'Open' from the context menu, or use CMD+o. >>> Just right now CMD+o is still broken due to the global shortcuts from opening tools. >>> >>> The Play button at the top works like that as we tried to have in the toolbar only global actions that apply on the entire presentations and not only on the selection. >>> Those that apply on the selection go in the context menu and should have keybindings >>> >>> Does this seem ok to you? >> >> Ah, I thought the open menu action worked like the inspect it menu action. >> OK, that works for me. >> >> Thanks. >> >>> Cheers, >>> Andrei >>> >>> >>> Sven > >

Oct. 1, 2014

Re: [Pharo-dev] GTPlayground Play Button Semantics

by Andrei Chis

If we want to keep cmd+o for opening the tools then it make sense to use cmd+e. Just it could be a little confusing because cmd+e was already user before to open the explorer. We wanted a new shortcut to avoid this confusion. But I am not against using cmd+e On Wed, Oct 1, 2014 at 4:06 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > and btw, what about remap cmd+o to cmd+e (like âexecuteâ) ? > > Esteban > > > On 01 Oct 2014, at 16:05, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 01 Oct 2014, at 16:00, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > > > On Wed, Oct 1, 2014 at 3:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > Was it a conscious decision to make the GTPlayground Play button act as > 'play all' (evaluate the whole workspace contents) ? > > If so, why ? > > I find it quite limiting that I cannot select some expression and 'play > it'. A workspace/playground is like a notebook containing lots of different > things. > > > Yes, it is like this by design. The Play button at the top evaluates the > entire content of the workspace. > > To evaluate just an expression you can select it and choose 'Open' from > the context menu, or use CMD+o. > Just right now CMD+o is still broken due to the global shortcuts from > opening tools. > > The Play button at the top works like that as we tried to have in the > toolbar only global actions that apply on the entire presentations and not > only on the selection. > Those that apply on the selection go in the context menu and should have > keybindings > > Does this seem ok to you? > > > Ah, I thought the open menu action worked like the inspect it menu action. > OK, that works for me. > > Thanks. > > Cheers, > Andrei > > > Sven > > >

Oct. 1, 2014

Re: [Pharo-dev] GTPlayground Play Button Semantics

by Esteban Lorenzano

and btw, what about remap cmd+o to cmd+e (like âexecuteâ) ? Esteban > On 01 Oct 2014, at 16:05, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 01 Oct 2014, at 16:00, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: > >> >> >> On Wed, Oct 1, 2014 at 3:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Was it a conscious decision to make the GTPlayground Play button act as 'play all' (evaluate the whole workspace contents) ? >> >> If so, why ? >> >> I find it quite limiting that I cannot select some expression and 'play it'. A workspace/playground is like a notebook containing lots of different things. >> >> >> Yes, it is like this by design. The Play button at the top evaluates the entire content of the workspace. >> >> To evaluate just an expression you can select it and choose 'Open' from the context menu, or use CMD+o. >> Just right now CMD+o is still broken due to the global shortcuts from opening tools. >> >> The Play button at the top works like that as we tried to have in the toolbar only global actions that apply on the entire presentations and not only on the selection. >> Those that apply on the selection go in the context menu and should have keybindings >> >> Does this seem ok to you? > > Ah, I thought the open menu action worked like the inspect it menu action. > OK, that works for me. > > Thanks. > >> Cheers, >> Andrei >> >> >> Sven

Oct. 1, 2014

Re: [Pharo-dev] GTPlayground Play Button Semantics

by Sven Van Caekenberghe

On 01 Oct 2014, at 16:00, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > > On Wed, Oct 1, 2014 at 3:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Was it a conscious decision to make the GTPlayground Play button act as 'play all' (evaluate the whole workspace contents) ? > > If so, why ? > > I find it quite limiting that I cannot select some expression and 'play it'. A workspace/playground is like a notebook containing lots of different things. > > > Yes, it is like this by design. The Play button at the top evaluates the entire content of the workspace. > > To evaluate just an expression you can select it and choose 'Open' from the context menu, or use CMD+o. > Just right now CMD+o is still broken due to the global shortcuts from opening tools. > > The Play button at the top works like that as we tried to have in the toolbar only global actions that apply on the entire presentations and not only on the selection. > Those that apply on the selection go in the context menu and should have keybindings > > Does this seem ok to you? Ah, I thought the open menu action worked like the inspect it menu action. OK, that works for me. Thanks. > Cheers, > Andrei > > > Sven > > >

Oct. 1, 2014

Re: [Pharo-dev] GTPlayground Play Button Semantics

by Damien Cassou

On Wed, Oct 1, 2014 at 4:00 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Does this seem ok to you? makes perfect sense to me. Toolbar is for global stuff, context menu for contextual stuff. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Oct. 1, 2014

Re: [Pharo-dev] Confused about the GTInspector State Tab

by Sven Van Caekenberghe

But we cannot all start doing different things, right ? There should be some design and structure, that is why I am asking. On 01 Oct 2014, at 15:59, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > cool thing of this new inspector is that is super easy to extend with what you want > So wouldnât be complicated to add that functionality :) > > Esteban > > >> On 01 Oct 2014, at 15:51, Ben Coman <btc(a)openInWorld.com> wrote: >> >> Sven Van Caekenberghe wrote: >>> I am confused about the GTInspector State tab. What is its definition ? >>> I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views. >>> Why then does it not show all variable content and only named variables ? >>> Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all. >>> How can I inspect an individual character of a String ? Or an individual byte ? >>> Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view. >>> In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing. >>> I could propose changes or a slice, but I think we should agree on the definition of 'State' first. >>> Sven >> >> If its a raw slots view you want, >> maybe that tab should be called 'Slots' ? >> cheers -ben >> > >

Oct. 1, 2014

Re: [Pharo-dev] GTPlayground Play Button Semantics

by Andrei Chis

On Wed, Oct 1, 2014 at 3:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Was it a conscious decision to make the GTPlayground Play button act as > 'play all' (evaluate the whole workspace contents) ? > > If so, why ? > > I find it quite limiting that I cannot select some expression and 'play > it'. A workspace/playground is like a notebook containing lots of different > things. > Yes, it is like this by design. The Play button at the top evaluates the entire content of the workspace. To evaluate just an expression you can select it and choose 'Open' from the context menu, or use CMD+o. Just right now CMD+o is still broken due to the global shortcuts from opening tools. The Play button at the top works like that as we tried to have in the toolbar only global actions that apply on the entire presentations and not only on the selection. Those that apply on the selection go in the context menu and should have keybindings Does this seem ok to you? Cheers, Andrei > > Sven > > >

Oct. 1, 2014

Re: [Pharo-dev] Confused about the GTInspector State Tab

by Esteban Lorenzano

cool thing of this new inspector is that is super easy to extend with what you want So wouldnât be complicated to add that functionality :) Esteban > On 01 Oct 2014, at 15:51, Ben Coman <btc(a)openInWorld.com> wrote: > > Sven Van Caekenberghe wrote: >> I am confused about the GTInspector State tab. What is its definition ? >> I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views. >> Why then does it not show all variable content and only named variables ? >> Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all. >> How can I inspect an individual character of a String ? Or an individual byte ? >> Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view. >> In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing. >> I could propose changes or a slice, but I think we should agree on the definition of 'State' first. >> Sven > > If its a raw slots view you want, > maybe that tab should be called 'Slots' ? > cheers -ben >

Oct. 1, 2014

Re: [Pharo-dev] Confused about the GTInspector State Tab

by Ben Coman

Sven Van Caekenberghe wrote: > I am confused about the GTInspector State tab. What is its definition ? > > I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views. > > Why then does it not show all variable content and only named variables ? > > Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all. > > How can I inspect an individual character of a String ? Or an individual byte ? > > Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view. > > In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing. > > I could propose changes or a slice, but I think we should agree on the definition of 'State' first. > > Sven > > > If its a raw slots view you want, maybe that tab should be called 'Slots' ? cheers -ben

Oct. 1, 2014