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

Re: [Pharo-dev] About icon: and iconNamed:

by Ben Coman

On Thu, Oct 13, 2016 at 10:00 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Also look at #systemIcon method which define icon of class in browser. > All implementors dublicate "Smalltalk ui icons iconNamed: #myIconName". > > Should we change it to #systemIconName? > > Also think about remote browser which also wants to show icons over > classes. With icon name it is not problem to transfer it together with > class. With Form it is of course much expensive. > Is most of that expense come from passing the same Form over a link multiple times? I vaguely wonder if content-addressable caching would help there. But anyway, wouldn't a remote browser work at a higher level that being a remote UI? and the user want to use their local theme rather than that from the remote image? cheers -ben > > > 2016-10-13 14:45 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> So I'm trying to think ;) >> >> menuOn: aBuilder >> "Specify the menu used when writing text." >> <contextMenu> >> <RubLineNumberMenu> >> (aBuilder item: #'Find...' translated) >> keyText: 'f'; >> selector: #find; >> icon: (Smalltalk ui icons iconNamed: #smallFindIcon) >> >> ====> >> >> menuOn: aBuilder >> "Specify the menu used when writing text." >> <contextMenu> >> <RubLineNumberMenu> >> (aBuilder item: #'Find...' translated) >> keyText: 'f'; >> selector: #find; >> icon: #smallFindIcon >> >> Now I do not really like to have a symbol or an icon. >> >> icon: aSymbol >> >> aSymbol asIcon but we could have the provider >> >> So for now I will finish the effort. >> >> have >> >> icon: anIcon and >> >> iconNamed: >> >> >> Stef >> >> On Oct 13, 2016, at 1:03 PM, stepharo <stepharo(a)free.fr> wrote: >> >> >> Thanks! >> >> Just a question: How about adding an extension >> >> Symbol>>asIcon >> ^ â¦ look up the icon >> >> Form>>asIcon >> ^ self >> >> >> what if you want to have side by side two different themes to compare the >> best icons >> choices? >> >> >> This is a valid concern, but I do not understand how this would work if >> the only thing you pass in iconName: is just one symbol: >> >> act: aBlock iconName: *aSymbol* entitled: aString >> >> So there needs to be a lookup. This lookup will depend on the current >> icon theme. So, you could open on window with one theme, switch the theme >> and then open another window. Or did I misunderstand something? >> >> My idea was that we leave the public API of Glamour to be: >> >> act: aBlock icon: *aSymbolOrForm* entitled: aString >> >> and then if you want to play with things, you can also explicitly pass >> one icon or another (beside relying on the default lookup behavior). >> >> What do you think? >> >> Doru >> >> >> >> In this way we do not have to change the external interface, and only the >> internal implementation has to send an âasIconâ before using it? >> >> Cheers, >> Doru >> >> >> >> On Oct 12, 2016, at 10:33 PM, stepharo <stepharo(a)free.fr> wrote: >> >> I'm adding >> >> act: aBlock iconName: aSymbol entitled: aString >> self act: aBlock icon: (self iconNamed: aSymbol) entitled: aString >> >> and >> >> act: aBlock iconName: aSymbol on: aCharacter entitled: aString >> self act: aBlock icon: (self iconNamed: aSymbol) on: aCharacter >> entitled: aString >> >> and others .... >> >>

Oct. 13, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Denis Kudriashov

Also look at #systemIcon method which define icon of class in browser. All implementors dublicate "Smalltalk ui icons iconNamed: #myIconName". Should we change it to #systemIconName? Also think about remote browser which also wants to show icons over classes. With icon name it is not problem to transfer it together with class. With Form it is of course much expensive. 2016-10-13 14:45 GMT+02:00 stepharo <stepharo(a)free.fr>: > So I'm trying to think ;) > > menuOn: aBuilder > "Specify the menu used when writing text." > <contextMenu> > <RubLineNumberMenu> > (aBuilder item: #'Find...' translated) > keyText: 'f'; > selector: #find; > icon: (Smalltalk ui icons iconNamed: #smallFindIcon) > > ====> > > menuOn: aBuilder > "Specify the menu used when writing text." > <contextMenu> > <RubLineNumberMenu> > (aBuilder item: #'Find...' translated) > keyText: 'f'; > selector: #find; > icon: #smallFindIcon > > Now I do not really like to have a symbol or an icon. > > icon: aSymbol > > aSymbol asIcon but we could have the provider > > So for now I will finish the effort. > > have > > icon: anIcon and > > iconNamed: > > > Stef > > On Oct 13, 2016, at 1:03 PM, stepharo <stepharo(a)free.fr> wrote: > > > Thanks! > > Just a question: How about adding an extension > > Symbol>>asIcon > ^ â¦ look up the icon > > Form>>asIcon > ^ self > > > what if you want to have side by side two different themes to compare the > best icons > choices? > > > This is a valid concern, but I do not understand how this would work if > the only thing you pass in iconName: is just one symbol: > > act: aBlock iconName: *aSymbol* entitled: aString > > So there needs to be a lookup. This lookup will depend on the current icon > theme. So, you could open on window with one theme, switch the theme and > then open another window. Or did I misunderstand something? > > My idea was that we leave the public API of Glamour to be: > > act: aBlock icon: *aSymbolOrForm* entitled: aString > > and then if you want to play with things, you can also explicitly pass one > icon or another (beside relying on the default lookup behavior). > > What do you think? > > Doru > > > > In this way we do not have to change the external interface, and only the > internal implementation has to send an âasIconâ before using it? > > Cheers, > Doru > > > > On Oct 12, 2016, at 10:33 PM, stepharo <stepharo(a)free.fr> wrote: > > I'm adding > > act: aBlock iconName: aSymbol entitled: aString > self act: aBlock icon: (self iconNamed: aSymbol) entitled: aString > > and > > act: aBlock iconName: aSymbol on: aCharacter entitled: aString > self act: aBlock icon: (self iconNamed: aSymbol) on: aCharacter > entitled: aString > > and others .... > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing has its own flow." > > > > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "We are all great at making mistakes." > > > > > > > > > >

Oct. 13, 2016

itemIcon: and Spotter

by stepharo

Doru It would be nice to take some action here too. I would like to remove the Smalltalk ui icons iconNamed: spotterMonticelloWorkingCopyFor: aStep <spotterOrder: 1> aStep listProcessor title: 'Monticello Working Copy'; allCandidates: [ Array with: self workingCopy ]; itemIcon: [ Smalltalk ui icons iconNamed: #versionControlIcon ]; filter: GTFilterSubstring

Oct. 13, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by stepharo

So I'm trying to think ;) menuOn: aBuilder "Specify the menu used when writing text." <contextMenu> <RubLineNumberMenu> (aBuilder item: #'Find...' translated) keyText: 'f'; selector: #find; icon: (Smalltalk ui icons iconNamed: #smallFindIcon) ====> menuOn: aBuilder "Specify the menu used when writing text." <contextMenu> <RubLineNumberMenu> (aBuilder item: #'Find...' translated) keyText: 'f'; selector: #find; icon: #smallFindIcon Now I do not really like to have a symbol or an icon. icon: aSymbol aSymbol asIcon but we could have the provider So for now I will finish the effort. have icon: anIcon and iconNamed: Stef >> On Oct 13, 2016, at 1:03 PM, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> >>> Thanks! >>> >>> Just a question: How about adding an extension >>> >>> Symbol>>asIcon >>> ^ â¦ look up the icon >>> >>> Form>>asIcon >>> ^ self >> >> what if you want to have side by side two different themes to compare >> the best icons >> choices? > > This is a valid concern, but I do not understand how this would work > if the only thing you pass in iconName: is just one symbol: > > act: aBlock iconName: *aSymbol* entitled: aString > > So there needs to be a lookup. This lookup will depend on the current > icon theme. So, you could open on window with one theme, switch the > theme and then open another window. Or did I misunderstand something? > > My idea was that we leave the public API of Glamour to be: > > act: aBlock icon: *aSymbolOrForm* entitled: aString > > and then if you want to play with things, you can also explicitly pass > one icon or another (beside relying on the default lookup behavior). > > What do you think? > > Doru > >> >>> >>> In this way we do not have to change the external interface, and >>> only the internal implementation has to send an âasIconâ before >>> using it? >>> >>> Cheers, >>> Doru >>> >>> >>> >>>> On Oct 12, 2016, at 10:33 PM, stepharo <stepharo(a)free.fr >>>> <mailto:stepharo@free.fr>> wrote: >>>> >>>> I'm adding >>>> >>>> act: aBlock iconName: aSymbol entitled: aString >>>> self act: aBlock icon: (self iconNamed: aSymbol) entitled: aString >>>> >>>> and >>>> >>>> act: aBlock iconName: aSymbol on: aCharacter entitled: aString >>>> self act: aBlock icon: (self iconNamed: aSymbol) on: aCharacter >>>> entitled: aString >>>> >>>> and others .... >>>> >>> -- >>> www.tudorgirba.com <http://www.tudorgirba.com> >>> www.feenk.com >>> >>> "Every thing has its own flow." >>> >>> >>> >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com > > "We are all great at making mistakes." > > > > > > > >

Oct. 13, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by stepharo

So I'm trying to think menuOn: aBuilder "Specify the menu used when writing text." <contextMenu> <RubLineNumberMenu> (aBuilder item: #'Find...' translated) keyText: 'f'; selector: #find; icon: (Smalltalk ui icons iconNamed: #smallFindIcon) ====> menuOn: aBuilder "Specify the menu used when writing text." <contextMenu> <RubLineNumberMenu> (aBuilder item: #'Find...' translated) keyText: 'f'; selector: #find; icon: #smallFindIcon Now I do not really like to pass a symbol. icon: aSymbol aSymbol asIcon But we cannot plug a provider So for now I would like to continue Stef >> what if you want to have side by side two different themes to compare >> the best icons >> choices? > > This is a valid concern, but I do not understand how this would work > if the only thing you pass in iconName: is just one symbol: > > act: aBlock iconName: *aSymbol* entitled: aString > > So there needs to be a lookup. This lookup will depend on the current > icon theme. So, you could open on window with one theme, switch the > theme and then open another window. Or did I misunderstand something? > > My idea was that we leave the public API of Glamour to be: > > act: aBlock icon: *aSymbolOrForm* entitled: aString > > and then if you want to play with things, you can also explicitly pass > one icon or another (beside relying on the default lookup behavior). > > What do you think? > > Doru > >> >>> >>> In this way we do not have to change the external interface, and >>> only the internal implementation has to send an âasIconâ before >>> using it? >>> >>> Cheers, >>> Doru >>> >>> >>> >>>> On Oct 12, 2016, at 10:33 PM, stepharo <stepharo(a)free.fr >>>> <mailto:stepharo@free.fr>> wrote: >>>> >>>> I'm adding >>>> >>>> act: aBlock iconName: aSymbol entitled: aString >>>> self act: aBlock icon: (self iconNamed: aSymbol) entitled: aString >>>> >>>> and >>>> >>>> act: aBlock iconName: aSymbol on: aCharacter entitled: aString >>>> self act: aBlock icon: (self iconNamed: aSymbol) on: aCharacter >>>> entitled: aString >>>> >>>> and others .... >>>> >>> -- >>> www.tudorgirba.com <http://www.tudorgirba.com> >>> www.feenk.com >>> >>> "Every thing has its own flow." >>> >>> >>> >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com > > "We are all great at making mistakes." > > > > > > > >

Oct. 13, 2016

[ANN] New release of iceberg

by Nicolas Passerini

Hi, we are releasing a new version of Iceberg, with several new features and bugfixes. I would't yet say that is 100% production ready, but it is close, so I want to invite you to test it and provide feedback. You can install it by doing: Metacello new baseline: 'Iceberg'; repository: 'github://npasserini/iceberg'; load. More installation instructions and documentation can be found at https://github.com/npasserini/iceberg. Some of the new features in this version are: - Allow to commit several packages together in the same commit. - Show diffs for incoming and outgoing commits (i.e. before push/pull you can browse the difference between the remote and the local versions). - New History view allows to see any commit in any branch and compare it to the current loaded version. - Better support for interacting code loaded outside Iceberg (smaltalkhub, filetree, gitfiletree, etc). - From the diff view, revert changes or browse them (i.e. open a Nautilus on the changed class/method). - Automatically update presentations on code / repository changes. - Integration with Metacello, i.e. after installing Iceberg you do something like Metacello new baseline: 'TaskIt'; repository: 'github://sbragagnolo/taskit'; load. (By default) it will be loaded using iceberg (there is a setting to avoid it if you prefer traditional behavior. - Improved handling of git errors. - Improved performance for several operations. - Improved documentation. - ... and several bug fixes and other minor improvements (please look at https://github.com/npasserini/iceberg/milestone/7?closed=1 for more details). Please do not hesitate to contact me if you have any doubts.

Oct. 13, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by stepharo

>> what if you want to have side by side two different themes to compare >> the best icons >> choices? > > This is a valid concern, but I do not understand how this would work > if the only thing you pass in iconName: is just one symbol: > > act: aBlock iconName: *aSymbol* entitled: aString > > So there needs to be a lookup. This lookup will depend on the current > icon theme. So, you could open on window with one theme, switch the > theme and then open another window. Or did I misunderstand something? The idea is that all the tools: should have an iconProvider and not a global lookup (even if the lookup can access a global) > My idea was that we leave the public API of Glamour to be: > > act: aBlock icon: *aSymbolOrForm* entitled: aString > > and then if you want to play with things, you can also explicitly pass > one icon or another (beside relying on the default lookup behavior). > > What do you think? I would like to avoid clients to use Symbol >> asIcon it can be an internal implementation. > > Doru > >> >>> >>> In this way we do not have to change the external interface, and >>> only the internal implementation has to send an âasIconâ before >>> using it? >>> >>> Cheers, >>> Doru >>> >>> >>> >>>> On Oct 12, 2016, at 10:33 PM, stepharo <stepharo(a)free.fr >>>> <mailto:stepharo@free.fr>> wrote: >>>> >>>> I'm adding >>>> >>>> act: aBlock iconName: aSymbol entitled: aString >>>> self act: aBlock icon: (self iconNamed: aSymbol) entitled: aString >>>> >>>> and >>>> >>>> act: aBlock iconName: aSymbol on: aCharacter entitled: aString >>>> self act: aBlock icon: (self iconNamed: aSymbol) on: aCharacter >>>> entitled: aString >>>> >>>> and others .... >>>> >>> -- >>> www.tudorgirba.com <http://www.tudorgirba.com> >>> www.feenk.com >>> >>> "Every thing has its own flow." >>> >>> >>> >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com > > "We are all great at making mistakes." > > > > > > > >

Oct. 13, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Tudor Girba

Hi, > On Oct 13, 2016, at 1:03 PM, stepharo <stepharo(a)free.fr> wrote: > > >> Thanks! >> >> Just a question: How about adding an extension >> >> Symbol>>asIcon >> ^ â¦ look up the icon >> >> Form>>asIcon >> ^ self > > what if you want to have side by side two different themes to compare the best icons > choices? This is a valid concern, but I do not understand how this would work if the only thing you pass in iconName: is just one symbol: act: aBlock iconName: aSymbol entitled: aString So there needs to be a lookup. This lookup will depend on the current icon theme. So, you could open on window with one theme, switch the theme and then open another window. Or did I misunderstand something? My idea was that we leave the public API of Glamour to be: act: aBlock icon: aSymbolOrForm entitled: aString and then if you want to play with things, you can also explicitly pass one icon or another (beside relying on the default lookup behavior). What do you think? Doru > >> >> In this way we do not have to change the external interface, and only the internal implementation has to send an âasIconâ before using it? >> >> Cheers, >> Doru >> >> >> >>> On Oct 12, 2016, at 10:33 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>> I'm adding >>> >>> act: aBlock iconName: aSymbol entitled: aString >>> self act: aBlock icon: (self iconNamed: aSymbol) entitled: aString >>> >>> and >>> >>> act: aBlock iconName: aSymbol on: aCharacter entitled: aString >>> self act: aBlock icon: (self iconNamed: aSymbol) on: aCharacter entitled: aString >>> >>> and others .... >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Every thing has its own flow." >> >> >> >> >> >> >> > > -- www.tudorgirba.com www.feenk.com "We are all great at making mistakes."

Oct. 13, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by stepharo

> Thanks! > > Just a question: How about adding an extension > > Symbol>>asIcon > ^ â¦ look up the icon > > Form>>asIcon > ^ self what if you want to have side by side two different themes to compare the best icons choices? > > In this way we do not have to change the external interface, and only the internal implementation has to send an âasIconâ before using it? > > Cheers, > Doru > > > >> On Oct 12, 2016, at 10:33 PM, stepharo <stepharo(a)free.fr> wrote: >> >> I'm adding >> >> act: aBlock iconName: aSymbol entitled: aString >> self act: aBlock icon: (self iconNamed: aSymbol) entitled: aString >> >> and >> >> act: aBlock iconName: aSymbol on: aCharacter entitled: aString >> self act: aBlock icon: (self iconNamed: aSymbol) on: aCharacter entitled: aString >> >> and others .... >> > -- > www.tudorgirba.com > www.feenk.com > > "Every thing has its own flow." > > > > > > >

Oct. 13, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Henrik Johansen

> On 12 Oct 2016, at 8:09 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-10-12 20:06 GMT+02:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: > In fact I do not really like iconNamed: as a name for a setter (for menu items and settings) > May be it should be iconSelector: or buildIconNamed: > because else we will confuse iconNamed: which returns an icon and iconNamed: that just sets the selector to retrieve the selector. > > What do you think? > > maybe #iconName:? Isn't this exposing internal implementation details in the external API? The end result is a menu or a setting displayed with the corresponding iconNamed: associated, no? Cheers, Henry

Oct. 13, 2016