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

[pharo-project/pharo-core] 5dfcea: 60188

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 5dfcea3320fb3b8942a80337b07de7565f30e73c https://github.com/pharo-project/pharo-core/commit/5dfcea3320fb3b8942a80337… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-19 (Fri, 19 Aug 2016) Changed paths: M Kernel.package/MessageSend.class/instance/evaluating/value.st M Kernel.package/MessageSend.class/instance/evaluating/value_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60187.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60188.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60187.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60188.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60188 18158 MessageSend should not care about obsolete classes https://pharo.fogbugz.com/f/cases/18158 http://files.pharo.org/image/60/60188.zip

Aug. 19, 2016

STON and (default) line endings

by Peter Uhnak

Hi, can we have a class-side configuration for STON line ending? Atm if I want to output with LF instead of CR (which is always), then I have to always do this String streamContents: [ :stream | (STON writer on: stream) prettyPrint: true; newLine: String lf; nextPut: data ]. I would be much happier if at least I could do this STON lineEnding: String lf (I could put the above in a StartupScript) And then just use regular STON toStringPretty: data. And I would be even happier if STON class>>lineEnding ^ String lf or STON class>>lineEnding ^ OSPlatform current isWindows ifTrue: [ String crlf ] ifFalse: [ String lf ] (Although always using LF by default might be preferable.) To summarize, it would be great if we could: * switch STON to LF _by default_ * allow users to easily switch to CR/CRLF if they need Thanks, Peter

Aug. 19, 2016

Re: [Pharo-dev] Usability issue : the class/instance button in Pharo 5 gives poor feedback

by Sven Van Caekenberghe

Oscar, > On 19 Aug 2016, at 14:15, Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> wrote: > > > Hi Folks, > > Does anyone else find this to be a problem? I can never tell whether I am on the class or the instance side as the button toggle is non-obvious. In fact, the (C) is more clearly visible on the instance side, which is counter intuitive. > > I would rather see the name of the button change between âInstanceâ and âClassâ so I always know where I am. > > Cheers, > Oscar You are right, toggle buttons are never very intuitive. Two way switches with double green/gray labels are better but take more space. In Pharo 6 Dark Theme, there are several 'clear' differences: the blue of the class button selection (pressed), the title of the browser window, the changed template or protocols, no ? It is not perfect, but good enough, there is no easy improvement without taking more space, IMHO. Sven

Aug. 19, 2016

Usability issue : the class/instance button in Pharo 5 gives poor feedback

by Oscar Nierstrasz

Hi Folks, Does anyone else find this to be a problem? I can never tell whether I am on the class or the instance side as the button toggle is non-obvious. In fact, the (C) is more clearly visible on the instance side, which is counter intuitive. I would rather see the name of the button change between âInstanceâ and âClassâ so I always know where I am. Cheers, Oscar

Aug. 19, 2016

Re: [Pharo-dev] Epicea import+revert instead of redo+undo changes? (Was: Re: [pharo-project/pharo-core] f57843: 60163)

by Denis Kudriashov

2016-08-19 10:43 GMT+02:00 Max Leske <maxleske(a)gmail.com>: > I think âapplyâ is better. âimportâ sounds too specific to me. I donât > want to care where the entries come from and âimportâ implies that there > may be something else going on (also: if thereâs an import whereâs the > export?). But we support to open and import changes from any image (not only owner). Anyway we need to choose most intuitive name because undo/redo are always raise questions (also after many times I use it). "apply" could be good too.

Aug. 19, 2016

Re: [Pharo-dev] Epicea import+revert instead of redo+undo changes? (Was: Re: [pharo-project/pharo-core] f57843: 60163)

by Esteban Lorenzano

> On 19 Aug 2016, at 10:43, Max Leske <maxleske(a)gmail.com> wrote: > > I think âapplyâ is better. âimportâ sounds too specific to me. I donât want to care where the entries come from and âimportâ implies that there may be something else going on (also: if thereâs an import whereâs the export?). +1 :) > > But thatâs just an opinion. > > Cheers, > Max > > >> On 19 Aug 2016, at 04:13, Martin Dias <tinchodias(a)gmail.com <mailto:tinchodias@gmail.com>> wrote: >> >> Hi Stef, I come back to your observation about the words Redo and Undo used in Epicea menu. You proposed to use Import and Revert instead. >> >> Originally I chose redo/undo because they are very well known terms in text editing UIs, but it is true that they are different: in regular UIs you can't select an arbitrary operation in the history and redo or undo it, like in Epicea. So other names can be more adequate... >> >> any other opinion? >> >> >> >> Martin >> >> ps: other alternative is apply+"apply inverse" >> >> ps2: I'm preparing a major update in Epicea's UIs, which already has some renames. >> >> <PharoScreenshot.1.png> >> â >> >> >> >> >> >> >> El 7/8/2016 3:16, "stepharo" <stepharo(a)free.fr <mailto:stepharo@free.fr>> escribiÃ³: >> >> >> Le 5/8/16 Ã 05:28, Martin Dias a Ã©crit : >>> Hi Stef, good, I take note. I improved filters in the recent releases and will continue improving. >> >> Thanks Martin >> >> I have problems with the menu item names :) >> To me redo looks strange >> when I get a crash I want to import the changes not redo them. >> Then I do not get what undo means (yes I know this is probably revert) >> May be some pharoers have better names than mine. >> >> Stef >> >>> >>> Martin >>> >>> On Wed, Aug 3, 2016 at 5:30 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>> Thanks Martin. >>> >>> We missed yesterday: show only the latest version of every entities. :) >>> >>> >>> Setf >>> >>> >>> Le 3/8/16 Ã 11:23, Marcus Denker a Ã©crit : >>> >>> On 03 Aug 2016, at 11:07, GitHub <noreply(a)github.com <mailto:noreply@github.com>> wrote: >>> >>> >>> Log Message: >>> ----------- >>> 60163 >>> 18831 Integrate new Epicea version >>> https://pharo.fogbugz.com/f/cases/18831 <https://pharo.fogbugz.com/f/cases/18831> >>> >>> ChangeLog for this: >>> >>> - Case 18813: Implement redo and undo of protocol addition and removal. >>> >>> - Case 18612: disable drag&drop until TreeModel supports it correctly. >>> >>> - Case 18384: Redo and undo: show on any selection (not only when all selected entries are code changes). >>> >>> - Enhancement: Improve lost changes detection; show only the events actually lost. >>> >>> - Enhancement: Pass on filters. >>> >>> - Clean up: Do not show the "absent entry" item anymore since it was not useful at all. >>> >>> - Clean up: Remove unused "commit tags" in log browser. >>> >>> - Clean up: Remove unused tests. They were good idea, we can re-introduce them but working and covering more cases. >>> >>> - Clean up: Rename #displayWidget to #asMorph in EpLogBrowserItem''s hierarchy. It is more meaningful. >>> >>> - Workaround: Hide "Open in Sorter" menu action since it is useless until Treemodel drag&drop is fixed. >>> >>> >>> >>> 18768 Inlined method const could be implemented by metalinks >>> https://pharo.fogbugz.com/f/cases/18768 <https://pharo.fogbugz.com/f/cases/18768> >>> >>> 18835 Update RBParser-Nodes class comments >>> https://pharo.fogbugz.com/f/cases/18835 <https://pharo.fogbugz.com/f/cases/18835> >>> >>> http://files.pharo.org/image/60/60163.zip <http://files.pharo.org/image/60/60163.zip> >>> >>> >>> >>> >>> >>> >>> >> >> >

Aug. 19, 2016

Re: [Pharo-dev] Epicea import+revert instead of redo+undo changes? (Was: Re: [pharo-project/pharo-core] f57843: 60163)

by Max Leske

I think âapplyâ is better. âimportâ sounds too specific to me. I donât want to care where the entries come from and âimportâ implies that there may be something else going on (also: if thereâs an import whereâs the export?). But thatâs just an opinion. Cheers, Max > On 19 Aug 2016, at 04:13, Martin Dias <tinchodias(a)gmail.com> wrote: > > Hi Stef, I come back to your observation about the words Redo and Undo used in Epicea menu. You proposed to use Import and Revert instead. > > Originally I chose redo/undo because they are very well known terms in text editing UIs, but it is true that they are different: in regular UIs you can't select an arbitrary operation in the history and redo or undo it, like in Epicea. So other names can be more adequate... > > any other opinion? > > > > Martin > > ps: other alternative is apply+"apply inverse" > > ps2: I'm preparing a major update in Epicea's UIs, which already has some renames. > > <PharoScreenshot.1.png> > â > > > > > > > El 7/8/2016 3:16, "stepharo" <stepharo(a)free.fr <mailto:stepharo@free.fr>> escribiÃ³: > > > Le 5/8/16 Ã 05:28, Martin Dias a Ã©crit : >> Hi Stef, good, I take note. I improved filters in the recent releases and will continue improving. > > Thanks Martin > > I have problems with the menu item names :) > To me redo looks strange > when I get a crash I want to import the changes not redo them. > Then I do not get what undo means (yes I know this is probably revert) > May be some pharoers have better names than mine. > > Stef > >> >> Martin >> >> On Wed, Aug 3, 2016 at 5:30 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >> Thanks Martin. >> >> We missed yesterday: show only the latest version of every entities. :) >> >> >> Setf >> >> >> Le 3/8/16 Ã 11:23, Marcus Denker a Ã©crit : >> >> On 03 Aug 2016, at 11:07, GitHub <noreply(a)github.com <mailto:noreply@github.com>> wrote: >> >> >> Log Message: >> ----------- >> 60163 >> 18831 Integrate new Epicea version >> https://pharo.fogbugz.com/f/cases/18831 <https://pharo.fogbugz.com/f/cases/18831> >> >> ChangeLog for this: >> >> - Case 18813: Implement redo and undo of protocol addition and removal. >> >> - Case 18612: disable drag&drop until TreeModel supports it correctly. >> >> - Case 18384: Redo and undo: show on any selection (not only when all selected entries are code changes). >> >> - Enhancement: Improve lost changes detection; show only the events actually lost. >> >> - Enhancement: Pass on filters. >> >> - Clean up: Do not show the "absent entry" item anymore since it was not useful at all. >> >> - Clean up: Remove unused "commit tags" in log browser. >> >> - Clean up: Remove unused tests. They were good idea, we can re-introduce them but working and covering more cases. >> >> - Clean up: Rename #displayWidget to #asMorph in EpLogBrowserItem''s hierarchy. It is more meaningful. >> >> - Workaround: Hide "Open in Sorter" menu action since it is useless until Treemodel drag&drop is fixed. >> >> >> >> 18768 Inlined method const could be implemented by metalinks >> https://pharo.fogbugz.com/f/cases/18768 <https://pharo.fogbugz.com/f/cases/18768> >> >> 18835 Update RBParser-Nodes class comments >> https://pharo.fogbugz.com/f/cases/18835 <https://pharo.fogbugz.com/f/cases/18835> >> >> http://files.pharo.org/image/60/60163.zip <http://files.pharo.org/image/60/60163.zip> >> >> >> >> >> >> >> > >

Aug. 19, 2016

Re: [Pharo-dev] Epicea import+revert instead of redo+undo changes? (Was: Re: [pharo-project/pharo-core] f57843: 60163)

by Denis Kudriashov

2016-08-19 4:13 GMT+02:00 Martin Dias <tinchodias(a)gmail.com>: > ps2: I'm preparing a major update in Epicea's UIs, which already has some > renames. > > > â > > That is cool

Aug. 19, 2016

Re: [Pharo-dev] Epicea import+revert instead of redo+undo changes? (Was: Re: [pharo-project/pharo-core] f57843: 60163)

by Denis Kudriashov

Hi 2016-08-19 4:13 GMT+02:00 Martin Dias <tinchodias(a)gmail.com>: > Hi Stef, I come back to your observation about the words Redo and Undo > used in Epicea menu. You proposed to use Import and Revert instead. > > Originally I chose redo/undo because they are very well known terms in > text editing UIs, but it is true that they are different: in regular UIs > you can't select an arbitrary operation in the history and redo or undo it, > like in Epicea. > Does it always work? I could rename class A to B. Then I will rename B to C. After that how first change could be reverted?

Aug. 19, 2016

Re: [Pharo-dev] Epicea import+revert instead of redo+undo changes? (Was: Re: [pharo-project/pharo-core] f57843: 60163)

by Denis Kudriashov

I prefer import/revert 2016-08-19 10:27 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > apply / revert sounds good to me. > > Esteban > > On 19 Aug 2016, at 09:37, stepharo <stepharo(a)free.fr> wrote: > > good to me. > > Import is good. Apply to. > > After I'm not sure I understand redo :) > > > Tx for the new release > Le 19/8/16 Ã 04:13, Martin Dias a Ã©crit : > > Hi Stef, I come back to your observation about the words Redo and Undo > used in Epicea menu. You proposed to use Import and Revert instead. > > Originally I chose redo/undo because they are very well known terms in > text editing UIs, but it is true that they are different: in regular UIs > you can't select an arbitrary operation in the history and redo or undo it, > like in Epicea. So other names can be more adequate... > > any other opinion? > > > Martin > > ps: other alternative is apply+"apply inverse" > > ps2: I'm preparing a major update in Epicea's UIs, which already has some > renames. > > <Mail Attachment.png> > â > > > > > El 7/8/2016 3:16, "stepharo" <stepharo(a)free.fr> escribiÃ³: > > > > Le 5/8/16 Ã 05:28, Martin Dias a Ã©crit : > > Hi Stef, good, I take note. I improved filters in the recent releases and > will continue improving. > > > Thanks Martin > > I have problems with the menu item names :) > To me redo looks strange > when I get a crash I want to import the changes not redo them. > Then I do not get what undo means (yes I know this is probably revert) > May be some pharoers have better names than mine. > > Stef > > > Martin > > On Wed, Aug 3, 2016 at 5:30 PM, stepharo <stepharo(a)free.fr> wrote: > >> Thanks Martin. >> >> We missed yesterday: show only the latest version of every entities. :) >> >> >> Setf >> >> >> Le 3/8/16 Ã 11:23, Marcus Denker a Ã©crit : >> >> On 03 Aug 2016, at 11:07, GitHub <noreply(a)github.com> wrote: >>>> >>>> >>>> Log Message: >>>> ----------- >>>> 60163 >>>> 18831 Integrate new Epicea version >>>> https://pharo.fogbugz.com/f/cases/18831 >>>> >>>> ChangeLog for this: >>> >>> - Case 18813: Implement redo and undo of protocol addition and removal. >>> >>> - Case 18612: disable drag&drop until TreeModel supports it correctly. >>> >>> - Case 18384: Redo and undo: show on any selection (not only when all >>> selected entries are code changes). >>> >>> - Enhancement: Improve lost changes detection; show only the events >>> actually lost. >>> >>> - Enhancement: Pass on filters. >>> >>> - Clean up: Do not show the "absent entry" item anymore since it was not >>> useful at all. >>> >>> - Clean up: Remove unused "commit tags" in log browser. >>> >>> - Clean up: Remove unused tests. They were good idea, we can >>> re-introduce them but working and covering more cases. >>> >>> - Clean up: Rename #displayWidget to #asMorph in EpLogBrowserItem''s >>> hierarchy. It is more meaningful. >>> >>> - Workaround: Hide "Open in Sorter" menu action since it is useless >>> until Treemodel drag&drop is fixed. >>> >>> >>> >>> 18768 Inlined method const could be implemented by metalinks >>>> https://pharo.fogbugz.com/f/cases/18768 >>>> >>>> 18835 Update RBParser-Nodes class comments >>>> https://pharo.fogbugz.com/f/cases/18835 >>>> >>>> http://files.pharo.org/image/60/60163.zip >>>> >>>> >>>> >>> >>> >> >> > > > > >

Aug. 19, 2016