so I am enjoying the new Inspector but I have come to a problem. I inspected Smalltalk global variable and has gave me an array with 4000+ items . My problem is that there is no way to quickly scroll those items for example to go forward i have to scroll down and then press next page icon. I think it would be better if the next page icon is always displayed , it does not make sense to me for it to become visible only when I scroll down. Something that would have been following normal GUI behavior it would be just few button presses, now its scroll down to make the next page button visible , then repeat. Very tedious. also if I put "image" in the search box it gives me an MNU UndefinedObject(Object)>>doesNotUnderstand: #ifTrue: GLMTreeMorphModel>>ExecuteUnOptimizedIn: UndefinedObject(Object)>>mustBeBooleanInMagic: UndefinedObject(Object)>>mustBeBoolean [ :each | check := self glamourPresentation searchStrategy value: self inputText value: each item. check ifTrue: [ newSelection add: each path ] ] in GLMTreeMorphModel>>executeSearch in Block: [ :each | ... OrderedCollection>>do: GLMTreeMorphModel>>executeSearch GLMTreeMorphModel>>doSearchOrFilter GLMTreeMorphModel>>inputText: PluggableTextFieldMorph>>acceptTextInModel PluggableTextFieldMorph(PluggableTextMorph)>>acceptBasic PluggableTextFieldMorph>>accept TextMorphForFieldView(TextMorphForEditView)>>acceptContents TextEditor>>accept TextMorphForFieldView(TextMorphForEditView)>>keyStroke: TextMorphForFieldView>>keyStroke: TextMorphForFieldView(TextMorph)>>handleKeystroke: KeyboardEvent>>sentTo: TextMorphForFieldView(Morph)>>handleEvent: TextMorphForFieldView(Morph)>>handleFocusEvent: [ ActiveHand := self. ActiveEvent := anEvent. result := focusHolder handleFocusEvent: (anEvent transformedBy: (focusHolder transformedFrom: self)) ] in HandMorph>>sendFocusEvent:to:clear: in Block: [ ... BlockClosure>>on:do: WorldMorph(PasteUpMorph)>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendKeyboardEvent: HandMorph>>handleEvent: HandMorph>>processEvents [ :h | ActiveHand := h. h processEvents. ActiveHand := nil ] in WorldState>>doOneCycleNowFor: in Block: [ :h | ... Array(SequenceableCollection)>>do:
So I am not the only one grumbling about the scrolling in lists. My suggestion was to use paging for this purpose. See the discussion here on moose-list. https://code.google.com/p/moose-technology/issues/detail?id=1099&can=4&colsp... regards, usman On Thu, Dec 4, 2014 at 11:13 AM, kilon alios <kilon.alios@gmail.com> wrote:
so I am enjoying the new Inspector but I have come to a problem. I inspected Smalltalk global variable and has gave me an array with 4000+ items .
My problem is that there is no way to quickly scroll those items for example to go forward i have to scroll down and then press next page icon. I think it would be better if the next page icon is always displayed , it does not make sense to me for it to become visible only when I scroll down.
Something that would have been following normal GUI behavior it would be just few button presses, now its scroll down to make the next page button visible , then repeat. Very tedious.
also if I put "image" in the search box it gives me an MNU
UndefinedObject(Object)>>doesNotUnderstand: #ifTrue: GLMTreeMorphModel>>ExecuteUnOptimizedIn: UndefinedObject(Object)>>mustBeBooleanInMagic: UndefinedObject(Object)>>mustBeBoolean [ :each | check := self glamourPresentation searchStrategy value: self inputText value: each item. check ifTrue: [ newSelection add: each path ] ] in GLMTreeMorphModel>>executeSearch in Block: [ :each | ... OrderedCollection>>do: GLMTreeMorphModel>>executeSearch GLMTreeMorphModel>>doSearchOrFilter GLMTreeMorphModel>>inputText: PluggableTextFieldMorph>>acceptTextInModel PluggableTextFieldMorph(PluggableTextMorph)>>acceptBasic PluggableTextFieldMorph>>accept TextMorphForFieldView(TextMorphForEditView)>>acceptContents TextEditor>>accept TextMorphForFieldView(TextMorphForEditView)>>keyStroke: TextMorphForFieldView>>keyStroke: TextMorphForFieldView(TextMorph)>>handleKeystroke: KeyboardEvent>>sentTo: TextMorphForFieldView(Morph)>>handleEvent: TextMorphForFieldView(Morph)>>handleFocusEvent: [ ActiveHand := self. ActiveEvent := anEvent. result := focusHolder handleFocusEvent: (anEvent transformedBy: (focusHolder transformedFrom: self)) ] in HandMorph>>sendFocusEvent:to:clear: in Block: [ ... BlockClosure>>on:do: WorldMorph(PasteUpMorph)>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendKeyboardEvent: HandMorph>>handleEvent: HandMorph>>processEvents [ :h | ActiveHand := h. h processEvents. ActiveHand := nil ] in WorldState>>doOneCycleNowFor: in Block: [ :h | ... Array(SequenceableCollection)>>do:
On Thu, Dec 4, 2014 at 11:33 AM, Usman Bhatti <usman.bhatti@gmail.com> wrote:
So I am not the only one grumbling about the scrolling in lists.
Yeah, painful. I want a search box too. But further than that I want to edit values in inspectors. Is there a way? Phil
My suggestion was to use paging for this purpose.
See the discussion here on moose-list.
https://code.google.com/p/moose-technology/issues/detail?id=1099&can=4&colsp...
regards,
usman
On Thu, Dec 4, 2014 at 11:13 AM, kilon alios <kilon.alios@gmail.com> wrote:
so I am enjoying the new Inspector but I have come to a problem. I inspected Smalltalk global variable and has gave me an array with 4000+ items .
My problem is that there is no way to quickly scroll those items for example to go forward i have to scroll down and then press next page icon. I think it would be better if the next page icon is always displayed , it does not make sense to me for it to become visible only when I scroll down.
Something that would have been following normal GUI behavior it would be just few button presses, now its scroll down to make the next page button visible , then repeat. Very tedious.
also if I put "image" in the search box it gives me an MNU
UndefinedObject(Object)>>doesNotUnderstand: #ifTrue: GLMTreeMorphModel>>ExecuteUnOptimizedIn: UndefinedObject(Object)>>mustBeBooleanInMagic: UndefinedObject(Object)>>mustBeBoolean [ :each | check := self glamourPresentation searchStrategy value: self inputText value: each item. check ifTrue: [ newSelection add: each path ] ] in GLMTreeMorphModel>>executeSearch in Block: [ :each | ... OrderedCollection>>do: GLMTreeMorphModel>>executeSearch GLMTreeMorphModel>>doSearchOrFilter GLMTreeMorphModel>>inputText: PluggableTextFieldMorph>>acceptTextInModel PluggableTextFieldMorph(PluggableTextMorph)>>acceptBasic PluggableTextFieldMorph>>accept TextMorphForFieldView(TextMorphForEditView)>>acceptContents TextEditor>>accept TextMorphForFieldView(TextMorphForEditView)>>keyStroke: TextMorphForFieldView>>keyStroke: TextMorphForFieldView(TextMorph)>>handleKeystroke: KeyboardEvent>>sentTo: TextMorphForFieldView(Morph)>>handleEvent: TextMorphForFieldView(Morph)>>handleFocusEvent: [ ActiveHand := self. ActiveEvent := anEvent. result := focusHolder handleFocusEvent: (anEvent transformedBy: (focusHolder transformedFrom: self)) ] in HandMorph>>sendFocusEvent:to:clear: in Block: [ ... BlockClosure>>on:do: WorldMorph(PasteUpMorph)>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendKeyboardEvent: HandMorph>>handleEvent: HandMorph>>processEvents [ :h | ActiveHand := h. h processEvents. ActiveHand := nil ] in WorldState>>doOneCycleNowFor: in Block: [ :h | ... Array(SequenceableCollection)>>do:
On Thu, Dec 4, 2014 at 11:56 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 04 Dec 2014, at 11:45, phil@highoctane.be wrote:
But further than that I want to edit values in inspectors.
Yes !
Is there a way to get back an old trusty inspector on something? (like anObject inspectClassic / anObject exploreClassic) Live yes, but live behind a wall of glass isn't that interactive. Phil
And auto refresh !
Both of these could be depending on presentation, so that heavy presentations can opt out.
Hi, We are working on the edit values. Could you open a ticket in the meantime to not forget about it? As for auto refresh, we will probably have to wait until we get the ability to listen to an individual object. Doru On Thu, Dec 4, 2014 at 11:56 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 04 Dec 2014, at 11:45, phil@highoctane.be wrote:
But further than that I want to edit values in inspectors.
Yes !
And auto refresh !
Both of these could be depending on presentation, so that heavy presentations can opt out.
-- www.tudorgirba.com "Every thing has its own flow"
On 04 Dec 2014, at 14:36, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
We are working on the edit values. Could you open a ticket in the meantime to not forget about it?
Here you go: https://pharo.fogbugz.com/f/cases/14568/GTInspector-should-allow-slots-value...
As for auto refresh, we will probably have to wait until we get the ability to listen to an individual object.
https://pharo.fogbugz.com/f/cases/14569/GTInspector-should-do-live-updates-o... I understand the performance argument, but we had this before and it worked well enough, so it should be possible to bring this back in some form (like maybe only for Raw and Items). BTW, it would also feel like a regression if the solution would be that you have to activate this explicitly...
Doru
On Thu, Dec 4, 2014 at 11:56 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 04 Dec 2014, at 11:45, phil@highoctane.be wrote:
But further than that I want to edit values in inspectors.
Yes !
And auto refresh !
Both of these could be depending on presentation, so that heavy presentations can opt out.
-- www.tudorgirba.com
"Every thing has its own flow"
Sven Van Caekenberghe wrote:
On 04 Dec 2014, at 11:45, phil@highoctane.be wrote:
But further than that I want to edit values in inspectors.
Yes !
And auto refresh !
Both of these could be depending on presentation, so that heavy presentations can opt out.
It would be good if there was some visual indication of which presentations auto-refreshed - like a drop pin looking like its "stuck-in" when not-auto-refreshing. A user might even be able to change the state of the pin, with the just the default dependent on type of presentation. cheers -ben
Hi, in case someone is still interested, a Glamour-Morphic-Brick (extension of morph, that was used to build a Spotter) supports a very large lists. You can try in the latest version: GLMScrollListBrick exampleCollection - to open a list of all classes in the image (each element in the list is a morph). GLMScrollListBrick example - list of 2000 elements GLMScrollListBrick exampleInfinity - list of Float infinity number of elements. if your pharo image is old:
Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'Glamour-Morphic-Brick'; load.
Maybe we will use it instead of default lists in Inspector. Cheers, Alex On Thu, Dec 4, 2014 at 4:04 PM, Ben Coman <btc@openinworld.com> wrote:
Sven Van Caekenberghe wrote:
On 04 Dec 2014, at 11:45, phil@highoctane.be wrote:
But further than that I want to edit values in inspectors.
Yes !
And auto refresh !
Both of these could be depending on presentation, so that heavy presentations can opt out.
It would be good if there was some visual indication of which presentations auto-refreshed - like a drop pin looking like its "stuck-in" when not-auto-refreshing. A user might even be able to change the state of the pin, with the just the default dependent on type of presentation. cheers -ben
I am very interested into Brick, because I am very interesting into anything GUI and graphic wise and I want to push pharo forward in that field with my own efforts as best I can. The scrolling of your examples is actually very smooth. Why the class you use is not available in Moose 5.0 ? Because a moose 5.0 image I have downloaded recently with pharolauncher that it contains GTSpotter yet it does not have the class you use here. On Wed, Dec 10, 2014 at 9:31 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi,
in case someone is still interested, a Glamour-Morphic-Brick (extension of morph, that was used to build a Spotter) supports a very large lists. You can try in the latest version:
GLMScrollListBrick exampleCollection - to open a list of all classes in the image (each element in the list is a morph). GLMScrollListBrick example - list of 2000 elements GLMScrollListBrick exampleInfinity - list of Float infinity number of elements.
if your pharo image is old:
Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'Glamour-Morphic-Brick'; load.
Maybe we will use it instead of default lists in Inspector.
Cheers, Alex
On Thu, Dec 4, 2014 at 4:04 PM, Ben Coman <btc@openinworld.com> wrote:
Sven Van Caekenberghe wrote:
On 04 Dec 2014, at 11:45, phil@highoctane.be wrote:
But further than that I want to edit values in inspectors.
Yes !
And auto refresh !
Both of these could be depending on presentation, so that heavy presentations can opt out.
It would be good if there was some visual indication of which presentations auto-refreshed - like a drop pin looking like its "stuck-in" when not-auto-refreshing. A user might even be able to change the state of the pin, with the just the default dependent on type of presentation. cheers -ben
Hi, Why the class you use is not available in Moose 5.0 ? There were some failing tests, so maybe new classes were not in the build (The latest is Glamour-Morphic-Brick.88) Brick more or less is nothing special. The main idea was to kill morphic layouting mechanism and reimplement it from scratch. Also drawing logic was changed, such that there is no way to draw outside of the parent Brick and to support z-index. But one of the most important feature for us was to have a normal support of paddings and margins (like in css). And all bounds are relative to the parent. Cheers, Alex On Wed, Dec 10, 2014 at 10:31 PM, kilon alios <kilon.alios@gmail.com> wrote:
I am very interested into Brick, because I am very interesting into anything GUI and graphic wise and I want to push pharo forward in that field with my own efforts as best I can.
The scrolling of your examples is actually very smooth.
Why the class you use is not available in Moose 5.0 ? Because a moose 5.0 image I have downloaded recently with pharolauncher that it contains GTSpotter yet it does not have the class you use here.
On Wed, Dec 10, 2014 at 9:31 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi,
in case someone is still interested, a Glamour-Morphic-Brick (extension of morph, that was used to build a Spotter) supports a very large lists. You can try in the latest version:
GLMScrollListBrick exampleCollection - to open a list of all classes in the image (each element in the list is a morph). GLMScrollListBrick example - list of 2000 elements GLMScrollListBrick exampleInfinity - list of Float infinity number of elements.
if your pharo image is old:
Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'Glamour-Morphic-Brick'; load.
Maybe we will use it instead of default lists in Inspector.
Cheers, Alex
On Thu, Dec 4, 2014 at 4:04 PM, Ben Coman <btc@openinworld.com> wrote:
Sven Van Caekenberghe wrote:
On 04 Dec 2014, at 11:45, phil@highoctane.be wrote:
But further than that I want to edit values in inspectors.
Yes !
And auto refresh !
Both of these could be depending on presentation, so that heavy presentations can opt out.
It would be good if there was some visual indication of which presentations auto-refreshed - like a drop pin looking like its "stuck-in" when not-auto-refreshing. A user might even be able to change the state of the pin, with the just the default dependent on type of presentation. cheers -ben
Spotter is cool! I guess the days of Spotlight will now be count. I especially like the search for pragmas, one can easily find the #spotterOrder: examples. When spotting directories is it possible to dive into the contents? Aliaksei Syrel wrote:
and all bounds are relative to the parent.
Mmmhh...would like to see this for all Morphic. If I understood correctly Cuis changed this already for existing Morphic - still dont know how much effort it would mean for Pharo. BTW: the brick list does not react to PAGE-DOWN, PAGE-UP like the regular lists Bye T.
curious how come you guys did not use Spec ? On Thu, Dec 11, 2014 at 12:12 AM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi,
Why the class you use is not available in Moose 5.0 ?
There were some failing tests, so maybe new classes were not in the build (The latest is Glamour-Morphic-Brick.88)
Brick more or less is nothing special. The main idea was to kill morphic layouting mechanism and reimplement it from scratch. Also drawing logic was changed, such that there is no way to draw outside of the parent Brick and to support z-index. But one of the most important feature for us was to have a normal support of paddings and margins (like in css). And all bounds are relative to the parent.
Cheers, Alex
On Wed, Dec 10, 2014 at 10:31 PM, kilon alios <kilon.alios@gmail.com> wrote:
I am very interested into Brick, because I am very interesting into anything GUI and graphic wise and I want to push pharo forward in that field with my own efforts as best I can.
The scrolling of your examples is actually very smooth.
Why the class you use is not available in Moose 5.0 ? Because a moose 5.0 image I have downloaded recently with pharolauncher that it contains GTSpotter yet it does not have the class you use here.
On Wed, Dec 10, 2014 at 9:31 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi,
in case someone is still interested, a Glamour-Morphic-Brick (extension of morph, that was used to build a Spotter) supports a very large lists. You can try in the latest version:
GLMScrollListBrick exampleCollection - to open a list of all classes in the image (each element in the list is a morph). GLMScrollListBrick example - list of 2000 elements GLMScrollListBrick exampleInfinity - list of Float infinity number of elements.
if your pharo image is old:
Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'Glamour-Morphic-Brick'; load.
Maybe we will use it instead of default lists in Inspector.
Cheers, Alex
On Thu, Dec 4, 2014 at 4:04 PM, Ben Coman <btc@openinworld.com> wrote:
Sven Van Caekenberghe wrote:
On 04 Dec 2014, at 11:45, phil@highoctane.be wrote:
But further than that I want to edit values in inspectors.
Yes !
And auto refresh !
Both of these could be depending on presentation, so that heavy presentations can opt out.
It would be good if there was some visual indication of which presentations auto-refreshed - like a drop pin looking like its "stuck-in" when not-auto-refreshing. A user might even be able to change the state of the pin, with the just the default dependent on type of presentation. cheers -ben
Because we wanted to be both fast and flexible. Doru On Thu, Dec 11, 2014 at 12:03 PM, kilon alios <kilon.alios@gmail.com> wrote:
curious how come you guys did not use Spec ?
On Thu, Dec 11, 2014 at 12:12 AM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi,
Why the class you use is not available in Moose 5.0 ?
There were some failing tests, so maybe new classes were not in the build (The latest is Glamour-Morphic-Brick.88)
Brick more or less is nothing special. The main idea was to kill morphic layouting mechanism and reimplement it from scratch. Also drawing logic was changed, such that there is no way to draw outside of the parent Brick and to support z-index. But one of the most important feature for us was to have a normal support of paddings and margins (like in css). And all bounds are relative to the parent.
Cheers, Alex
On Wed, Dec 10, 2014 at 10:31 PM, kilon alios <kilon.alios@gmail.com> wrote:
I am very interested into Brick, because I am very interesting into anything GUI and graphic wise and I want to push pharo forward in that field with my own efforts as best I can.
The scrolling of your examples is actually very smooth.
Why the class you use is not available in Moose 5.0 ? Because a moose 5.0 image I have downloaded recently with pharolauncher that it contains GTSpotter yet it does not have the class you use here.
On Wed, Dec 10, 2014 at 9:31 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi,
in case someone is still interested, a Glamour-Morphic-Brick (extension of morph, that was used to build a Spotter) supports a very large lists. You can try in the latest version:
GLMScrollListBrick exampleCollection - to open a list of all classes in the image (each element in the list is a morph). GLMScrollListBrick example - list of 2000 elements GLMScrollListBrick exampleInfinity - list of Float infinity number of elements.
if your pharo image is old:
Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'Glamour-Morphic-Brick'; load.
Maybe we will use it instead of default lists in Inspector.
Cheers, Alex
On Thu, Dec 4, 2014 at 4:04 PM, Ben Coman <btc@openinworld.com> wrote:
Sven Van Caekenberghe wrote:
On 04 Dec 2014, at 11:45, phil@highoctane.be wrote:
But further than that I want to edit values in inspectors.
Yes !
And auto refresh !
Both of these could be depending on presentation, so that heavy presentations can opt out.
It would be good if there was some visual indication of which presentations auto-refreshed - like a drop pin looking like its "stuck-in" when not-auto-refreshing. A user might even be able to change the state of the pin, with the just the default dependent on type of presentation. cheers -ben
-- www.tudorgirba.com "Every thing has its own flow"
I am not a fan of Spec myself design wise, obviously Spec is useful, I really like Morphic and I really like your idea of making small extensions to Morphic to make it more easy to deal with . On Thu, Dec 11, 2014 at 1:28 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Because we wanted to be both fast and flexible.
Doru
On Thu, Dec 11, 2014 at 12:03 PM, kilon alios <kilon.alios@gmail.com> wrote:
curious how come you guys did not use Spec ?
On Thu, Dec 11, 2014 at 12:12 AM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi,
Why the class you use is not available in Moose 5.0 ?
There were some failing tests, so maybe new classes were not in the build (The latest is Glamour-Morphic-Brick.88)
Brick more or less is nothing special. The main idea was to kill morphic layouting mechanism and reimplement it from scratch. Also drawing logic was changed, such that there is no way to draw outside of the parent Brick and to support z-index. But one of the most important feature for us was to have a normal support of paddings and margins (like in css). And all bounds are relative to the parent.
Cheers, Alex
On Wed, Dec 10, 2014 at 10:31 PM, kilon alios <kilon.alios@gmail.com> wrote:
I am very interested into Brick, because I am very interesting into anything GUI and graphic wise and I want to push pharo forward in that field with my own efforts as best I can.
The scrolling of your examples is actually very smooth.
Why the class you use is not available in Moose 5.0 ? Because a moose 5.0 image I have downloaded recently with pharolauncher that it contains GTSpotter yet it does not have the class you use here.
On Wed, Dec 10, 2014 at 9:31 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi,
in case someone is still interested, a Glamour-Morphic-Brick (extension of morph, that was used to build a Spotter) supports a very large lists. You can try in the latest version:
GLMScrollListBrick exampleCollection - to open a list of all classes in the image (each element in the list is a morph). GLMScrollListBrick example - list of 2000 elements GLMScrollListBrick exampleInfinity - list of Float infinity number of elements.
if your pharo image is old:
Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'Glamour-Morphic-Brick'; load.
Maybe we will use it instead of default lists in Inspector.
Cheers, Alex
On Thu, Dec 4, 2014 at 4:04 PM, Ben Coman <btc@openinworld.com> wrote:
Sven Van Caekenberghe wrote:
On 04 Dec 2014, at 11:45, phil@highoctane.be wrote:
But further than that I want to edit values in inspectors.
Yes !
And auto refresh !
Both of these could be depending on presentation, so that heavy presentations can opt out.
It would be good if there was some visual indication of which presentations auto-refreshed - like a drop pin looking like its "stuck-in" when not-auto-refreshing. A user might even be able to change the state of the pin, with the just the default dependent on type of presentation. cheers -ben
-- www.tudorgirba.com
"Every thing has its own flow"
Alain is doing something similar in Bloc. He will show you that in January. Stef
Hi,
Why the class you use is not available in Moose 5.0 ?
There were some failing tests, so maybe new classes were not in the build (The latest is Glamour-Morphic-Brick.88)
Brick more or less is nothing special. The main idea was to kill morphic layouting mechanism and reimplement it from scratch. Also drawing logic was changed, such that there is no way to draw outside of the parent Brick and to support z-index. But one of the most important feature for us was to have a normal support of paddings and margins (like in css). And all bounds are relative to the parent.
Cheers, Alex
On Wed, Dec 10, 2014 at 10:31 PM, kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote:
I am very interested into Brick, because I am very interesting into anything GUI and graphic wise and I want to push pharo forward in that field with my own efforts as best I can.
The scrolling of your examples is actually very smooth.
Why the class you use is not available in Moose 5.0 ? Because a moose 5.0 image I have downloaded recently with pharolauncher that it contains GTSpotter yet it does not have the class you use here.
On Wed, Dec 10, 2014 at 9:31 PM, Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@gmail.com>> wrote:
Hi,
in case someone is still interested, a Glamour-Morphic-Brick (extension of morph, that was used to build a Spotter) supports a very large lists. You can try in the latest version:
GLMScrollListBrick exampleCollection - to open a list of all classes in the image (each element in the list is a morph). GLMScrollListBrick example - list of 2000 elements GLMScrollListBrick exampleInfinity - list of Float infinity number of elements.
if your pharo image is old:
Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'Glamour-Morphic-Brick'; load.
Maybe we will use it instead of default lists in Inspector.
Cheers, Alex
On Thu, Dec 4, 2014 at 4:04 PM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:
Sven Van Caekenberghe wrote:
On 04 Dec 2014, at 11:45, phil@highoctane.be <mailto:phil@highoctane.be> wrote:
But further than that I want to edit values in inspectors.
Yes !
And auto refresh !
Both of these could be depending on presentation, so that heavy presentations can opt out.
It would be good if there was some visual indication of which presentations auto-refreshed - like a drop pin looking like its "stuck-in" when not-auto-refreshing. A user might even be able to change the state of the pin, with the just the default dependent on type of presentation. cheers -ben
"So I am not the only one grumbling about the scrolling in lists. My suggestion was to use paging for this purpose. See the discussion here on moose-list. https://code.google.com/p/moose-technology/issues/detail?id=1099&can=4&colsp... regards, usman " I cannot understand your problem and your solution to it. I am afraid I am not familiar with the library you use or with GTInspector. If I could assume I would say you dont like the continuous scroll solution currently implemented in GTInspector but that is not my problem. My problem is that next 50 items icon button disappears each time I press it and for me that makes no sense. Without changing the current implementation at a fundamental level the button should be always visible and allow you to press it multiple times and send you to the last first of 50. So if I press it lets say 4 times, it will be nice if it would send the cursor of the list display to the item 200 and the list be able to scroll down to 250 assuming that the list was already at cursor 1 displaying 50 items.
On Thu, Dec 4, 2014 at 11:56 AM, kilon alios <kilon.alios@gmail.com> wrote:
"So I am not the only one grumbling about the scrolling in lists. My suggestion was to use paging for this purpose.
See the discussion here on moose-list.
https://code.google.com/p/moose-technology/issues/detail?id=1099&can=4&colsp...
regards,
usman "
I cannot understand your problem and your solution to it. I am afraid I am not familiar with the library you use or with GTInspector. If I could assume I would say you dont like the continuous scroll solution currently implemented in GTInspector but that is not my problem.
My problem is that next 50 items icon button disappears each time I press it and for me that makes no sense. Without changing the current implementation at a fundamental level the button should be always visible and allow you to press it multiple times and send you to the last first of 50. So if I press it lets say 4 times, it will be nice if it would send the cursor of the list display to the item 200 and the list be able to scroll down to 250 assuming that the list was already at cursor 1 displaying 50 items.
Did you try this script in the discussion that shows the other possibility of list scrolling in Morph without talking about GT-*: This covers your requirement of omnipresent buttons and a list showing a fix number of items (in your case 50). | treeMorph aWindow aModel | aModel := PaginatedMorphTreeModel new rootItems: (1 to: 100) asArray. aWindow := aModel theme newWindowIn: World for: aModel title: 'test'. treeMorph := aModel defaultTreeMorph. treeMorph pageSize: 30. treeMorph buildContents. aWindow addMorph: treeMorph fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1) offsets: (0 @ 0 corner: 0 @ 0)). aWindow open. aModel expandItemPath: {50}.
"Did you try this script in the discussion that shows the other possibility of list scrolling in Morph without talking about GT-*: This covers your requirement of omnipresent buttons and a list showing a fix number of items (in your case 50)." I did try but was giving me an error . The code you provide here works. Yes its as I assumed you want to go down the route of pages, but as I said again its not related to my issue. Yes I really like your solution. I wonder why Tudor prefer continuous scroll , is there any advantage ? Just a side note here even paging is very limited and unsuitable for big data, I think in the end a search facility on steroids would be an ideal solution, possible one supporting regex like finder tool already does.
Hi Kilon, We started to explore a new list implementation that is more scalable and whose goal is to support smooth scrolling, but it will take a while. Until then, you can still increase the paging size (the 50 is editable). Cheers, Doru On Thu, Dec 4, 2014 at 12:15 PM, kilon alios <kilon.alios@gmail.com> wrote:
"Did you try this script in the discussion that shows the other possibility of list scrolling in Morph without talking about GT-*: This covers your requirement of omnipresent buttons and a list showing a fix number of items (in your case 50)."
I did try but was giving me an error . The code you provide here works. Yes its as I assumed you want to go down the route of pages, but as I said again its not related to my issue.
Yes I really like your solution. I wonder why Tudor prefer continuous scroll , is there any advantage ?
Just a side note here even paging is very limited and unsuitable for big data, I think in the end a search facility on steroids would be an ideal solution, possible one supporting regex like finder tool already does.
-- www.tudorgirba.com "Every thing has its own flow"
On Thu, Dec 4, 2014 at 12:15 PM, kilon alios <kilon.alios@gmail.com> wrote:
"Did you try this script in the discussion that shows the other possibility of list scrolling in Morph without talking about GT-*: This covers your requirement of omnipresent buttons and a list showing a fix number of items (in your case 50)."
I did try but was giving me an error . The code you provide here works. Yes its as I assumed you want to go down the route of pages, but as I said again its not related to my issue.
Yes I really like your solution. I wonder why Tudor prefer continuous scroll , is there any advantage ?
Just a side note here even paging is very limited and unsuitable for big data, I think in the end a search facility on steroids would be an ideal solution, possible one supporting regex like finder tool already does.
It is already possible to search in lists by sending filterOn:/searchOn: message to the list presentation in Glamour. An example: | finder | finder := GLMFinder new. finder show: [:a | a list beMultiple; title: 'Simple'. a list title: 'With filter'; beMultiple; filterOn: [:text :each | (Smalltalk evaluate: '[:each | ', text, ']') value: each]; helpMessage: 'Enter a filtering request (e.g., "each > 10")'. a list title: 'With search'; beMultiple; searchOn: [:text :each | (Smalltalk evaluate: '[:each | ', text, ']') value: each]; helpMessage: 'Enter a search request (e.g., "each > 10")' ]. ^ finder openOn: (1 to: 100)
Hi, I think Kilon refers to the search in the Items presentation of a collection. If so, that search field accepts a Pharo expression of the form: each isMatchingSomething In that case, this will translate in self select: [:each | each isMatchingSomething] If you hover with the mouse over the search input you should get this info. Cheers, Doru On Thu, Dec 4, 2014 at 12:26 PM, Usman Bhatti <usman.bhatti@gmail.com> wrote:
On Thu, Dec 4, 2014 at 12:15 PM, kilon alios <kilon.alios@gmail.com> wrote:
"Did you try this script in the discussion that shows the other possibility of list scrolling in Morph without talking about GT-*: This covers your requirement of omnipresent buttons and a list showing a fix number of items (in your case 50)."
I did try but was giving me an error . The code you provide here works. Yes its as I assumed you want to go down the route of pages, but as I said again its not related to my issue.
Yes I really like your solution. I wonder why Tudor prefer continuous scroll , is there any advantage ?
Just a side note here even paging is very limited and unsuitable for big data, I think in the end a search facility on steroids would be an ideal solution, possible one supporting regex like finder tool already does.
It is already possible to search in lists by sending filterOn:/searchOn: message to the list presentation in Glamour. An example: | finder | finder := GLMFinder new. finder show: [:a | a list beMultiple; title: 'Simple'. a list title: 'With filter'; beMultiple; filterOn: [:text :each | (Smalltalk evaluate: '[:each | ', text, ']') value: each]; helpMessage: 'Enter a filtering request (e.g., "each > 10")'. a list title: 'With search'; beMultiple; searchOn: [:text :each | (Smalltalk evaluate: '[:each | ', text, ']') value: each]; helpMessage: 'Enter a search request (e.g., "each > 10")' ]. ^ finder openOn: (1 to: 100)
-- www.tudorgirba.com "Every thing has its own flow"
"In that case, this will translate in self select: [:each | each isMatchingSomething]" ah ok, I see, so it does not search based on a string but based on expression.
In that presentation, yes. Doru On Thu, Dec 4, 2014 at 1:09 PM, kilon alios <kilon.alios@gmail.com> wrote:
"In that case, this will translate in self select: [:each | each isMatchingSomething]"
ah ok, I see, so it does not search based on a string but based on expression.
-- www.tudorgirba.com "Every thing has its own flow"
thanks Doru and keep the awesome job. You guys really improved the inspector feature wise, I love to see efforts to modernize Smalltalk :) On Thu, Dec 4, 2014 at 2:15 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
In that presentation, yes.
Doru
On Thu, Dec 4, 2014 at 1:09 PM, kilon alios <kilon.alios@gmail.com> wrote:
"In that case, this will translate in self select: [:each | each isMatchingSomething]"
ah ok, I see, so it does not search based on a string but based on expression.
-- www.tudorgirba.com
"Every thing has its own flow"
participants (9)
-
Aliaksei Syrel -
Ben Coman -
kilon alios -
phil＠highoctane.be -
stepharo -
Sven Van Caekenberghe -
Torsten Bergmann -
Tudor Girba -
Usman Bhatti