- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] <example>/<examplar>

by stepharo

Le 19/8/16 Ã 10:18, Tudor Girba a Ã©crit : > Hi, > > I strongly believe that the interaction should not be hardcoded in the example pragma name. That is because you will want all sorts of interactions once you go beyond the surface. For example, a Roassal visualization, a Bloc element, and a Morph are all interesting from an interaction point of view, but there are different ways to open them (and having it polymorphic does not quite make sense). sorry but I cannot understand what you mean. You suggest to use example but not to have it polymorphic? > > Cheers, > Doru > > > >> On Aug 19, 2016, at 9:52 AM, stepharo <stepharo(a)free.fr> wrote: >> >> Let me know. I do not care about examplar or sample. >> >> Let us pick one that works well. I thought about prototype but this is too close to prototype based language. >> >> So we could get >> >> <interactiveExample> >> >> <sample>/<instance>/ >> >> >> Le 19/8/16 Ã 01:59, Ben Coman a Ã©crit : >>> On Fri, Aug 19, 2016 at 5:09 AM, Esteban A. Maringolo >>> <emaringolo(a)gmail.com> wrote: >>>> 2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: >>>>> On 18/08/16 14:38, stepharo wrote: >>>>>> Hi >>>>>> >>>>>> In my projects I start to do the following: >>>>>> >>>>>> I create <examplar> class method that returns an prototypical instance. >>>>> Nice. Excellent inititive. I'm not a native speaker, and <exemplar> does not >>>>> sound like the right name for this to me. That might be me being dutch. >>>>> Native speakers, is this the right name to use? >>>> Semantically it is correct, but for me, also maybe by not being a >>>> native English speaker, sounds weird. >>>> >>>> I'd use something like "sample". However I'll be fine with whatever >>>> you choose. But I'd choose something that doesn't sound weird to >>>> native English readers, we already have some cases of that. >>>> >>>> Regards, >>>> >>>> >>>> Esteban A. Maringolo >>>> >>> In the previous thread I argued against <exemplar> and for <sample>, >>> but I'm not so strong in my conviction to push it again :). The >>> former is a little exotic, but is sufficient -- and perhaps its useful >>> <example> and <exemplar> sound similar with just a minor difference at >>> the end. >>> >>> P.S. In terms of discover-ability about this difference, a passing >>> thought is it would be nice for newcomers to be able to hover over a >>> code like a pragma and get a tool tip popup. >>> >>> cheers -ben >>> >>> >> > -- > www.tudorgirba.com > www.feenk.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > > >

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

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 <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] FileTree export format on Windows

by Sven Van Caekenberghe

> On 19 Aug 2016, at 09:36, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > I just ran into a quite nasty issue when using GitFileTree on Windows with the FileTree export format. > > Apparently there are reserved names on Windows: > > > CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9 > > And I had an âauxâ and âaux:â methods in Pharo, which were attempted to be exported as âaux.stâ and âaux..stâ, but silently failed. The silently fails part is really bad ! > There are also other rules https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#naming_conven… which might break binary selectors (I havenât tried those). > > I am not sure how I am supposed to deal with this, but assuming Pharo wants to support all platforms, this should be resolved in some manner; in the meantime I will use some alternative name. > > Thanks, > Peter

Aug. 19, 2016